[B.A.T.M.A.N.] problem starting batmand (v799)

[B.A.T.M.A.N.] problem starting batmand (v799)

[rene]

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

Re: [B.A.T.M.A.N.] problem starting batmand (v799)

[Axel Neumann]

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

Re: [B.A.T.M.A.N.] problem starting batmand (v799)

[rene]

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

[B.A.T.M.A.N.] single IP for multiple interfaces (was: Re: [B.A.T.M.A.N.] problem starting batmand (v799))

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] single IP for multiple interfaces

[rene]

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

Re: [B.A.T.M.A.N.] single IP for multiple interfaces

[Marek Lindner]

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

Re: [B.A.T.M.A.N.] single IP for multiple interfaces

[rene]

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

Re: [B.A.T.M.A.N.] single IP for multiple interfaces

[Marek Lindner]

> 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

Re: [B.A.T.M.A.N.] problem starting batmand (v799)

[Axel Neumann]

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

Re: [B.A.T.M.A.N.] single IP for multiple interfaces

[rene]

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

Re: [B.A.T.M.A.N.] single IP for multiple interfaces

[Axel Neumann]

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