On 11/01/2013 04:16 PM, Bastian Bittorf wrote:
- Antonio Quartulli antonio@meshcoding.com [01.11.2013 16:04]:
both nodes are not connected via cable and are nodes in hybrid-mode (ap+adhoc). no special tricks, 'only' macvlan. BLA2 is active on all nodes.
the again: why does batman-adv think, that the client (my laptop) is/was reachable over 02:00:ca:b1:00:13 - the laptop was never there? a hash-collision?
No. This happens when bat0 on one node and bat0 on the other are bridged together. The common scenario for this is that you have the two nodes connected to an Ethernet switch and you have bat0 bridged into this LAN. At this point the "two bat0s" will get in touch with each other. Like the first picture in this page[1].
The "only" macvlan thing is probably something we should try to investigate further :-) You are the first reporting strange issues like this and the fact that this happens quite often means that there is something in the network setup that is triggering this problem.
All nodes are in 'hybrid' mode, so adhoc+ap on 1 or more radio's. Each interface, e.g. LAN/WAN/ADHOC is an batman-adv interface, each AP-Mode/hostapd-interfaces is bridged to bat0, so it looks like:
root@node15hybrid:~ batctl interface eth0.1: active # LAN eth0.2: active # WAN wlan0-1: active # adhoc-2.4ghz wlan1-1: active # adhoc-5ghz
root@node15hybrid:~ brctl show bridge name bridge id STP enabled interfaces br-mybridge 7fff.460a753cf247 no bat0 wlan0 # AP-2.4ghz wlan1 # AP-5ghz
A few number of nodes are coupled via wire (this works). Each node has an IP of 192.168.x.1/16 where X is a uniq number.
Each node has a macvlan called 'gateway0' which has the IP 192.168.0.1/32 This is just an IP which every DHCP-Client gets for "default-gateway". (so the gateway is the node itself and not the internet-offering-node). This looks like this:
root@node222hybrid:~ ip address show dev gateway0 15: gateway0@br-mybridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether 02:00:c0:ca:c0:1a brd ff:ff:ff:ff:ff:ff
if this mac (02:00:c0:ca:c0:1a) exists on several different nodes that are not connected by a real ethernet backbone (and BLA2 enabled) then batman goes mushroom tripping, since it 'sees' that MAC as a non-mesh-client that is everywhere at the same time, and tries to roam it around, creating funny symptoms (like DUPs and such)
if all nodes are actually connected to an ethernet backbone, then BLA2 is supposed to save the day, by properly handling the situation. (haven't actually tried it, tho)
what we did is avoid (the best we can) those packets to be sent over bat0, with ebtables
# cat /etc/firewall.user ebtables -A FORWARD -j DROP -d 02:00:c0:ca:c0:1a ebtables -t nat -A POSTROUTING -o bat0 -j DROP -s 02:00:c0:ca:c0:1a
hope that helps!
inet 192.168.0.1/32 scope global gateway0 valid_lft forever preferred_lft forever inet6 fe80::c0ff:feca:c01a/64 scope link valid_lft forever preferred_lft foreverEach node is a batman-adv gateway, so 'batctl gwl' outputs every node. (so DHCP-questions are not forwarded but ansered locally).
i wouldn't be so sure... AFAIU when a request arrives at a gw_mode=master, bat0 passes it upstream (to br-lan) as a broadcast, so that it will reach either a local dnsmasq, or another DHCP server running on the lan behind (say, connected to eth0 which is part of br-lan)
(i used that setup several times; a batadv gw_mode=master node with no local dnsmasq, but another dhcp server connected via ethernet behind)
The backbone-table seems to be empty on every node.
Does this help? bye, bastian