Re: [RFC PATCH net-next v0.1 1/1] net: add GeoNetworking protocol

Let frame this in IP/Ethernet/802.11 words, where applicable,
since they are better understood by everyone.

Okay.

[...]
So i don't think thinking about a tunnel actually helps.

So let's stick to bridges and multiple interfaces.

But how do we handle multiple interfaces?

That's the central question.

Does an 802.1 bridge actually break and cause loops [when using
GeoBroadcast / the L2 flood mechanism]?

I think, yes. Currently there is a actually a mechanism implemented,
which is described in the standard and mitigates some of the flooding,
called gn_dpd_find in gn_routing.c. It is based on the sequence number
of the last few packets recieved and a packet is dropped, if it has a
same sequence number as seen before (determined by if an entry of that
sequence number exists in a ring buffer). But I am not completely sure
if that addresses all possible problems, that could arise from all
(or even most possible) scenarios with multiple interfaces (maybe even
bridged).

And the L2 food mechanism and the L2.5 unicast mechanism, both need
considering, and the two might interact with each other.

I don't think they interact with each other. The worst case regarding
L2.5 unicast is - I think - when both interfaces (with the same
position) are closest to the destination node of a unicast, but not
close enough to be in range to that node. That may be problematic. But
an interaction between the L2 flood mechanism and the L2.5 unicast
mechanism I don't see at the moment.

For the broadcast flooding, i assume there is some packet duplication
detection, and duplicates get dropped.

It is, gn_dpd_find called from gn_update_location_table which in turn
is called in the handling process of each recieved packet.

Can you add on top of interfaces a GN bridge, and have hierarchical
duplication detection? If the interface has seen the packet before it
do not rebroadcast, it just sends it up to the bridge. If the bridge
has seen the packet before drops it.

I think gn_dpd_find currently is 'global' to the gn module, so the
other interface of the bridge would detect the duplicate packet, too
and drop it. Which in turn would mean, that bridged packets currently
would be dropped instantly. (Which is the current behavior, gn packets
currently are not transmitted over a bridge, properly).

since interfaces can be in different locations, the table is an
interface property. So it might require hierarchical tables, and the
interface table just says pass the frame to the global routing table,
and the global routing table then decides which egress interface to
use?

Would it solve our problems/open questions, if we drop the capability
of interfaces being in different locations? (I think not completely,
but it may be worth considering nevertheless, I think).

So lots of questions here.

Indeed.

What we need is an architect

That I think exceeds my capabilities. Therefore I lack at least
knowledge of the linux kernel (e.g. its internal implementation of
bridges) and probably even more.

Simon