From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 6 Apr 2010 21:28:42 +0200 From: Simon Wunderlich Message-ID: <20100406192842.GA23345@pandem0nium> References: <20100404220120.GA9171@pandem0nium> <20100406093331.GA24150@Sellars> <20100406104129.GA19923@pandem0nium> <20100406131105.GA28505@Sellars> <20100406175809.GA21016@pandem0nium> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20100406175809.GA21016@pandem0nium> Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Reorganize sequence number handling Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: The list for a Better Approach To Mobile Ad-hoc Networking --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Found the bug, it happens when the difference between the received and last= seqno is exactly -64. We also have bugs in this regard in the current implementation: if seq_diff is -64, bit_get_packet calls bit_mark(). However there is a che= ck inside which ignores -64, so nothing bad happens. if seq_diff is +64, bit_get_packet calls bit_shift. There is no check in=20 bit_shift(), so one byte outside next to the sequence window read. I will send a cleaned up patch in the next few minutes. We should also fix batman (layer 3) in this regard, adding the protection window there as well might be a good idea. best regards, Simon On Tue, Apr 06, 2010 at 07:58:09PM +0200, Simon Wunderlich wrote: > Hi Linus,=20 >=20 > i've verified and can reproduce the problem. The queue limitation patch r= emoves > the OOM problems, but the same packets are still broadcasted. It is always > the same sequence number which is sent many times - the same packet > should not be sent more than 3 times. >=20 > All nodes but the original sender flood the same packets on all interface= s ... >=20 > I'll look into this, thanks. > Simon >=20 > On Tue, Apr 06, 2010 at 03:11:05PM +0200, Linus L=C3=BCssing wrote: > > On Tue, Apr 06, 2010 at 12:41:29PM +0200, Simon Wunderlich wrote: > > > Hi Linus, > > >=20 > > > from the time where the messages come (the printk is removed in the s= ubmitted > > > version of the patch BTW), we can see that there is a 30 second perio= d between > > > the protection time starts - as it is supposed to be. > > >=20 > > > I guess you have stopped your broadcast ping after ~900 seconds, but = still > > > receive packets some time later. Do you have some dumps or any analys= is data > > > for this? > > Ehm, no, I stopped after 1-2 seconds :). And well, "some" packets > > after? A is still receiving about 3000-4000 packets per second. > > I made some dumps, you can find them here: > > http://x-realis.dyndns.org/Freifunk/batman-log/mesh1.cap > > http://x-realis.dyndns.org/Freifunk/batman-log/mesh2.cap > > For the virtual machines, I've just been bridging their > > tap-interfaces on the host system, so no vde_switch/wirefilter > > involved. mesh1.cap is the capture from the bridge between A and > > B, mesh2.cap from the bridge between B and C. > > A's mac addr: XX:...:XX:X1 > > B's mac addrs: XX:...:XX:X3 > > C's mac addr: XX:...:XX:X2 > > After some seconds, B and C also seem to relay the same packet all > > the time (in this dump 2702, but is a different seqno every time I > > restart the hole setup). > > >=20 > > > I will try to rebuild your setup and turn the broadcast replies on la= ter. > > Ok. As said above, I've just connected the nodes via bridges. > > After all three nodes were connected and running, I did the > > following commands on node A: > > --- > > ifconfig bat0 up > > ifconfig bat0 192.168.123.1/24 > > echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > > ping -b -f 192.168.123.255 > /dev/null > > --> and stopped the ping command after 1 to 2 seconds. --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAku7i2oACgkQrzg/fFk7axZ66gCePH3+R8b4zmtpoCrXsorx3Za0 azQAn3+dAFthClo0G52J6uGKiqMVAOik =TQzm -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--