[Babel-users] Basic questions about babeld setup for Battlemesh

[Jehan Tremback]

Hi everyone, I volunteered to set up babeld for the Battlemesh testbed,
since nobody else was going to do it. The testbed consists of some 2.4/5ghz
wifi routers. The 2.4ghz radio is used for management, while the 5ghz radio
runs the protocol being tested.

Each routing protocol needs to have a shell script that gets run after a
reboot, and adds an IP address to the 5ghz interface, and starts the
routing daemon.

For some reason, babeld is picking up and propagating the management IP,
which is not actually set on the interface that I am running babeld on
(there's some bridging going on for management though). I'm attempting to
use the filter syntax to stop that, but it's not working well and I don't
know enough about it.

Here's my script:

#!sh

hostname=$(cat /etc/config/system | grep hostname)
num=${hostname:22:1}
ip="10.0.$num.1/24"

ip addr add $ip dev wlan1

command="redistribute ip $ip allow"

babeld -d 1 \
-C $command \
-C 'redistribute local deny' \
wlan1

Here's the output of ip addr after running this:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
qlen 1000

    link/ether c0:4a:00:fc:1c:96 brd ff:ff:ff:ff:ff:ff

    inet6 fe80::c24a:ff:fefc:1c96/64 scope link

       valid_lft forever preferred_lft forever

3: ip6tnl0 at NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1

    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

6: br-mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP qlen 1000

    link/ether c0:4a:00:fc:1c:96 brd ff:ff:ff:ff:ff:ff

    inet 192.168.254.2/24 brd 192.168.254.255 scope global br-mgmt

       valid_lft forever preferred_lft forever

    inet6 fe80::c24a:ff:fefc:1c96/64 scope link

       valid_lft forever preferred_lft forever

7: eth0.2 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master br-mgmt state UP qlen 1000

    link/ether c0:4a:00:fc:1c:96 brd ff:ff:ff:ff:ff:ff

8: br-testbed: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP qlen 1000

    link/ether c0:4a:00:fc:1c:96 brd ff:ff:ff:ff:ff:ff

    inet 10.0.2.1/24 brd 10.0.2.255 scope global br-testbed

       valid_lft forever preferred_lft forever

    inet6 fe80::c24a:ff:fefc:1c96/64 scope link

       valid_lft forever preferred_lft forever

9: eth0.1 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master br-testbed state UP qlen 1000

    link/ether c0:4a:00:fc:1c:96 brd ff:ff:ff:ff:ff:ff

10: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP qlen 1000

    link/ether c0:4a:00:fc:1c:98 brd ff:ff:ff:ff:ff:ff

    inet 10.0.2.1/24 scope global wlan1

       valid_lft forever preferred_lft forever

    inet6 fe80::c24a:ff:fefc:1c98/64 scope link

       valid_lft forever preferred_lft forever

11: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master
br-mgmt state UP qlen 1000

    link/ether c0:4a:00:fc:1c:97 brd ff:ff:ff:ff:ff:ff

    inet6 fd70:1e56:f51e:cfc8:29cb:b8f3:94c4:61c4/16 scope global

       valid_lft forever preferred_lft forever

    inet6 fe80::c24a:ff:fefc:1c97/64 scope link

       valid_lft forever preferred_lft forever

And here's the output of the debug log:

ip: RTNETLINK answers: File exists

Type: 2


My id c2:4a:00:ff:fe:fc:1c:96 seqno 55368

192.168.254.2/32 metric 0 (exported)

10.0.2.1/32 metric 0 (exported)

fd5d:6789:d54d::/48 metric 0 (exported)

10.0.2.0/24 metric 0 (exported)

192.168.254.0/24 metric 0 (exported)


My id c2:4a:00:ff:fe:fc:1c:96 seqno 55368

192.168.254.2/32 metric 0 (exported)

10.0.2.1/32 metric 0 (exported)

fd5d:6789:d54d::/48 metric 0 (exported)

10.0.2.0/24 metric 0 (exported)

192.168.254.0/24 metric 0 (exported)


My id c2:4a:00:ff:fe:fc:1c:96 seqno 55368

192.168.254.2/32 metric 0 (exported)

10.0.2.1/32 metric 0 (exported)

fd5d:6789:d54d::/48 metric 0 (exported)

10.0.2.0/24 metric 0 (exported)

192.168.254.0/24 metric 0 (exported)


My id c2:4a:00:ff:fe:fc:1c:96 seqno 55368

192.168.254.2/32 metric 0 (exported)

10.0.2.1/32 metric 0 (exported)

fd5d:6789:d54d::/48 metric 0 (exported)

10.0.2.0/24 metric 0 (exported)

192.168.254.0/24 metric 0 (exported)


My id c2:4a:00:ff:fe:fc:1c:96 seqno 55368

192.168.254.2/32 metric 0 (exported)

10.0.2.1/32 metric 0 (exported)

fd5d:6789:d54d::/48 metric 0 (exported)

10.0.2.0/24 metric 0 (exported)

192.168.254.0/24 metric 0 (exported)


As you can see, it is still propagating the management IP,  192.168.254.2/32
.

This shouldn't actually cause any problems, and we'll test it out tomorrow,
but I just wanted to run it by the list and find out what I am doing wrong.

-Jehan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20170606/b25e3ee2/attachment.html>