[OLSR-users] WLAN and Broadcasts (e.g. OLSR)
Nikolaos Tsarmpopoulos
(spam-protected)
Fri Apr 28 17:17:06 CEST 2006
Hi,
I can confirm that this was a major issue on our network in Volos,
Greece (http://vmesh.inf.uth.gr/). Specifically, when there was a file
transfer between two nodes, broadcast packets used for HELLO messages
around these nodes were lost (due to collisions, I suppose) resulting in
unstable connections.
Also, I recall that someone suggested in the list the solution of
broadcasting + unicasting of HELLO messages, where broadcasting aims at
detecting new nodes, while unicasting aims at checking if known
neighbors are still reachable. I haven't checked latest features of
olsrd, but I think it is a planned feature for the new
(non-OLSR-compliant) version of the protocol.
Regards,
Nikos
Sven-Ola Tuecke wrote:
> Joerg,
>
> some Wifi cards have 2 settings for speed and mode. Unicast rate and
> multi(broad)cast Rate. If may have for example a multicast rate of 54g
> while using unicast 1b. Look out for iwprivs on that issue.
>
> HTH
> Sven-Ola
>
> "Joerg Pommnitz" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>> Hello all,
>> I have stumbled accross a problem with olsrd. It seems that
>> HELLO-Messages are only visible over a very short distance. Other
>> protocols (ICMP-Echo, ssh, iperf) work fine, however. The difference
>> is, that these protocols are unicast while olsr HELLO-messages are
>> sent to the broadcast address of the subnet. I have verified that a
>> broadcast ping has the same problems, so its not really OLSR-specific.
>>
>> This got me thinking. My understanding is, that 802.11 modifies the
>> over-the-air coding of the data packets according to the error rate
>> when talking to the peer. It trades bandwidth for reliability when
>> the error rate goes up. However, this is a point-to-point concept. In
>> AdHoc-Mode where you talk to all the nodes in a cell, this is not
>> applicable. My suspiction is, that the 802.11 card sends the
>> broadcast packets in whatever coding is the default for the current
>> mode which might not be optimal for nodes that are further away. Has
>> anybody seen something like this? Am I on the right track? Is there a
>> solution? Something I could try?
>>
>> -- Thanks in advance
>>
>> Joerg
>>
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
>
More information about the Olsr-users
mailing list