[Olsr-dev] invalidate node links

[Markus Kittenberger]

On Mon, Oct 31, 2011 at 4:02 PM, Giovanni Di Stasi <
(spam-protected)> wrote:

> **
> Il 30/09/2011 10:55, Markus Kittenberger ha scritto:
>
> olsrd would drop all links if u take the interface down and not changing
> its channel while it stays (logically) up all the time.
>
>  ip link set down dev wlan0
> iwconfig wlan0 channel x
> ip link set up dev wlan0
>
>  maybe iwconfig does not work on an downed interface (depends on the wlan
> driver), than swap order of line 2 and 3,.
>
>
> I have done the following that seems to help a bit:
>
> iwconfig wlan0 channel X
>
hmm dont you have different bssids on your channels?

> ifconfig wlan0 down
> ifconfig wlan0 up
>
> Do I need to put some delay after tearing down the interface?
>
olsrd "usually" gets informed via netlink in "realtime"
but this ist not 100% reliable, (just approx 99.99999% (-;)

Markus


> Following this topic, I have also tried to change the HELLO and TC timers.
> I have cut them to half but the recovery time does not change. What should
> I also change?
> I am thinking about changing the quality window length. Would that help?
> Btw, why is that no longer configurable?
>
(cause there is no window anymore, ..)

>
> Thanks for the other suggestions. For the moment I would like to go ahead
> without changing the olsrd code or making a plugin (just an analysis of the
> Olsrd behaviour as it is now when you change channels).
>
> Best regards,
> Giovanni
>
>
>  Markus
>
>  On Fri, Sep 30, 2011 at 10:49 AM, Giovanni Di Stasi <(spam-protected)>wrote:
>
>>  Hi everyone,
>>
>> I would like to receive some advices regarding an experiment we are
>> currently performing aboud channel assignment algorithms. The scenario is
>> multi-radio.
>>
>> The channel assignment algorithm (centralized) triggers at a certain
>> point the change of channels of most of the interfaces of nodes. It may
>> happen that a neighbor which was reachable through one interface, after the
>> change,  becomes reachable through another interface [1]. The experiment we
>> are doing shows an interruption of approximately one minute before the TCP
>> connections we had established are able to return to their full speed.
>> This is due (I noticed that by taking a look at the Olsrd logs) to the
>> time Olsrd needs to drop the old route (on the old interface) and use the
>> new one (on the new interface).
>> We would like to speed up things a little bit. The first attempt we think
>>  to do is to reduce the Hello and TC Intervals. This would speed up the
>> change but will imply greater overhead. First results however show no
>> improvements.
>> A different solution would be to discard all the links departing from the
>> interface of which we have changed channel. If we change the channel of an
>> interface, it means that all the links departing from that interface are
>> (probably) no longer good, so it is good to drop them and start using new
>> links (possibly just after the first hello packet is seen, so to regain
>> rapidly connectivity). Do you agree on this solution?   If that's the case,
>> how can I tell to Olsrd to drop all the links from a certain interface?
>>
>> Thanks a lot,
>> Giovanni
>>
>>
>> [1] suppose two nodes each with two interfaces, the one set on channel 1
>> and the other on channel 2. After the channel change the first node starts
>> using channels 3 and 4 and the second channels 4 and 3.
>>
>>
>> --
>> Olsr-dev mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>
>
>
>
> --
> Giovanni Di Stasi, Ph.D. Student
> Dipartimento di Informatica e Sistemistica
> Universita' degli Studi di Napoli "Federico II"
> Via Claudio, 21 - 80125 Napoli - Italy
>
> Phone:    +39 081 7683821
> Cell:     +39 333 6383732
> E-mail:   (spam-protected)
> Skype-ID: gdistasi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20111031/02436ac6/attachment.html>