[Olsr-dev] Bug in edge detection

[Aaron Kaplan]

Is it possible that this scenario happens on ethernet (for example in  
an (open)VPN concentrator)?


a.

On Sep 7, 2007, at 2:33 PM, Sven-Ola Tuecke wrote:

> Hey,
>
> I was not aware, that messages can exceed a packet. I would  
> consider this as
> a bug (is tc msg.size adapted accordingly?). While assembling  
> packets, an
> oversized TC should be sent with a new packet as a first step.
>
> Anyhow - if a node has more than 180 IPv4 (or 75 IPv6) neighbours,  
> I would
> not expect to be able to send a single ping. Why? Because Beacons  
> are sent
> by each node every 1/10 second at 1mbit. A beacon is ~ 100 Byte. So  
> I expect
> the maximum beacon emitter count for a particular area in the range
> 1,000,000 / 1,000 / 10 => around 100. Yes, you can enforce beaconless
> operation - but there are other management frame types too...
>
> // Sven-Ola
>
> "Hannes Gredler" <(spam-protected)> schrieb im Newsbeitrag
> news:(spam-protected)
>> On Thu, Sep 06, 2007 at 05:25:07PM +0200, Bernd Petrovitsch wrote:
>> | On Thu, 2007-09-06 at 17:08 +0200, Hannes Gredler wrote:
>> | [...]
>> | > i have recently stumbled on a interesting problem that causes
>> | > quite some inefficiency wrt malloc churn() and SPF calculations.
>> | >
>> | > it happens is when a TC message gets striped over two (or  
>> more) IP
>> packets.
>> | > this is typically for a TC message at the MTU boundary of a OLSR
>> packet.
>> |
>> | Hmm, what's in the RFC about this?
>> |
>> | [...]
>> | > patchset producing the debug output above is at
>> | > http://gredler.at/download/olsrd/inplace-spf-1.diff.gz
>> | >
>> | > any smart thoughts for a fix ? -
>> |
>> | Without time and without looking into code, only the generic ones:
>> |
>> | On the sender side: Don't send half TC packets.
>>
>> hmmm not really an option ... what to do if the neighbor set >  
>> 1500 bytes.
>> just because of massive neighbors ?
>>
>> | On the receiver side (which shouldn't be necessary with the above):
>> | Wait with the TC packet processing until we are sure that it is
>> | complete, e.g.
>> | if the next is already seen or some timeout.
>>
>> what about this:
>>
>> rather than deleting the edge we tweak T_time to an expired value
>> (now_times -1).
>>
>> if the neighbor set gets found when processing further packets  
>> then T_time
>> gets overwritten, otherwise it will get deleted when prcessing  
>> eventloop
>> next time.
>>
>> /hannes
>>
>> -- 
>> Olsr-dev mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-dev
>
>
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>

---
C.O.S.H.E.R. - Completely Open Source Headers Engineering and Research