[Olsr-dev] broadcast packet filtering

[Erik Tromp]

Hannes,

IMHO your comment is bashing. Please support your insinuations
("destabilizing") with examples or with proof. And mention exactly the
circumstances and conditions so we have a base for improvement.

Of course any over-feeding of packets into any forwarding system may lead to
queues becoming full and overflowing. Totally nothing new here. Try to route
1000000 IP packets per second through a 50 MHz CPU and its queues will
overflow.

Destabilization is the result of wrong handling priorities. Not from loose
statements based on vague opinions.

Joe, thanks for the suggestion! Would there be any way to implement this
kind of filter from within the C source code of bmf? A way to implement a
very quick disposal of the bounced back packets? And preferrably without the
need for an external component like iptables?

Erik



-----Oorspronkelijk bericht-----
Van: (spam-protected)
[mailto:(spam-protected)] Namens Hannes Gredler
Verzonden: dinsdag 6 mei 2008 7:59
Aan: Joe Gio
CC: olsr-dev
Onderwerp: Re: [Olsr-dev] broadcast packet filtering

hi joe,

IMO the basic idea of the bmf plugin (piggyback dataplane traffic on top of
control-plane traffic) is way broken, and for the reasons you have been
giving (as per your example below), it may even become destabilizing.

i have been mulling with henning over the ideas to program real multicast
forwarding state (/64 (S,G) for IPv4 and /256 (S, G) for
IPv6 into the kernel FIB. Every node shall publish the multicast groups it
wants to receive via protocol extensions. During the SPF run we could
compute the distribution tree and program the kernel FIB, such that
data-plane and control-plane stays seperate.

the idea is nothing new, much stuff will be derived from MOSPF

http://www.javvin.com/protocolMOSPF.html

/hannes

On Mon, May 05, 2008 at 02:26:45PM -0400, Joe Gio wrote:
| 
| It has been noticed that nodes generating high broadcast traffic (bmf 
| encap packets for instance) will "loose" some incoming messages even 
| though they are clearly visible being received using tcp dump on the 
| wireless interface.
| 
| The problem is that "broadcast " packets sent from the local node are 
| looped back to any listening sockets on the same box as is the case in 
| bmf, so bmf has to process (discard) its own broadcasts. Since bmf is 
| already busy reading packets of the wired interface the wireless 
| receive queue starts to get backed quickly so any "real" packets 
| received from other nodes get dropped in the socket buff before bmf 
| can process. This can be confirmed using the netstat command  "while 
| sleep 1; do netstat -a 2<&1 | grep 50698; done"
| 
| This command filters out the nodes own broadcast packets using ip 
| tables on the gateworks armeb board.
| 
| ADDR=`ifconfig ath0 | grep "inet addr" | awk '{print $2}'`
| 
| BCAST=`ifconfig ath0 | grep "inet addr" | awk '{print $3}'`
| 
| ADDR=`echo $ADDR | sed -e s/:/\ /g | awk '{print $2}'`
| 
| BCAST=`echo $BCAST | sed -e s/:/\ /g | awk '{print $2}'`
| 
| iptables -I INPUT -p udp --src $ADDR --dst $BCAST -j DROP
| 
| Joe Gio

--
Olsr-dev mailing list
(spam-protected)
http://lists.olsr.org/mailman/listinfo/olsr-dev