From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Simon Wunderlich Date: Mon, 17 Sep 2018 15:56:57 +0200 Message-ID: <3281209.XlqulP57tX@prime> In-Reply-To: References: <3502401.iodOTMQ5x1@prime> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart32716812.Y6vlbWO03M"; micalg="pgp-sha512"; protocol="application/pgp-signature" Subject: Re: [B.A.T.M.A.N.] R: Network loops on gateways join List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Francesco Salvatore [fabbricadigitale]" Cc: "b.a.t.m.a.n@lists.open-mesh.org" --nextPart32716812.Y6vlbWO03M Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi Francesco, On Wednesday, September 12, 2018 10:44:36 AM CEST Francesco Salvatore [fabbricadigitale] wrote: > Hi Simon, > > > Hi Francesco, > > > > On Tuesday, September 11, 2018 4:38:13 PM CEST Francesco Salvatore > > > > [fabbricadigitale] wrote: > > > Hi all, > > > We're running a mesh network made of a cloud of clients and multiple > > > gateways on two separate VLANs (on eth0, not on top of BATMAN). > > > The setup is similar to the one described in the figure. > > > https://www.open-> > > > mesh.org/attachments/download/132/Test_2xLAN.dia.png > > > > > We noticed that, sometimes, when new gateways are added to the already > > > running infrastructure network loops appear on VLANs We dumped VLANs > > > network traffic during one of these loops and we saw a storm of BLA > > > frames that collapsed the network. It seems that the frame (an > > > ANNOUNCE one, in this case) was firstly generated by a gateway and > > > started to loop inside the LAN, and then even the others gateways > > > propagated the same frame. After a few seconds also other frames > > > (coming from different > > > gateways) started to loop. > > > > > > Our hypothesis is that one of gateways directly injects BLA frames > > > inside mesh and that lead to an unmanageable loop. So, we have 2 > > > > questions: > > > - Are BLA frames (except for LOOP DETECT) allowed to flow only on > > > > > > LAN? > > > > Yes, all frames except LOOP DETECT are blocked in BATMAN > > > > > - If so, is our hypothesis reasonable? > > > > > > You can see the situation described above in the screenshot below. > > > http://oi63.tinypic.com/v7wl1w.jpg > > > > Unfortunately the screenshot doesn't describe which packets looped > > exactly. > > > > Are you sure it's an announce frame? It could also be a claim frame where > > two hosts try to claim hosts from each other. > > As you can see here (http://oi66.tinypic.com/ofo5jn.jpg) the frame that's > looping is an ANNOUNCE one, and so are the ones coming from Legra_55:3c:dc > The last ANNOUNCE frame from those MACs were sent 10 seconds before they > started looping, so it seems that at a certain time one of the gateways > started to forward BLA broadcast traffic from LAN to mesh. That certainly looks like an announce frame. Do you see any other frames in between, like claim frames? Announces are also sent after a couple of claim frames upon a request (check batadv_bla_answer_request). We actually had a bug where inconsistencies among the BLA tables could happen, but that was fixed before 2017.3 ... > > > BATMAN has a grace period to allow broadcasts from the LAN only after 1 > > minute of operation. This is done to make sure that the mesh is properly > > established and other gateways and their claims are detected before > > traffic is > > > allowed on it, at least potentially looping traffic. Therefore, you should > > make > > > sure (e.g. in your firmware or setup scripts) that the LAN is operational > > once > > > batman is brought op. > > > > If the mesh isn't fully established or it's actually split due to > > different > > > channels or similar, then you may run in an unresolved limitation of BLA: > > > > https://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-> > avoidance-II#Limitations > > > > For this reason we have the loop detect packets. If a loop is detected, an > > uevent is sent to userspace, and the firmware should react appropiately, > > e.g. > > > by shutting down batman-adv. > > We start gateways with this script placed in rc.local > > sudo pkill wpa_supplicant > sudo modprobe batman-adv > sudo ip link set wlan0 down > sleep 2s > sudo iwconfig wlan0 mode ad-hoc > sudo iwconfig wlan0 essid mesh-network > sudo iwconfig wlan0 ap any > sudo iwconfig wlan0 channel 44 > sudo ip link set wlan0 up > sudo batctl if add wlan0 > sleep 1s > sudo ip addr flush dev eth0 > sudo ip link add name br-lan type bridge > sudo ip link set dev eth0 master br-lan > sudo ip link set dev bat0 master br-lan > sudo ip link set up dev br-lan > sudo batctl bl 1 > sudo batctl gw server > > > As far as I can see the bridge interface gets IP/connectivity from LAN a few > seconds after the script quits. Are there steps correct or there are > possible timing issues? > We're using the same essid/channel for all originators It would be good to do "batctl bl 1" before adding bat0 to the bridge, otherwise you are not protected. Other than that, it looks fine to me. Cheers, Simon --nextPart32716812.Y6vlbWO03M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAlufsqkACgkQoSvjmEKS nqFF+hAAsLaie3rZzUMNYGEC4cTwEDZ2Ue24oupKMQssKq/WT9vrQBNbK1ZuykZa De3BiNkMsO8JPmEwWShAhEiWOl1m/EyymI1v7TW2BGLL4tZvo1xV/oWc190YAlzD GYOHc1b+6poADF+npJ739wrR2VvfEH1511kEq23iplvIUJHe8Co3XgvyqXnEK8pK NSBUOLZY36m4GHi3slIi09fqw0UhsmTM5ZlkKd8Igy75zYtkees2TM36H0+kEbJI uExohDDYDOWtRi62/ndS2iAmPOJf3rB2M61cdeQRJFj+bp/hSMy553ocevA0FAaR Oj2HL7A0pmMynwRVAT3kpcGEOTLO05nuIw4lK48by6oc1c8FU2tSiPKORHjS0jRN Fu6sSwkdUC0pMRI0acArlWTKgSMYYF8zM4pkfTT3ayqFST4zlY96H4ueqCQtowkD 1QTRzKtJ+aKBKSBzDGlRZtsCogYsUeKwK8XMG54GU9ysUTSKdKHf+0AcSJZRnSQr Hm+tL9xun8uR9LbtzCvL7po8v50AzKSroez+Yi7h1kjpunDjZe4cIqKNZNP3O/jK WlrSACzufC1M7OVVoA51RaeHttAmHBn0Zr60X9JcI4iHwxB2igqBXDSVxqIyuUOw QBG2sKKXTgpGD7LBIxhn8FKgvFs959PxCZmT6GKiOK38eV308Po= =hhQg -----END PGP SIGNATURE----- --nextPart32716812.Y6vlbWO03M--