From: Simon Dietz <simon.dietz@plantwatch.de>
To: andrew@lunn.ch
Cc: andrew+netdev@lunn.ch, davem@davemloft.net,
dietz23838@hs-ansbach.de, edumazet@google.com,
johannes@sipsolutions.net, kuniyu@google.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
simon.dietz@plantwatch.de
Subject: Re: short description of GeoNetworking
Date: Wed, 22 Jul 2026 23:34:37 +0200 [thread overview]
Message-ID: <20260722213437.3593569-1-simon.dietz@plantwatch.de> (raw)
In-Reply-To: <937e2942-3c0d-4583-a741-8a96c4e0bbc4@lunn.ch>
Hi Andrew,
> I assume there is some daemon talking to gpsd on one side, and the
> kernel and the other? What other user space pieces are there?
At time of creation of the initial code base we used user space code to
pass the gps position data from gpds to the kernel module (first via
/proc then via ioctl). We also wrote some code that implemented a very
limited subset of the higher layer protocols (BTP and DNEM) for
testing purposes. We also had some scripts for qemu (for debugging
the implementation in an isolated environment) and ansible scripts to
patch the ath9k driver to actually use the 802.11p wifi band (which is
above the classic 5 GHz wifi 802.11ac band) for testing the inter-
operability with a specific commercial solution. However only the
geonetworking kernel module and the ansible scripts have been published
> So it would be good to include a link to your git repo. We generally
> want open user spaces tools.
I'll polish them a bit, then I'll publish them near-term.
> Given the previous definition, this makes no sense.
I may have simplified the modes of operation too much, sorry for the
confusion. Having the standard (ETSI EN 302 636-1) open (which contains
a visualization of the operating modes), let me try it again.
There is GeoUnicast, which is the most advanced and needs routing and
the cosine calculations to find the intermediary host in range closest
to the target host.
Then there is GeoBroadcast, where a packet is forwarded hop-by-hop
until it reaches a host inside the target geographic area. Once having
reached the target area it is then broadcasted (and re-broadcasted /
flooded) by hosts in that area (until the with each broadcast decreased
hop-limit reaches 0).
And there is Topologically-scoped broadcast (TSB) where a packet is
broadcasted to all nodes in the n-hop neighbourhood (with the special
case single-hop broadcast with n=1).
> How useful is the stack without unicast?
At first glance, not very much. But considering the use case (e.g. BTP
or DNEM) it is more common to notify all vehicles in range (TSB) or a
certain area (GeoBroadcast) to e.g. warn them of a car crash than to
search for a wrong-way driver and tell him via unicast that he is
driving in the wrong direction. And it's two-thirds of the standard.
Plus (and the most important) it would allow me to focus on more
essential stuff, first (like how to properly inject the gps position
data via netlink in a kernel conform manner) instead of aiming for full
standard conformity all at once (cathedral approach).
Simon
PS: I've seen your other emails commenting on the code, I'll answer
them later.
next prev parent reply other threads:[~2026-07-22 21:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 21:00 [RFC PATCH net-next v0.1 0/1] add GeoNetworking protocol Simon Dietz
2026-07-18 21:00 ` [RFC PATCH net-next v0.1 1/1] net: " Simon Dietz
2026-07-19 17:16 ` Andrew Lunn
2026-07-19 17:28 ` Andrew Lunn
2026-07-19 23:33 ` Andrew Lunn
2026-07-19 16:21 ` [RFC PATCH net-next v0.1 0/1] " Andrew Lunn
2026-07-20 18:36 ` short description of GeoNetworking Simon Dietz
2026-07-20 20:16 ` Andrew Lunn
2026-07-22 21:34 ` Simon Dietz [this message]
2026-07-23 0:30 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722213437.3593569-1-simon.dietz@plantwatch.de \
--to=simon.dietz@plantwatch.de \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dietz23838@hs-ansbach.de \
--cc=edumazet@google.com \
--cc=johannes@sipsolutions.net \
--cc=kuniyu@google.com \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox