Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Local node routing table separation #1568

Closed
wants to merge 3 commits into from
Closed

Local node routing table separation #1568

wants to merge 3 commits into from

Commits on Nov 15, 2018

  1. gluon-mesh-batman-adv: fix source MAC for the IPv6 local-node address 

    Before, IPv6 packets from the local-node interface using the IPv6 ULA
were wrongly using the MAC address from br-client (64:70:02:ae:72:e4):

client$ tcpdump -i enp0s31f6 -e -n "ether src 16:41:95:40:f7:dc or ether src 64:70:02:ae:72:e4 or ether src 8c:16:45:66:ba:11"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
00:02:51.202570 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 3, length 64
00:02:51.203040 64:70:02:ae:72:e4 > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 3, length 64
00:02:52.226566 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 4, length 64
00:02:52.227255 64:70:02:ae:72:e4 > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 4, length 64

(br-client: 64:70:02:ae:72:e4, local-node: 16:41:95:40:f7:dc, client device: 8c:16:45:66:ba:11)

$ ip a s dev local-node
10: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc noqueue state UP qlen 1000
    link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
    inet 10.130.0.1/20 brd 10.130.15.255 scope global local-node
       valid_lft forever preferred_lft forever
    inet6 fdef:ffc0:3dd7::1/128 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::1441:95ff:fe40:f7dc/64 scope link
       valid_lft forever preferred_lft forever

With this patch applied ICMPv6 uses the correct source MAC
address from the local-node interface (16:41:95:40:f7:dc):

$ tcpdump -i enp0s31f6 -e -n "ether src 16:41:95:40:f7:dc or ether src 64:70:02:ae:72:e4 or ether src 8c:16:45:66:ba:11"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
00:15:19.757790 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 1, length 64
00:15:19.758567 16:41:95:40:f7:dc > 33:33:ff:66:ba:11, ethertype IPv6 (0x86dd), length 86: fdef:ffc0:3dd7::1 > ff02::1:ff66:ba11: ICMP6, neighbor solicitation, who has fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11, length 32
00:15:19.758617 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 86: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, neighbor advertisement, tgt is fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11, length 32
00:15:19.759220 16:41:95:40:f7:dc > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 1, length 64
00:15:20.759425 8c:16:45:66:ba:11 > 16:41:95:40:f7:dc, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11 > fdef:ffc0:3dd7::1: ICMP6, echo request, seq 2, length 64
00:15:20.759966 16:41:95:40:f7:dc > 8c:16:45:66:ba:11, ethertype IPv6 (0x86dd), length 118: fdef:ffc0:3dd7::1 > fdef:ffc0:3dd7:0:8e16:45ff:fe66:ba11: ICMP6, echo reply, seq 2, length 64

In practice, this wrong MAC address does not seem to cause any
issues so far, though, as ebtables rules are filtering to bat0 for both
local-node MAC, IPv4 and IPv6 addresses and the IPv6 stack (at least in
Linux) does not seem to update its neighbor table from IPv6 data packets
(interestingly, contrary to the Linux IPv4 stack, as was observed
with 3ef28a4
("gluon-client-bridge: Revert "move IPv4 local subnet route to br-client (freifunk-gluon#1312)").

Signed-off-by: Linus Lüssing <[email protected]>
    @T-X
    T-X committed Nov 15, 2018
    Configuration menu
    Copy the full SHA
    909363f View commit details
    Browse the repository at this point in the history

  2. gluon-mesh-batman-adv: unify IPv4 and IPv6 local-node route behavior 

    Just as was done for IPv6 previously, use the new, separate table for IPv4
local-node, too.

This ensures that we will always only use the source MAC of the
local-node interface if the packet originated from us (locally
generated, not routed) and matches our local-node IPv4 or IPv6
address.

Signed-off-by: Linus Lüssing <[email protected]>
    @T-X
    T-X committed Nov 15, 2018
    Configuration menu
    Copy the full SHA
    8c6a4d8 View commit details
    Browse the repository at this point in the history

  3. gluon-mesh-batman-adv: Add IPv4 subnet to br-client 

    This allows us to route and NAT between br-client and br-wan in the future.
Which is necessary for the gluon-alt-esc-provider package, for instance.

With the local-node routes separated in their own table, the issue
described in:

3ef28a4 ("gluon-client-bridge: Revert "move IPv4 local subnet route to br-client (freifunk-gluon#1312)"

and initially introduced in:

b3762fc ("gluon-client-bridge: move IPv4 local subnet route to br-client (freifunk-gluon#1312)")

does not apply anymore, which makes this change safe again.

Signed-off-by: Linus Lüssing <[email protected]>
    @T-X
    T-X committed Nov 15, 2018
    Configuration menu
    Copy the full SHA
    86802ac View commit details
    Browse the repository at this point in the history