Re: [B.A.T.M.A.N.] [B.A.T.M.A.N] OGM problem and documentation
Hello Arthur, On Tue, Jul 03, 2012 at 10:57:28AM +0200, Arthur Lambert wrote: Hi, I am testing Batman Advance (Batman release 2012 1.0) and I am trying to measure signaling on some topology of VMs. I have 81 nodes (Debian, 3.0.9) with KVM virtualization. My topology is something like this : http://imgur.com/Xh1gM I have a topology with an adjacency matrix of maximum 4 as you can see on my screenshot. I record on each VM signaling received and sent. On some VM, my node send OGM at each orig_interval but does not receive any OGM at all. Is it normal ? Well, no. :) Have you checked that the problem is really with batman and not with a layer below (I don't know how you interconnect your VMs, wirefilter/bridges/etc)? You can check using tcpdump on the interface batman is using and see if you have any incoming packets of other nodes. If not, there is most probably something wrong with the interconnect. Moreover, I have found a wonderful documention here : http://gitorious.org/batman-adv-doc. Unfortunatly, it is not maintened since two years. I have also found some papers which describe your protocol, but most of the time, the paper are too old or not correct in the protocol description. At this moment, my first source of information is the code. Can you advise me a good paper or documentation on the architecture and features of Batman Advance set apart your twiki. Well yeah, this documentation is pretty old. I'd suggest to read http://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.pdf which has a nice and (quite) up-to-date introduction to batman-adv included. Furthermore, we try to keep the Wiki as much up to date as possible, if there is something missing feel free to ask. Cheers, Simon signature.asc Description: Digital signature
Re: [B.A.T.M.A.N.] [B.A.T.M.A.N] OGM problem and documentation
Hello, thanks for your answer, This is what I thought.. Its probably a mistake in my script to measure signaling. I will check that. I have already read the document that you give to me. This document discribes most of the features of Batman and some interesting stuffs. But I am looking for information about global architecture, how the protocol handles threads. An example of usefull draw : http://imgur.com/3ecCY. Its not always easy to study or understand a complex project like Batman when you does not know how a ad-hoc protocol works. I am trying for example to follow the execution of the module with tools like LTTNG to see how works the implementation of workqueue or using GCOV to follow the data path. And I interconnect my vm with special way. Its a king of bridge but the tool that I use simulate network topology so it more complicated than that. I will come back problably later to ask questions, but at this moment, I have to many questions, I need first to continue reading the code and twiki, running my tests, ... again and again. Arthur. 2012/7/4 Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de: Hello Arthur, On Tue, Jul 03, 2012 at 10:57:28AM +0200, Arthur Lambert wrote: Hi, I am testing Batman Advance (Batman release 2012 1.0) and I am trying to measure signaling on some topology of VMs. I have 81 nodes (Debian, 3.0.9) with KVM virtualization. My topology is something like this : http://imgur.com/Xh1gM I have a topology with an adjacency matrix of maximum 4 as you can see on my screenshot. I record on each VM signaling received and sent. On some VM, my node send OGM at each orig_interval but does not receive any OGM at all. Is it normal ? Well, no. :) Have you checked that the problem is really with batman and not with a layer below (I don't know how you interconnect your VMs, wirefilter/bridges/etc)? You can check using tcpdump on the interface batman is using and see if you have any incoming packets of other nodes. If not, there is most probably something wrong with the interconnect. Moreover, I have found a wonderful documention here : http://gitorious.org/batman-adv-doc. Unfortunatly, it is not maintened since two years. I have also found some papers which describe your protocol, but most of the time, the paper are too old or not correct in the protocol description. At this moment, my first source of information is the code. Can you advise me a good paper or documentation on the architecture and features of Batman Advance set apart your twiki. Well yeah, this documentation is pretty old. I'd suggest to read http://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.pdf which has a nice and (quite) up-to-date introduction to batman-adv included. Furthermore, we try to keep the Wiki as much up to date as possible, if there is something missing feel free to ask. Cheers, Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/0CvQACgkQrzg/fFk7axYygACfa0uCbrlMDd9bklpcEm3XFnik sq4An09exU1zZWlVF27ybLMVFZyFM8FZ =gIYi -END PGP SIGNATURE-
Re: [B.A.T.M.A.N.] [B.A.T.M.A.N] OGM problem and documentation
Hi, This document discribes most of the features of Batman and some interesting stuffs. But I am looking for information about global architecture, how the protocol handles threads. An example of usefull draw : http://imgur.com/3ecCY. Its not always easy to study or understand a complex project like Batman when you does not know how a ad-hoc protocol works. looking at your drawing I'd say your are more interested in the actual implementation than the protocol. Is that right? Chapter 4 of the mentioned paper explains how the packets travels through the invidual functions and files. Might that be what you are looking for ? Regards, Marek
Re: [B.A.T.M.A.N.] [B.A.T.M.A.N] OGM problem and documentation
Hey Arthur, On Wed, Jul 04, 2012 at 12:00:09PM +0200, Arthur Lambert wrote: Hello, thanks for your answer, This is what I thought.. Its probably a mistake in my script to measure signaling. I will check that. I have already read the document that you give to me. This document discribes most of the features of Batman and some interesting stuffs. But I am looking for information about global architecture, how the protocol handles threads. An example of usefull draw : http://imgur.com/3ecCY. Its not always easy to study or understand a complex project like Batman when you does not know how a ad-hoc protocol works. I am trying for example to follow the execution of the module with tools like LTTNG to see how works the implementation of workqueue or using GCOV to follow the data path. That's pretty interesting! I don't know if we have something like an architecture illustration (but haven't see any recently). If you get anything interesting out of that (illustration, performance insights, etc), please tell us. And I interconnect my vm with special way. Its a king of bridge but the tool that I use simulate network topology so it more complicated than that. Ah ok. Is it a self-written tool or something public? We usually use vde/wirefilter to build up different topologies, see: http://www.open-mesh.org/wiki/open-mesh/Emulation Would be interesting if there are other possibilities :) I will come back problably later to ask questions, but at this moment, I have to many questions, I need first to continue reading the code and twiki, running my tests, ... again and again. Good luck! Cheers Simon signature.asc Description: Digital signature
Re: [B.A.T.M.A.N.] [B.A.T.M.A.N] OGM problem and documentation
Hey again, That's pretty interesting! I don't know if we have something like an architecture illustration (but haven't see any recently). If you get anything interesting out of that (illustration, performance insights, etc), please tell us. I am trying to draw some illustration like the document that I show to you. But I am not sure of the validity of them and there are not finish. I have the first that I show you that is a king of global architecture. I have a Data path which follow the same design of the first. And a third will follow which describe the temporal organization. I have also a first study which measure the signaling of topology like before with different size (4, 9, 36, 25, 36, 49, 81 nodes). I measure the signaling in bytes by seconds on all the topology. And all of this work is also done for an other protocol to compare them. But as I say its to soon to show you something. At this moment, my new way to test is better I think, I want measure the received and sent packets on each node of my topology and not only for all the topology to have a better way to measure the cost of the signaling. Ah ok. Is it a self-written tool or something public? We usually use vde/wirefilter to build up different topologies, see: http://www.open-mesh.org/wiki/open-mesh/Emulation Would be interesting if there are other possibilities :) Yes this tool is Cloonix : http://clownix.net/. You are lucky, you will not find a lot of documentation but its is in English. This tool use a system of socket to encapsulate the flow. But with this tol you have not a wireless network, only wired network. You can also simulate lost packet during communication. I am using this tool because I know the creator of the project so it's really convenient for me to use it. Good luck! Cheers Simon Thank you Arthur.
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hello Guido, On Tue, Jul 03, 2012 at 05:07:17PM -0300, Guido Iribarren wrote: Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help There are some debug levels for BLA as well, and you can now get the claimlist with batctl (which is basically the list of clients a gateway feels responsible for) - this may help for debugging. But first, we should clarify some more details for your setup. Yes, I've seen the cl command, but didn't completely understand how to interpret it. For example, right now I see the clients claimed in the cl of mesh nodes, and even the same client claimed in different nodes. ( when I say mesh nodes, and in the rest of the email, i'm referring to http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-II#Definitions ) i.e. sample mesh-nodes: root@charly:~# batctl cl Claims announced for the mesh bat0 (origcharly, group id 6412) Client VID Originator[o] (CRC ) * 00:25:d3:f5:93:76 on-1 bycharly [x] (77f9) * f8d1113b6e66_eth0 on-1 bycharly [x] (77f9) root@hquilla:~# batctl cl Claims announced for the mesh bat0 (orig hquilla, group id 82cb) Client VID Originator[o] (CRC ) * 00:25:d3:f5:93:76 on-1 by hquilla [x] (c72e) * 00:24:81:4b:ea:6d on-1 by hquilla [x] (c72e) maybe that's fine because they have different group ids? (??) is there any documentation on the cl output? as far i could interpret, CRC identifies a particular version of a table, [o] = [x] means this is claimed by myself group id identifies different backbones (like in this case:) http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-Testcases#Two-LANs-connected-by-one-mesh and VID, is always set to -1 :P oh, mybe it's vlan id (?) since i'm not using VLANs the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758) with this setup, dhcp requests from the mesh sometimes get lost, either they don't reach f8d11504758 or the reply doesn't get out Questions: * which node runs the DHCP server? colmena-casa, f8d11504758 or something else? Only the node f8d11504758 runs a DHCP server (dnsmasq) on its interface br-lan no other dhcp server is running on the network * at which point is DHCP getting lost? is the DISCOVER/REQUEST from the client getting lost, or the reply from the server? Well, I just managed to get a clarifying tcpdump! hquilla sent a select (REQUEST) that reached the wlan0-2 (mesh) interface of f8d11504758 and it was silently dropped (didn't appear on a batctl td of bat0) this repeated several times, until a lucky REQUEST managed to pass through, was sniffed at bat0, and got a reply from dnsmasq I couldn't see any difference between the unlucky and lucky REQUESTs or DISCOVERs, but running a batctl cl -w1 did the trick: when the client is currently claimed by f8d11504758 as in * hquilla_eth0 on-1 by f8d11504758 [x] (d38b) both the REQUESTs and DISCOVERs reach dnsmasq fine but if the client is currently claimed by colmena-casa as in * hquilla_eth0 on-1 by colmena-casa [ ] (3d7f) these discover/requests get dropped by batman when they arrive through wlan0-2 * Can you specify sometimes a little bit more? What are the circumstances, how often does it happen? Well, most of the time :) dhcp clients keep trying and eventually they get the lease, but in unlucky times that might even take hours :( at any point in time, there are lucky clients who can get a lease and renew it without problem, and other unlucky that can't get a reply at all. from what i've just seen at the batctl cl, this luck is related to being claimed by the right backbone node. this didn't happen with batman 2012.1 , setup as indicated by the BLAI wiki page (batctl if add br-lan) furthermore, with batman 2012.2 , BLAII activated, but gw_mode=off in all nodes, DHCP also works fine. Mhm, that's rather strange ... we had a similar problem when ap isolation was activated. Do you have this feature turned on? Nope So DHCP is only having problems when gw-mode is turned on colmena-casa and f8d11504758? gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client on
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 9:43 AM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hello Guido, gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client on every node except f8d11504758, which has gw_mode=server As far as i can recall, disabling gw_mode=client in every mesh node, solved the problem. But now that i found out about this batctl td thing, i'm in doubt about the validity of the previous statement :( i should check again and report. I can now confirm this. if i set gw_mode=off in a particular mesh node, DHCP requests originating from that node work correctly, even when the mesh node client is claimed by the wrong backbone node. in this scenario: * ruth_eth0 on-1 by colmena-casa [ ] (7a27) * hquilla_eth0 on-1 by colmena-casa [ ] (7a27) root@ruth:~# batctl gw off root@ruth:~# /sbin/udhcpc -t 0 -i br-lan:ipv4 -f -R udhcpc (v1.19.4) started Sending discover... Sending select for 10.254.0.131... Lease of 10.254.0.131 obtained, lease time 600 root@hquilla:~# batctl gw client root@hquilla:~# /sbin/udhcpc -t 0 -i br-lan:ipv4 -f -R udhcpc (v1.19.4) started Sending discover... Sending discover... Sending discover...^C when hquilla sends the request, this is received at f8d11504758 interface wlan0-2 BAT colmena-casa f8d11504758: UCAST... and gets dropped (doesn't reach dnsmasq) when ruth (gw_mode=off) sends the request, this is received at f8d11504758 interface wlan0-2 BAT colmena: BCAST, orig ruth, .. (then rebroadcasted several times) and it reaches dnsmasq properly. If you prefer the raw batctl td for some eye-injuring reason, here you go: http://pastebin.com/HNBg01hR hope that helps! Gui
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 04, 2012 at 09:43:13AM -0300, Guido Iribarren wrote: On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hello Guido, On Tue, Jul 03, 2012 at 05:07:17PM -0300, Guido Iribarren wrote: Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help There are some debug levels for BLA as well, and you can now get the claimlist with batctl (which is basically the list of clients a gateway feels responsible for) - this may help for debugging. But first, we should clarify some more details for your setup. Yes, I've seen the cl command, but didn't completely understand how to interpret it. For example, right now I see the clients claimed in the cl of mesh nodes, and even the same client claimed in different nodes. ( when I say mesh nodes, and in the rest of the email, i'm referring to http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-II#Definitions ) i.e. sample mesh-nodes: root@charly:~# batctl cl Claims announced for the mesh bat0 (origcharly, group id 6412) Client VID Originator[o] (CRC ) * 00:25:d3:f5:93:76 on-1 bycharly [x] (77f9) * f8d1113b6e66_eth0 on-1 bycharly [x] (77f9) root@hquilla:~# batctl cl Claims announced for the mesh bat0 (orig hquilla, group id 82cb) Client VID Originator[o] (CRC ) * 00:25:d3:f5:93:76 on-1 by hquilla [x] (c72e) * 00:24:81:4b:ea:6d on-1 by hquilla [x] (c72e) maybe that's fine because they have different group ids? (??) Yup. They are not interconnected via Ethernet, so they are in different backbones and have a different group id. If there are other gatways on the backbone with claims, you should see them in the claim list as well. is there any documentation on the cl output? Yup, you can find it here: http://www.open-mesh.org/wiki/batman-adv/Understand-your-batman-adv-network as far i could interpret, CRC identifies a particular version of a table, yup. [o] = [x] means this is claimed by myself yup. group id identifies different backbones (like in this case:) http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-Testcases#Two-LANs-connected-by-one-mesh yup. and VID, is always set to -1 :P oh, mybe it's vlan id (?) since i'm not using VLANs it means you have no VLAN here. the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758) with this setup, dhcp requests from the mesh sometimes get lost, either they don't reach f8d11504758 or the reply doesn't get out Questions: * which node runs the DHCP server? colmena-casa, f8d11504758 or something else? Only the node f8d11504758 runs a DHCP server (dnsmasq) on its interface br-lan no other dhcp server is running on the network OK. * at which point is DHCP getting lost? is the DISCOVER/REQUEST from the client getting lost, or the reply from the server? Well, I just managed to get a clarifying tcpdump! hquilla sent a select (REQUEST) that reached the wlan0-2 (mesh) interface of f8d11504758 and it was silently dropped (didn't appear on a batctl td of bat0) this repeated several times, until a lucky REQUEST managed to pass through, was sniffed at bat0, and got a reply from dnsmasq I couldn't see any difference between the unlucky and lucky REQUESTs or DISCOVERs, but running a batctl cl -w1 did the trick: when the client is currently claimed by f8d11504758 as in * hquilla_eth0 on-1 by f8d11504758 [x] (d38b) both the REQUESTs and DISCOVERs reach dnsmasq fine but if the client is currently claimed by colmena-casa as in * hquilla_eth0 on-1 by colmena-casa [ ] (3d7f) these discover/requests get dropped by batman when they arrive through wlan0-2 Ah, this helps. If the client is claimed by colmena-case, the request should go from hquilla to colmena-casa via mesh, and from colmena-casa to f8d11504758 via LAN. I guess the problem is the interaction between BLA and the gateway feature. The DHCP request is sent via unicast to f8d11504758, but the destination address is still broadcast. The bla implementation in f8d11504758 will then think that colmena-casa also has received the broadcast (but it didn't), and therefore drop it. I'll
[B.A.T.M.A.N.] [PATCH] batman-adv: check incoming packet type for bla
If the gateway functionality is used, some broadcast packets (DHCP
requests) may be transmitted as unicast packets. As the bridge loop
avoidance code now only considers the payload Ethernet destination,
it may drop the DHCP request for clients which are claimed by other
backbone gateways, because it falsely infers from the broadcast address
that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used
for transmission.
Reported-by: Guido Iribarren guidoiribar...@buenosaireslibre.org
Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
---
bridge_loop_avoidance.c |6 --
bridge_loop_avoidance.h |5 +++--
soft-interface.c|6 +-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 6452e2f..8478083 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -1368,6 +1368,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv)
/* @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
+ * @is_bcast: the packet came in a broadcast packet type
*
* bla_rx avoidance checks if:
* * we have to race for a claim
@@ -1377,7 +1378,8 @@ void batadv_bla_free(struct batadv_priv *bat_priv)
* returns 1, otherwise it returns 0 and the caller shall further
* process the skb.
*/
-int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid)
+int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast)
{
struct ethhdr *ethhdr;
struct batadv_claim search_claim, *claim = NULL;
@@ -1422,7 +1424,7 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct
sk_buff *skb, short vid)
}
/* if it is a broadcast ... */
- if (is_multicast_ether_addr(ethhdr-h_dest)) {
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast) {
/* ... drop it. the responsible gateway is in charge. */
goto handled;
} else {
diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h
index 35d39e3..789cb73 100644
--- a/bridge_loop_avoidance.h
+++ b/bridge_loop_avoidance.h
@@ -21,7 +21,8 @@
#define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA
-int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short
vid);
+int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast);
int batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, short
vid);
int batadv_bla_is_backbone_gw(struct sk_buff *skb,
struct batadv_orig_node *orig_node, int hdr_size);
@@ -42,7 +43,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv);
#else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int batadv_bla_rx(struct batadv_priv *bat_priv,
- struct sk_buff *skb, short vid)
+ struct sk_buff *skb, short vid, bool is_bcast)
{
return 0;
}
diff --git a/soft-interface.c b/soft-interface.c
index 96736ea..be39f89 100644
--- a/soft-interface.c
+++ b/soft-interface.c
@@ -274,9 +274,13 @@ void batadv_interface_rx(struct net_device *soft_iface,
struct batadv_priv *bat_priv = netdev_priv(soft_iface);
struct ethhdr *ethhdr;
struct vlan_ethhdr *vhdr;
+ struct batadv_header *batadv_header = (struct batadv_header *)skb-data;
short vid __maybe_unused = -1;
+ bool is_bcast;
__be16 ethertype = __constant_htons(BATADV_ETH_P_BATMAN);
+ is_bcast = !!(batadv_header-packet_type == BATADV_BCAST);
+
/* check if enough space is available for pulling, and pull */
if (!pskb_may_pull(skb, hdr_size))
goto dropped;
@@ -323,7 +327,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
/* Let the bridge loop avoidance check the packet. If will
* not handle it, we can safely push it up.
*/
- if (batadv_bla_rx(bat_priv, skb, vid))
+ if (batadv_bla_rx(bat_priv, skb, vid, is_bcast))
goto out;
netif_rx(skb);
--
1.7.10
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
Hey Guido, thanks again for the good debugging, that really helped to understand the problem :) I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes. Cheers Simon signature.asc Description: Digital signature
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 11:05 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hey Guido, thanks again for the good debugging, that really helped to understand the problem :) Thanks free software! :D I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes. Definitely! here's the output, tho: Applying ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c Hunk #1 succeeded at 1351 with fuzz 1 (offset -17 lines). Hunk #2 FAILED at 1378. Hunk #3 FAILED at 1423. 2 out of 3 hunks FAILED -- saving rejects to file bridge_loop_avoidance.c.rej patching file bridge_loop_avoidance.h Hunk #1 FAILED at 21. Hunk #2 FAILED at 42. 2 out of 2 hunks FAILED -- saving rejects to file bridge_loop_avoidance.h.rej patching file soft-interface.c Hunk #1 FAILED at 274. Hunk #2 FAILED at 323. 2 out of 2 hunks FAILED -- saving rejects to file soft-interface.c.rej Patch failed! Please fix ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch! i'm trying to apply against openwrt@torvic:~/trunk/feeds/packages/net/batman-adv$ svn info Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32587 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32579 Last Changed Date: 2012-07-02 13:20:20 -0300 (Mon, 02 Jul 2012) Visually inspecting the rejects, seems my source code still doesn't have the batadv_ prefix in functions names. i.e.: int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) I've seen many patches flying around dealing with the batadv_ prefix for dave, but didn't pay much attention to them: which of those should i grab? Or, Simon, could you kindly send another patch that i can apply cleanly to r32587 of svn://svn.openwrt.org/openwrt/packages/net/batman-adv in any case, i see the changes are simple, so i *could* try a manual apply of the patch... but last time i tried (with other patch), it got overwritten by openwrt build system. Thanks a lot for the support! Gui Cheers Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/0TYwACgkQrzg/fFk7axbznwCg5oyyF4UaWJBV8GXztFSGG8sa vnAAoJYcgNuCcdA5fZKrIvaUE888FzSI =zd3Q -END PGP SIGNATURE-
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
Sorry, my fault. Will send a patch based on maint in a minute. On Wed, Jul 04, 2012 at 03:12:59PM -0300, Guido Iribarren wrote: On Wed, Jul 4, 2012 at 11:05 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hey Guido, thanks again for the good debugging, that really helped to understand the problem :) Thanks free software! :D I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes. Definitely! here's the output, tho: Applying ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c Hunk #1 succeeded at 1351 with fuzz 1 (offset -17 lines). Hunk #2 FAILED at 1378. Hunk #3 FAILED at 1423. 2 out of 3 hunks FAILED -- saving rejects to file bridge_loop_avoidance.c.rej patching file bridge_loop_avoidance.h Hunk #1 FAILED at 21. Hunk #2 FAILED at 42. 2 out of 2 hunks FAILED -- saving rejects to file bridge_loop_avoidance.h.rej patching file soft-interface.c Hunk #1 FAILED at 274. Hunk #2 FAILED at 323. 2 out of 2 hunks FAILED -- saving rejects to file soft-interface.c.rej Patch failed! Please fix ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch! i'm trying to apply against openwrt@torvic:~/trunk/feeds/packages/net/batman-adv$ svn info Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32587 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32579 Last Changed Date: 2012-07-02 13:20:20 -0300 (Mon, 02 Jul 2012) Visually inspecting the rejects, seems my source code still doesn't have the batadv_ prefix in functions names. i.e.: int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) I've seen many patches flying around dealing with the batadv_ prefix for dave, but didn't pay much attention to them: which of those should i grab? Or, Simon, could you kindly send another patch that i can apply cleanly to r32587 of svn://svn.openwrt.org/openwrt/packages/net/batman-adv in any case, i see the changes are simple, so i *could* try a manual apply of the patch... but last time i tried (with other patch), it got overwritten by openwrt build system. Thanks a lot for the support! Gui Cheers Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/0TYwACgkQrzg/fFk7axbznwCg5oyyF4UaWJBV8GXztFSGG8sa vnAAoJYcgNuCcdA5fZKrIvaUE888FzSI =zd3Q -END PGP SIGNATURE- signature.asc Description: Digital signature
[B.A.T.M.A.N.] [PATCH-maint] batman-adv: check incoming packet type for bla
If the gateway functionality is used, some broadcast packets (DHCP
requests) may be transmitted as unicast packets. As the bridge loop
avoidance code now only considers the payload Ethernet destination,
it may drop the DHCP request for clients which are claimed by other
backbone gateways, because it falsely infers from the broadcast address
that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used
for transmission.
Reported-by: Guido Iribarren guidoiribar...@buenosaireslibre.org
Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
---
PATCHv2 adds a comment why we are doing this, and adds the is_bcast
check to the other is_multicast_ether_addr() check in this function.
PATCH-maint is the backport for maint
---
bridge_loop_avoidance.c | 15 +++
bridge_loop_avoidance.h |5 +++--
soft-interface.c|6 +-
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 8bf9751..2b82a0f 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -1351,6 +1351,7 @@ void bla_free(struct bat_priv *bat_priv)
* @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
+ * @is_bcast: the packet came in a broadcast packet type.
*
* bla_rx avoidance checks if:
* * we have to race for a claim
@@ -1361,7 +1362,8 @@ void bla_free(struct bat_priv *bat_priv)
* process the skb.
*
*/
-int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
+int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast)
{
struct ethhdr *ethhdr;
struct claim search_claim, *claim = NULL;
@@ -1380,7 +1382,7 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff
*skb, short vid)
if (unlikely(atomic_read(bat_priv-bla_num_requests)))
/* don't allow broadcasts while requests are in flight */
- if (is_multicast_ether_addr(ethhdr-h_dest))
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast)
goto handled;
memcpy(search_claim.addr, ethhdr-h_source, ETH_ALEN);
@@ -1406,8 +1408,13 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff
*skb, short vid)
}
/* if it is a broadcast ... */
- if (is_multicast_ether_addr(ethhdr-h_dest)) {
- /* ... drop it. the responsible gateway is in charge. */
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast) {
+ /* ... drop it. the responsible gateway is in charge.
+*
+* We need to check is_bcast because with the gateway
+* feature, broadcasts (like DHCP requests) may be sent
+* using a unicast packet type.
+*/
goto handled;
} else {
/* seems the client considers us as its best gateway.
diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h
index e39f93a..dc5227b 100644
--- a/bridge_loop_avoidance.h
+++ b/bridge_loop_avoidance.h
@@ -23,7 +23,8 @@
#define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA
-int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
+int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast);
int bla_tx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
int bla_is_backbone_gw(struct sk_buff *skb,
struct orig_node *orig_node, int hdr_size);
@@ -41,7 +42,7 @@ void bla_free(struct bat_priv *bat_priv);
#else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb,
-short vid)
+short vid, bool is_bcast)
{
return 0;
}
diff --git a/soft-interface.c b/soft-interface.c
index 6e2530b..92a4070 100644
--- a/soft-interface.c
+++ b/soft-interface.c
@@ -256,7 +256,11 @@ void interface_rx(struct net_device *soft_iface,
struct bat_priv *bat_priv = netdev_priv(soft_iface);
struct ethhdr *ethhdr;
struct vlan_ethhdr *vhdr;
+ struct batman_header *batadv_header = (struct batman_header *)skb-data;
short vid __maybe_unused = -1;
+ bool is_bcast;
+
+ is_bcast = !!(batadv_header-packet_type == BAT_BCAST);
/* check if enough space is available for pulling, and pull */
if (!pskb_may_pull(skb, hdr_size))
@@ -302,7 +306,7 @@ void interface_rx(struct net_device *soft_iface,
/* Let the bridge loop avoidance check the packet. If will
* not handle it, we can safely push it up.
*/
- if (bla_rx(bat_priv, skb, vid))
+ if (bla_rx(bat_priv, skb, vid, is_bcast))
goto out;
netif_rx(skb);
--
1.7.10
[B.A.T.M.A.N.] [PATCH-maint-v2] batman-adv: check incoming packet type for bla
If the gateway functionality is used, some broadcast packets (DHCP
requests) may be transmitted as unicast packets. As the bridge loop
avoidance code now only considers the payload Ethernet destination,
it may drop the DHCP request for clients which are claimed by other
backbone gateways, because it falsely infers from the broadcast address
that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used
for transmission.
Reported-by: Guido Iribarren guidoiribar...@buenosaireslibre.org
Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
---
PATCHv2 adds a comment why we are doing this, and adds the is_bcast
check to the other is_multicast_ether_addr() check in this function.
PATCH-maint is the backport for maint
PATCH-maint-v2 is even checkpatch clean, and remove obsolete !!
---
bridge_loop_avoidance.c | 15 +++
bridge_loop_avoidance.h |5 +++--
soft-interface.c|6 +-
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 8bf9751..c5863f4 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -1351,6 +1351,7 @@ void bla_free(struct bat_priv *bat_priv)
* @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
+ * @is_bcast: the packet came in a broadcast packet type.
*
* bla_rx avoidance checks if:
* * we have to race for a claim
@@ -1361,7 +1362,8 @@ void bla_free(struct bat_priv *bat_priv)
* process the skb.
*
*/
-int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
+int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast)
{
struct ethhdr *ethhdr;
struct claim search_claim, *claim = NULL;
@@ -1380,7 +1382,7 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff
*skb, short vid)
if (unlikely(atomic_read(bat_priv-bla_num_requests)))
/* don't allow broadcasts while requests are in flight */
- if (is_multicast_ether_addr(ethhdr-h_dest))
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast)
goto handled;
memcpy(search_claim.addr, ethhdr-h_source, ETH_ALEN);
@@ -1406,8 +1408,13 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff
*skb, short vid)
}
/* if it is a broadcast ... */
- if (is_multicast_ether_addr(ethhdr-h_dest)) {
- /* ... drop it. the responsible gateway is in charge. */
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast) {
+ /* ... drop it. the responsible gateway is in charge.
+*
+* We need to check is_bcast because with the gateway
+* feature, broadcasts (like DHCP requests) may be sent
+* using a unicast packet type.
+*/
goto handled;
} else {
/* seems the client considers us as its best gateway.
diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h
index e39f93a..dc5227b 100644
--- a/bridge_loop_avoidance.h
+++ b/bridge_loop_avoidance.h
@@ -23,7 +23,8 @@
#define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA
-int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
+int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast);
int bla_tx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
int bla_is_backbone_gw(struct sk_buff *skb,
struct orig_node *orig_node, int hdr_size);
@@ -41,7 +42,7 @@ void bla_free(struct bat_priv *bat_priv);
#else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb,
-short vid)
+short vid, bool is_bcast)
{
return 0;
}
diff --git a/soft-interface.c b/soft-interface.c
index 6e2530b..a0ec0e4 100644
--- a/soft-interface.c
+++ b/soft-interface.c
@@ -256,7 +256,11 @@ void interface_rx(struct net_device *soft_iface,
struct bat_priv *bat_priv = netdev_priv(soft_iface);
struct ethhdr *ethhdr;
struct vlan_ethhdr *vhdr;
+ struct batman_header *batadv_header = (struct batman_header *)skb-data;
short vid __maybe_unused = -1;
+ bool is_bcast;
+
+ is_bcast = (batadv_header-packet_type == BAT_BCAST);
/* check if enough space is available for pulling, and pull */
if (!pskb_may_pull(skb, hdr_size))
@@ -302,7 +306,7 @@ void interface_rx(struct net_device *soft_iface,
/* Let the bridge loop avoidance check the packet. If will
* not handle it, we can safely push it up.
*/
- if (bla_rx(bat_priv, skb, vid))
+ if (bla_rx(bat_priv, skb, vid, is_bcast))
goto out;
netif_rx(skb);
--
1.7.10
[B.A.T.M.A.N.] [PATCH-v2] batman-adv: check incoming packet type for bla
If the gateway functionality is used, some broadcast packets (DHCP
requests) may be transmitted as unicast packets. As the bridge loop
avoidance code now only considers the payload Ethernet destination,
it may drop the DHCP request for clients which are claimed by other
backbone gateways, because it falsely infers from the broadcast address
that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used
for transmission.
Reported-by: Guido Iribarren guidoiribar...@buenosaireslibre.org
Signed-off-by: Simon Wunderlich s...@hrz.tu-chemnitz.de
---
PATCHv2 adds a comment why we are doing this, and adds the is_bcast
check to the other is_multicast_ether_addr() check in this function,
and remove obsolete !!.
---
bridge_loop_avoidance.c | 15 +++
bridge_loop_avoidance.h |5 +++--
soft-interface.c|6 +-
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 6452e2f..1af7af5 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -1368,6 +1368,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv)
/* @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
+ * @is_bcast: the packet came in a broadcast packet type.
*
* bla_rx avoidance checks if:
* * we have to race for a claim
@@ -1377,7 +1378,8 @@ void batadv_bla_free(struct batadv_priv *bat_priv)
* returns 1, otherwise it returns 0 and the caller shall further
* process the skb.
*/
-int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid)
+int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast)
{
struct ethhdr *ethhdr;
struct batadv_claim search_claim, *claim = NULL;
@@ -1396,7 +1398,7 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct
sk_buff *skb, short vid)
if (unlikely(atomic_read(bat_priv-bla_num_requests)))
/* don't allow broadcasts while requests are in flight */
- if (is_multicast_ether_addr(ethhdr-h_dest))
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast)
goto handled;
memcpy(search_claim.addr, ethhdr-h_source, ETH_ALEN);
@@ -1422,8 +1424,13 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct
sk_buff *skb, short vid)
}
/* if it is a broadcast ... */
- if (is_multicast_ether_addr(ethhdr-h_dest)) {
- /* ... drop it. the responsible gateway is in charge. */
+ if (is_multicast_ether_addr(ethhdr-h_dest) is_bcast) {
+ /* ... drop it. the responsible gateway is in charge.
+*
+* We need to check is_bcast because with the gateway
+* feature, broadcasts (like DHCP requests) may be sent
+* using a unicast packet type.
+*/
goto handled;
} else {
/* seems the client considers us as its best gateway.
diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h
index 35d39e3..789cb73 100644
--- a/bridge_loop_avoidance.h
+++ b/bridge_loop_avoidance.h
@@ -21,7 +21,8 @@
#define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA
-int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short
vid);
+int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast);
int batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, short
vid);
int batadv_bla_is_backbone_gw(struct sk_buff *skb,
struct batadv_orig_node *orig_node, int hdr_size);
@@ -42,7 +43,7 @@ void batadv_bla_free(struct batadv_priv *bat_priv);
#else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int batadv_bla_rx(struct batadv_priv *bat_priv,
- struct sk_buff *skb, short vid)
+ struct sk_buff *skb, short vid, bool is_bcast)
{
return 0;
}
diff --git a/soft-interface.c b/soft-interface.c
index 96736ea..ae7d23e 100644
--- a/soft-interface.c
+++ b/soft-interface.c
@@ -274,9 +274,13 @@ void batadv_interface_rx(struct net_device *soft_iface,
struct batadv_priv *bat_priv = netdev_priv(soft_iface);
struct ethhdr *ethhdr;
struct vlan_ethhdr *vhdr;
+ struct batadv_header *batadv_header = (struct batadv_header *)skb-data;
short vid __maybe_unused = -1;
+ bool is_bcast;
__be16 ethertype = __constant_htons(BATADV_ETH_P_BATMAN);
+ is_bcast = (batadv_header-packet_type == BATADV_BCAST);
+
/* check if enough space is available for pulling, and pull */
if (!pskb_may_pull(skb, hdr_size))
goto dropped;
@@ -323,7 +327,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
/* Let the bridge loop
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 3:30 PM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Sorry, my fault. Will send a patch based on maint in a minute. Applying ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c patching file bridge_loop_avoidance.h patching file soft-interface.c Now i'm having fun, heh Thanks! Gui
[B.A.T.M.A.N.] tt log
Hi Antonio I encountered the tt loop in kvm this evening, so I captured some tiny logs for you. The topology is a small chain: n1 - n2 - n3 - n4 The nodes run clean batman-adv from master (5deb69f60f388055982a1da6dce876049f86841d) with no catwoman or whatever compiled in :) -- Kind Regards Martin Hundebøll Frederiks Allé 99A, 1.th 8000 Aarhus C Denmark +45 61 65 54 61 mar...@hundeboll.net root@n1:/# [ 17.980968] batman_adv: bat0: Adding interface: eth0 [ 17.982191] batman_adv: bat0: Interface activated: eth0 [ 18.109976] batman_adv: bat0: fragmentation: Changing from: enabled to: disabled [ 18.112955] batman_adv: bat0: log_level: Changing from: 0 to: 4 root@n1:/# batctl log [4294688626] Creating new global tt entry: 5a:9b:03:86:07:21 (via fe:fe:00:0a:02:01) [4294690286] Creating new global tt entry: a2:8d:c2:0e:e8:80 (via fe:fe:00:0a:03:01) [4294690316] Routing TT_RESPONSE to n3 [.] [4294690326] Routing TT_RESPONSE to n3 [.] [4294690326] Routing TT_RESPONSE to n3 [.] [4294690326] Routing TT_RESPONSE to n3 [.] [4294690326] Routing TT_RESPONSE to n3 [.] [4294690336] Routing TT_RESPONSE to n3 [.] [4294690336] Routing TT_RESPONSE to n3 [.] [4294690336] Routing TT_RESPONSE to n3 [.] [4294690336] Routing TT_RESPONSE to n3 [.] [4294690336] Routing TT_RESPONSE to n3 [.] [4294690336] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690346] Routing TT_RESPONSE to n3 [.] [4294690356] Routing TT_RESPONSE to n3 [.] [4294690356] Routing TT_RESPONSE to n3 [.] [4294692416] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692426] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692436] Routing TT_RESPONSE to n4 [.] [4294692736] TT inconsistency for fe:fe:00:0a:04:01. Need to retrieve the correct information (ttvn: 1 last_ttvn: 0 crc: 47084 last_crc: 0 num_changes: 0) [4294692736] Sending TT_REQUEST to n4 via n2 [.] a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new global tt entry: b6:95:47:cf:29:75 (via fe:fe:00:0a:04:01) [4294692786] Received TT_RESPONSE from n4 for ttvn 1 t_size: 1 [.] [4294692786] Creating new
