Re: [Autoconf] aspects of multi-hop wireless communication

["Teco Boot" <[e-mail]>]

|> Try it, and you will see it will fail.
|> OK, you can modify the code if you have a C compiler nearby, and some
|> sources to modify.
|
|I'm not meaning to modify any code.  It's existing software doing
|bridging between two interfaces as it always did.

No, you are prohibited to add a 802.11 IBSS interface to a bridge.

OK, you can do it without warnings, but the 802.11 mechanisms will not
operate as they should. There are problems with address fields, the NIC
cannot send CTS or ACK to the sender, because the transmitter MAC address is
missing in the RTS or DATA MAC header.
You could disable RTS-CTS and send unicast frames until retry limit, but is
this the behavior that you suggest?


|> But that is no longer wifi.
|
|Well, it's two 802.11a/b interfaces, running as before.  I could put
|both interfaces in ad-hoc mode with iwconfig.  There's probably a
|misunderstanding between what the IEEE standard documents mean by
|"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc"
|but I'm sure it works, by experience.

I am not aware with problems with iwconfig. It should configure the NIC in
IBSS mode. 


|Or I could set up both to act as access points, it's the same.  (the
|only visible difference  between AP mode and ad-hoc modes in
|implementation is the MAC address of the essid... in AP mode it's the
|real MAC address of the interface doing AP, in ad-hoc mode it's some
|random 48bit).  The resolution between this 48bit number and essid ascii
|name is done by 802.11 link-layer exchanges (probe req/reply IIRC).

There are lots of other differences between IBSS and BSS.

On (R1, R2, A):
What if A is STA and R1 and R2 are APs? Assume APs cannot communicate with
each other (no DS). Assume some kind of disaster.

One could deploy dense APs and a (to be standardized) form of mesh MANET
protocol. This could be disaster^2! 
(think of beacon-rain and probe-response-storms, and melt downs due to
collisions)


|> You could enable routing, and you are done!
|
|Why doing routing when I could do bridging, simpler, widely available
|software.

Try and you will see lots of shortcomings with bridging and 802.11 IBSS.
I am not saying it cannot be solved at a shim layer, but please accept this
is not supported by current wifi standards.

And provide evidence if I am wrong. I will ask errata on the IEEE 802
standards if you come up with it.


|> Play a little with it, and check your (false) assumptions.
|
|I'm not sure which assumption you think I made false?  The fact that I
|could build a bridge with brctl and two wifi interfaces?

I explained above your assumption is false. I analyzed your suggestions
before and my conclusion 802.1D bridging is indeed not allowed with 802.11
IBSS.


By the way, there is code around that improves 802.11 IBSS mode, so bridging
is allowed. Ask Ronald In't Velt for details. This could be very useful if
you want to connect a 802.11 IBSS bridge to a router (split devices) or just
connect a couple of hosts to an ad hoc bridge.


Teco.


_______________________________________________
Autoconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/autoconf