[Olsr-dev] Bug in edge detection

[Hannes Gredler]

is independend of the underlying media ...

On Fri, Sep 07, 2007 at 02:42:41PM +0600, Aaron Kaplan wrote:
| 
| 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
| 
| 
| 
| 
| 
| -- 
| Olsr-dev mailing list
| (spam-protected)
| http://lists.olsr.org/mailman/listinfo/olsr-dev
|