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

[Alexandru Petrescu <[e-mail]>]

Teco Boot wrote:
> |> 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.

TEco, I can report more details about this particular experiment early 
next year about the experiment, if you wish.

Alex

> 
> 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.
> 
> 
> 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Autoconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/autoconf