Re: [B.A.T.M.A.N.] pull request [net]: batman-adv 20160216
On Fri, Feb 19, 2016 at 03:37:18PM -0500, David Miller wrote: > And thanks for the heads up about the potential merge issues, I'll watch > for that. > Hi David, actually I just realized that the patches that will create the conflict are not yet in net-next, but they are still pending in my queue. At this point I will wait for you to merge net into net-next first (there should be no conflict at that point) and then I will rebase my pending patches on top of that. This should prevent you from dealing with any conflict. Regards, -- Antonio Quartulli signature.asc Description: Digital signature
Re: [B.A.T.M.A.N.] Unsigned integer overflow in batadv_iv_ogm_calc_tq
On Mon, Feb 15, 2016 at 01:35:31PM +0100, Sven Eckelmann wrote: > It is easy to see that > > batadv_ogm_packet::tq (u8 255) * > tq_own (u8 255) * > tq_asym_penalty (int 134) * > tq_iface_penalty (int 255) > > is outside the range of an signed integer (32 bit). The maximum seen > here is 255 for each entry. So should tq_iface_penalty + > tq_iface_penalty, inv_asym_penalty be changed to unsigned int? Given that all these values are in the TQ domain I'd say that they should all be positive all the time, therefore there is no gain in using a signed variable here. Marek, what do you think ? Cheers, -- Antonio Quartulli signature.asc Description: Digital signature
Re: [B.A.T.M.A.N.] pull request [net]: batman-adv 20160216
From: Antonio Quartulli Date: Tue, 16 Feb 2016 23:01:25 +0800 > this pull request is intended for net. > > Two of the fixes included in this patchset prevent a wrong memory > access - it was triggered when removing an object from a list > after it was already free'd due to bad reference counting. > This misbehaviour existed for both the gw_node and the > orig_node_vlan object and has been fixed by Sven Eckelmann. > > The last patch fixes our interface feasibility check and prevents > it from looping indefinitely when two net_device objects > reference each other via iflink index (i.e. veth pair), by > Andrew Lunn Pulled, thanks Antonio. And thanks for the heads up about the potential merge issues, I'll watch for that.
Re: [B.A.T.M.A.N.] Still looping packets in bla setup
Hi Andreas, On Friday 19 February 2016 11:58:47 Andreas Pape wrote: > Hello Simon, > > I'm still working with my IT department to be able to send the patches in > a way compliant to the documentation provided by Sven. In the meantime I > reworked the patches, but I am still struggling with the e-mail client > issue. > Nevertheless if I apply all the patches I sent earlier (except Patch 4/4 > as it was meaningless) I still have 3 problems : > 1. I have sometimes looping unicast packets in the direction backbone -> > mesh -> backbone. Dropping all unicast traffic received from another > backbone gw and destined to be forwarded to the backbone again as you > suggested this in an earlier mail solves this issue. Shall I provide an > according patch? I think that is a good idea. > Shall I add a "Suggested-by" referring to you? If you want, you can add a "Reported-by", although I don't need any credit here. I don't know if there is something like Suggested-by in Linux. > I feel a > little bit uncomforable with this patch as it seems to be something more > like a workaround. Well, we also drop the broadcast traffic when it comes from another backbone. So I don't think this is a workaround. BLA consists of a lot of rules after all ... > The question I cannot answer yet is why the other > backbone gws send traffic via the mesh which could be sent via the > backbone? That is a good quesiton indeed. I think this can only be answered if you inspect the unicast packet and its source and destination as well as translation table state and bridge port state (brctl showmacs). This might give a clue what is going on ... If its not a DAT packet, that is. > 2. Although having the patch for 1. applied, the backbone gateways send > claim frames for the devices of their own backbone in rare cases from time > to time. I could send a patch for this as it is rather easy to check with > the help of the local tt table (batadv_is_my_client) if it is reasonable > to send a claim frame for these devices. Again, this patch looks more like > a workaround to me as I also cannot explain what really triggers the > generation of these claim frames. I don't think this is the right way to solve it - if a client has roamed to another device in the mesh, a gateway MUST send a claim. However batadv_is_my_client would probably return true, suggesting that the client is local although it is not local anymore. The problem probably needs to be fixed somewhere else. > 3. I see again in rare cases looping multicasts for traffic > mesh->backbone->mesh. If I look at the bla debug messages in these cases I > see, that a backbone gw holding the claim for the source of the multicast > frame thinks that the client belonging to the source address has "roamed" > from another mesh node into the backbone network although it didn't. From > this I conclude that another backbone gw has forwarded the multicast into > the backbone although it shoudn't have done this (having found no claim > for the client or erroneously also holding a claim). In this case the > backbone gateways seem to be out-of-sync about the actual claim status for > that client. This effect only lasts a very short time, as the gateway > which found the "roaming" client unclaims it and within a few milliseconds > (depending on the traffic generated by the client) another backbone gw (or > the same) claims the client again. Of course then the looping of the > multicast traffic from the client stops. In my case the sender of the > multicast was the bridge interface br0 of a remote mesh node itself. The > bat0 softinterface was added to that bridge. The looping multicast then > gave me a "bat0: received packet with own address as source address" > message. Furthermore that bat0 interface sent a claim frame for the mac of > the own bridge (whch is obvious as bat0 received a message from the mesh > with a mac address not claimed yet). This claim frame then produces > another "bat0: received packet ..." message. > I currently have no workaround for this 3rd issue as all I can image to > prevent this will break the "roaming client" scenario for bla. I could > even live with this problem as it happens quite seldomly and as it is > "self-healing", but it tells my that there might be a sync issue. Do you > think that my 1st and 2nd point could also relate to the same problem? > In the meantime I looked through the code for hours but I am not able to > find something that could explain the observed problem. Hmm ... that sounds strange. I don't know if this is related to the your first two points since we are talking about multicast here and the other points were about unicast. I think the main question here is - if the packet came from the mesh, why wasn't there a claim frame? Maybe two questions could help: * does this happen in the first minutes after starting/restarting the mesh? There is some initial time for bla gateway nodes to detect each other, although this should
[B.A.T.M.A.N.] Still looping packets in bla setup
Hello Simon, I'm still working with my IT department to be able to send the patches in a way compliant to the documentation provided by Sven. In the meantime I reworked the patches, but I am still struggling with the e-mail client issue. Nevertheless if I apply all the patches I sent earlier (except Patch 4/4 as it was meaningless) I still have 3 problems : 1. I have sometimes looping unicast packets in the direction backbone -> mesh -> backbone. Dropping all unicast traffic received from another backbone gw and destined to be forwarded to the backbone again as you suggested this in an earlier mail solves this issue. Shall I provide an according patch? Shall I add a "Suggested-by" referring to you? I feel a little bit uncomforable with this patch as it seems to be something more like a workaround. The question I cannot answer yet is why the other backbone gws send traffic via the mesh which could be sent via the backbone? 2. Although having the patch for 1. applied, the backbone gateways send claim frames for the devices of their own backbone in rare cases from time to time. I could send a patch for this as it is rather easy to check with the help of the local tt table (batadv_is_my_client) if it is reasonable to send a claim frame for these devices. Again, this patch looks more like a workaround to me as I also cannot explain what really triggers the generation of these claim frames. 3. I see again in rare cases looping multicasts for traffic mesh->backbone->mesh. If I look at the bla debug messages in these cases I see, that a backbone gw holding the claim for the source of the multicast frame thinks that the client belonging to the source address has "roamed" from another mesh node into the backbone network although it didn't. From this I conclude that another backbone gw has forwarded the multicast into the backbone although it shoudn't have done this (having found no claim for the client or erroneously also holding a claim). In this case the backbone gateways seem to be out-of-sync about the actual claim status for that client. This effect only lasts a very short time, as the gateway which found the "roaming" client unclaims it and within a few milliseconds (depending on the traffic generated by the client) another backbone gw (or the same) claims the client again. Of course then the looping of the multicast traffic from the client stops. In my case the sender of the multicast was the bridge interface br0 of a remote mesh node itself. The bat0 softinterface was added to that bridge. The looping multicast then gave me a "bat0: received packet with own address as source address" message. Furthermore that bat0 interface sent a claim frame for the mac of the own bridge (whch is obvious as bat0 received a message from the mesh with a mac address not claimed yet). This claim frame then produces another "bat0: received packet ..." message. I currently have no workaround for this 3rd issue as all I can image to prevent this will break the "roaming client" scenario for bla. I could even live with this problem as it happens quite seldomly and as it is "self-healing", but it tells my that there might be a sync issue. Do you think that my 1st and 2nd point could also relate to the same problem? In the meantime I looked through the code for hours but I am not able to find something that could explain the observed problem. Kind regards, Andreas .. PHOENIX CONTACT ELECTRONICS GmbH Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont USt-Id-Nr.: DE811742156 Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528 Geschäftsführer / Executive Board: Roland Bent, Dr. Martin Heubeck ___ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___
