909363f5b9
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
|
||
|---|---|---|
| contrib | ||
| docs | ||
| package | ||
| patches | ||
| scripts | ||
| targets | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| Makefile | ||
| modules | ||
| README.md | ||
Documentation (incomplete at this time, contribute if you can!) may be found at https://gluon.readthedocs.org/.
If you're new to Gluon and ready to get your feet wet, have a look at the Getting Started Guide.
Gluon IRC channel: #gluon in hackint
Issues & Feature requests
Before opening an issue, make sure to check whether any existing issues (open or closed) match. If you're suggesting a new feature, drop by on IRC or our mailinglist to discuss it first.
We maintain a Roadmap for the future development of Gluon.
Use a release!
Please refrain from using the master branch for anything else but development purposes!
Use the most recent release instead. You can list all releases by running git tag
and switch to one by running git checkout v2018.1.1 && make update.
If you're using the autoupdater, do not autoupdate nodes with anything but releases. If you upgrade using random master commits the nodes will break eventually.
Mailinglist
To subscribe to the list, send a message to:
gluon+subscribe@luebeck.freifunk.net
To remove your address from the list, just send a message to
the address in the List-Unsubscribe header of any list
message. If you haven't changed addresses since subscribing,
you can also send a message to:
gluon+unsubscribe@luebeck.freifunk.net