Hi,
starting batmand, the daemon sometimes doesn't seem to recognize the network the right way.
root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 ------------------------------------------------------- This is a tcpdump from a neighbor node:
root@ap14:~# tcpdump -i eth0 src 192.168.42.25 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 05:12:09.512310 arp who-has 192.168.43.255 tell 192.168.42.25 05:12:10.512178 arp who-has 192.168.43.255 tell 192.168.42.25 05:12:11.699795 arp who-has 192.168.43.255 tell 192.168.42.25
------------------------------------------- on the other node: root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 root@25:~#
---------------------------------------------- tcpdump:
05:12:28.621940 IP 192.168.42.25.4305 > 192.168.43.255.4305: UDP, length 20 05:12:28.873246 IP 192.168.42.25.4305 > 192.168.43.255.4305: UDP, length 25 05:12:28.892343 IP 192.168.42.25.4305 > 192.168.43.255.4305: UDP, length 15
now batmand is running successfully.
Any Ideas?
regards, Rene
Hi,
On Dienstag 20 November 2007, rene wrote:
Hi,
starting batmand, the daemon sometimes doesn't seem to recognize the network the right way.
root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255
on the other node: root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 root@25:~#
What is definitively not correct is that your capture indicates 4 times the same IP address (192.168.42.25) on 4 different interfaces. Can you check whether your capture, the alias-interface configuration (what is the output of ip a ?), or the daemon is wrong? There MUST be a different IP address for each BATMAN interface in the network (also if a single BATMAN node has more than one interface). All BATMAN interfaces SHOULD have the same netmask and broadcast address.
ciao, axel
Hi,
Axel Neumann wrote:
Hi,
On Dienstag 20 November 2007, rene wrote:
Hi,
starting batmand, the daemon sometimes doesn't seem to recognize the network the right way.
root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255
on the other node: root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 root@25:~#
What is definitively not correct is that your capture indicates 4 times the same IP address (192.168.42.25) on 4 different interfaces.
This is two times the same node, first time it recognizes the broadcast the right way, second time not.
There MUST be a different IP address for each BATMAN interface in the network (also if a single BATMAN node has more than one interface).
Is this implemented like this (where?)? Can't work BATMAN with the interfaces (or can't we change it to work this way), it would make the whole configuration much easier to assign to every node only one single IP address (or two, one for olsr and ne for BATMAN)? We are doing this with olsr and this really makes the network-structure much cleaner - every node has one IP.
Is the described problem with the misconfigured broadcast related to the 'same IP on different interfaces' issue?
regards, Rene
Hi,
05:12:09.512310 arp who-has 192.168.43.255 tell 192.168.42.25 05:12:10.512178 arp who-has 192.168.43.255 tell 192.168.42.25
These ARP request are not issued by BATMAN itself. BATMAN does only send broadcast packets - your system creates these requests.
This is two times the same node, first time it recognizes the broadcast the right way, second time not.
BATMAN askes the system for the IP and broadcast addresses. In both cases the system responds with the same answer. I don't see much difference from batmans point of view.
Is this implemented like this (where?)? Can't work BATMAN with the interfaces (or can't we change it to work this way), it would make the whole configuration much easier to assign to every node only one single IP address (or two, one for olsr and ne for BATMAN)? We are doing this with olsr and this really makes the network-structure much cleaner - every node has one IP.
You have multihomed OLSR nodes with a single IP and that works ? Can anyone of the OLSR folks say something about that ? I can't imagine how the routing daemon can distinguish 2 distinct connections with the same address ...
Regards, Marek
Hi,
Marek Lindner wrote:
Hi,
05:12:09.512310 arp who-has 192.168.43.255 tell 192.168.42.25 05:12:10.512178 arp who-has 192.168.43.255 tell 192.168.42.25
These ARP request are not issued by BATMAN itself. BATMAN does only send broadcast packets - your system creates these requests.
This is two times the same node, first time it recognizes the broadcast the right way, second time not.
BATMAN askes the system for the IP and broadcast addresses. In both cases the system responds with the same answer. I don't see much difference from batmans point of view.
But thats definitely whats happening, on OpenWrt WRAP (x86) as well as on BroadCom (mipsel). It happened more than once, and the only thing what was done to change the behavior was killing and starting batmand again. Which doesn't changed every time the behavior.
You have multihomed OLSR nodes with a single IP and that works ? Can anyone of the OLSR folks say something about that ? I can't imagine how the routing daemon can distinguish 2 distinct connections with the same address ...
Works perfect, we use for instance the WRAP-boards in our network with two WIFI- and one LAN-Interface, all three having the same IP. The related patch is at http://titan.www.opennet-initiative.de/olsrd_patches/mipip.patch, but its since a while part of olsrd.
Regards, Rene
Hi,
Works perfect, we use for instance the WRAP-boards in our network with two WIFI- and one LAN-Interface, all three having the same IP. The related patch is at http://titan.www.opennet-initiative.de/olsrd_patches/mipip.patch, but its since a while part of olsrd.
I read the patch and without knowing the olsrd code I would say that you operate on interface names instead of IPs. But I see some problems here: - How does this work in a mixed environment ? - More important: The routing table operates on IP addresses and not on interface names. Even if olsrd can distinguish your interfaces by name the kernel can't.
Imagine: You have a node A with 2 Interfaces and node B can hear both interfaces but one better than the other. The routing table entry would look like that "<destination> via IP_of_node_A" whereas the kernel can't send the packet to a distinct interface of A. Whatever interface of A responds first to your ARP query will get all data packets and thus you may end up with using lossy links.
I don't see anything to solve that in this patch.
Regards, Marek
Hi,
Marek Lindner wrote:
- More important: The routing table operates on IP addresses and not on
interface names. Even if olsrd can distinguish your interfaces by name the kernel can't.
sure? (I'm in no way an expert, its an honest question.) root@OpenWrt:~# ip route 192.168.1.48 via 192.168.1.188 dev ath1 metric 7 192.168.2.40 via 192.168.1.188 dev ath1 metric 6 192.168.1.49 via 192.168.1.188 dev ath1 metric 4 192.168.2.42 via 192.168.1.188 dev ath1 metric 7 192.168.1.51 via 192.168.2.172 dev eth0 metric 2 192.168.1.53 via 192.168.1.188 dev ath1 metric 6 192.168.1.56 via 192.168.1.188 dev ath1 metric 6 192.168.2.32 via 192.168.1.188 dev ath1 metric 7 192.168.1.57 via 192.168.1.188 dev ath1 metric 6 192.168.2.33 via 192.168.1.188 dev ath1 metric 8 192.168.1.58 via 192.168.1.188 dev ath1 metric 3 192.168.1.60 via 192.168.1.188 dev ath1 metric 7 ....
so there are interfaces shown in the routes, the kernel should recognize them, what else they are for?
Imagine: You have a node A with 2 Interfaces and node B can hear both interfaces but one better than the other. The routing table entry would look like that "<destination> via IP_of_node_A" whereas the kernel can't send the packet to a distinct interface of A.
see above...
regards, Rene
PS: Invited Sebastian Hagen who programmed the patch to join the discussion, hope he will help me/us with more details
sure? (I'm in no way an expert, its an honest question.) root@OpenWrt:~# ip route 192.168.1.48 via 192.168.1.188 dev ath1 metric 7 192.168.2.40 via 192.168.1.188 dev ath1 metric 6 192.168.1.49 via 192.168.1.188 dev ath1 metric 4 192.168.2.42 via 192.168.1.188 dev ath1 metric 7 192.168.1.51 via 192.168.2.172 dev eth0 metric 2
so there are interfaces shown in the routes, the kernel should recognize them, what else they are for?
As Axel already mentionned: These are the outgoing interfaces which you can specify but the problem arises if your neighbor node has 2 interfaces as well. How are you going to seperate these ? Normally you do so by using 2 different IP addresses to send traffic to one or the other interface. But if you only have one address ...
PS: Invited Sebastian Hagen who programmed the patch to join the discussion, hope he will help me/us with more details
Good idea. :-)
Greetings, Marek
Hello,
On Dienstag 20 November 2007, rene wrote:
Hi,
Axel Neumann wrote:
Hi,
On Dienstag 20 November 2007, rene wrote:
Hi,
starting batmand, the daemon sometimes doesn't seem to recognize the network the right way.
root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255
on the other node: root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 root@25:~#
What is definitively not correct is that your capture indicates 4 times the same IP address (192.168.42.25) on 4 different interfaces.
This is two times the same node, first time it recognizes the broadcast the right way, second time not.
of course, ive been somwhow distracted by "the other node"
There MUST be a different IP address for each BATMAN interface in the network (also if a single BATMAN node has more than one interface).
Is this implemented like this (where?)?
Yes it is implemented/designed like this. It operates on layer three and above. IP addresses are used to differentiate between different links to the same neighbors. For example two nodes A and B, each with two wireless interfaces 1 and 2. All interfaces operating in the same channel, bssid, ... How could node A differentiate between the link A1<->B1 and A1<->B2 if it is not aware of any MAC addresses. But even if it is aware of MAC addresses. How could it set up the routing table to ensure that a packet to a distant node C should be routed via B1 (and NOT via B2)?
Can't work BATMAN with the interfaces (or can't we change it to work this way)
i guess its not that easy but if you are familiar with protocol design and c coding go ahead... Or you take a look on batman-advanced, but thats another story :-)
, it would make the whole configuration much easier to assign to every node only one single IP address (or two, one for olsr and ne for BATMAN)? We are doing this with olsr and this really makes the network-structure much cleaner - every node has one IP.
Actually, I did not even know that this is possible - is such a configuration proposed somewhere. I can imagine that this somehow works but how shure are you that this does not introduce any negative side effects?
ciao, axel
Is the described problem with the misconfigured broadcast related to the 'same IP on different interfaces' issue?
regards, Rene _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi,
Axel Neumann wrote:
There MUST be a different IP address for each BATMAN interface in the network (also if a single BATMAN node has more than one interface).
Is this implemented like this (where?)?
Yes it is implemented/designed like this. It operates on layer three and above. IP addresses are used to differentiate between different links to the same neighbors. For example two nodes A and B, each with two wireless interfaces 1 and 2. All interfaces operating in the same channel, bssid, ... How could node A differentiate between the link A1<->B1 and A1<->B2 if it is not aware of any MAC addresses. But even if it is aware of MAC addresses. How could it set up the routing table to ensure that a packet to a distant node C should be routed via B1 (and NOT via B2)?
just by setting the interface to the way the package has to leave the node? Just the same way olsr does, I'm not a protocol designer but don't see any main reason why Batman shouldn't be possible to do it similar.
Actually, I did not even know that this is possible - is such a configuration proposed somewhere. I can imagine that this somehow works but how shure are you that this does not introduce any negative side effects?
We are using this in Rostock since a while (on all WRAPs and on selected APs) and it works very well. Side effects? Maybe, you never know for sure, none recognized and I'm not deep enough into protocol designs to answer this from a theoretical point of view. But it's a great feature which makes Mesh networking much easier and the whole structure much cleaner.
Regards, Rene
On Dienstag 20 November 2007, rene wrote:
Hi,
Axel Neumann wrote:
There MUST be a different IP address for each BATMAN interface in the network (also if a single BATMAN node has more than one interface).
Is this implemented like this (where?)?
Yes it is implemented/designed like this. It operates on layer three and above. IP addresses are used to differentiate between different links to the same neighbors. For example two nodes A and B, each with two wireless interfaces 1 and 2. All interfaces operating in the same channel, bssid, ... How could node A differentiate between the link A1<->B1 and A1<->B2 if it is not aware of any MAC addresses. But even if it is aware of MAC addresses. How could it set up the routing table to ensure that a packet to a distant node C should be routed via B1 (and NOT via B2)?
just by setting the interface to the way the package has to leave the node? Just the same way olsr does, I'm not a protocol designer but don't see any main reason why Batman shouldn't be possible to do it similar.
IMO that does only work if the interfaces of a node are NOT connected to the same physical/logical link (e.g. B1 and B2 are operating on different channels or with different cell IDs,...). Otherwise specifying the outgoing interface is not enough. Even if node A has only one interface (A1). If there is a link A1<->B1 and a link A1<->B2 the problem remains:
How could it set up the routing table to ensure that a packet to a distant node C should be routed via B1 (and NOT via B2)?
The outgoing interface of node A is A1, for both cases. Setting the outgoing interface to A1 has no effect.
Maybe there is a way to configure the next-hop-mac address instead of the next-hop-ip address. But then you rather have layer 2 routing and not layer 3.
/axel
Actually, I did not even know that this is possible - is such a configuration proposed somewhere. I can imagine that this somehow works but how shure are you that this does not introduce any negative side effects?
We are using this in Rostock since a while (on all WRAPs and on selected APs) and it works very well. Side effects? Maybe, you never know for sure, none recognized and I'm not deep enough into protocol designs to answer this from a theoretical point of view. But it's a great feature which makes Mesh networking much easier and the whole structure much cleaner.
Regards, Rene
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
b.a.t.m.a.n@lists.open-mesh.org
-
Axel Neumann -
Marek Lindner -
rene