Hi all! I'm using batman-adv (2014.2.0) on two devices running OpenWrt (LibreMesh) connected using a third device running a proprietary firmware in bridge mode (AirOS), this is the topology: http://i.imgur.com/ELMi5RC.png
mac3E80 OpenWrt batman----cable----macE3E7 AirOS station----wireless-- --macE434 AP OpenWrt batman
using tcpdump on the OpenWrt devices I can see batman packets flowing: on mac3E80 I can see: http://sprunge.us/iePM while on macE434 I can see: http://sprunge.us/DIAX as you can see the problem is that macE434 sees packets from mac3E80 *approaching with the wrong mac address*, the mac address of macE3E7 so I think it discards the packages when source mac address is different from mac address specified inside the packet. Is this only a security check? How could I get things work? Thanks, Ilario
On 20/06/14 10:58, Ilario Gelmetti wrote:
Hi all! I'm using batman-adv (2014.2.0) on two devices running OpenWrt (LibreMesh) connected using a third device running a proprietary firmware in bridge mode (AirOS), this is the topology: http://i.imgur.com/ELMi5RC.png
mac3E80 OpenWrt batman----cable----macE3E7 AirOS station----wireless-- --macE434 AP OpenWrt batman
using tcpdump on the OpenWrt devices I can see batman packets flowing: on mac3E80 I can see: http://sprunge.us/iePM while on macE434 I can see: http://sprunge.us/DIAX as you can see the problem is that macE434 sees packets from mac3E80 *approaching with the wrong mac address*, the mac address of macE3E7 so
Yeah, AirOS in "WDS mode" does tricky stuff.
The problem is, in principle, you shouldn't be able to bridge a wifi interface in client mode.
http://wiki.openwrt.org/doc/howto/clientmode?s%5B%5D=bridged&s%5B%5D=cli...
Your AirOS client device is expecting the AP to be in "4addr" mode, which vanilla openwrt is not.
You should either a) keep stock airOS on both client and ap, (what i've done so far, when bumped into this problem) b) flash openwrt to both "client" and "ap", and use adhoc between them c) or dig into doing WDS on openwrt (i guess it's possible but i haven't tried)
Nothing to do with batman-adv, though :)
I think it discards the packages when source mac address is different from mac address specified inside the packet. Is this only a security check? How could I get things work? Thanks, Ilario
Hi,
we have a similar situation at freifunk-berlin. Because of problems with weather-radar we are forced to use DFS/802.11h compliant hardware. We chose ubnt nanostations with AirOS in WDS/transparent-bridge mode. If you want to *bridge* two networks, you need some form of WDS. Basic AP<->STA does not have enough fields for additional MAC-addresses of devices behind the STA.
So either you run OpenWRT with batadv+bmx6 on both NanoStations, or you use AirOS in WDS-mode on both NanoStations and run batadv+bm6 with ethernet-node behind those NS5. Mixing AirOS and OpenWRT (with or without bridge mode) will - as far as i know - always break anything that relies on correct MAC-adresses, like batman-adv or IPv6-NDP.
Regards. Bastian
On 06/20/2014 03:58 PM, Ilario Gelmetti wrote:
Hi all! I'm using batman-adv (2014.2.0) on two devices running OpenWrt (LibreMesh) connected using a third device running a proprietary firmware in bridge mode (AirOS), this is the topology: http://i.imgur.com/ELMi5RC.png
mac3E80 OpenWrt batman----cable----macE3E7 AirOS station----wireless-- --macE434 AP OpenWrt batman
using tcpdump on the OpenWrt devices I can see batman packets flowing: on mac3E80 I can see: http://sprunge.us/iePM while on macE434 I can see: http://sprunge.us/DIAX as you can see the problem is that macE434 sees packets from mac3E80 *approaching with the wrong mac address*, the mac address of macE3E7 so I think it discards the packages when source mac address is different from mac address specified inside the packet. Is this only a security check? How could I get things work? Thanks, Ilario
b.a.t.m.a.n@lists.open-mesh.org