#20313: mac80211 from 2015-07-21 causes DUPs
------------------------+------------------------
Reporter: anonymous | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: packages | Version: Trunk
Resolution: | Keywords:
------------------------+------------------------
Comment (by anonymous):
I am currently trying to reproduce the report from Krishna on the
battlemesh
without success. Maybe it was easier to trigger there because of all other
devices which used the same channels.
But this doesn't explain the claim that r46436 introduced a problem which
allowed the devices to receive packets which were not for them. But I can
clearly see that they send packets which are not from them
(00:aa:aa:aa:aa:02
sends packets from 00:aa:aa:aa:aa:01). But this is also the case for
r46435.
I've configured two OM2P as explained below. The used versions are:
* r46436 aa3336aab186fbef720d345c70e9388851056cd2
* (r46435 113f685179b34015d615530575c73e61fc913039)
wireless node 1 (trelay):
{{{
config wifi-device radio0
option type mac80211
option channel 11
option hwmode 11g
option path 'pci0000:00/0000:00:00.0'
option htmode HT20
option txpower 5
config wifi-iface
option device radio0
option network meshnet
option mode adhoc
option ssid 'mesh'
option encryption none
option bssid '02:CA:FE:CA:CA:40'
option macaddr '00:aa:aa:aa:aa:02'
}}}
wireless node 2 (receiver):
{{{
config wifi-device radio0
option type mac80211
option channel 11
option hwmode 11g
option path 'pci0000:00/0000:00:00.0'
option htmode HT20
option txpower 5
config wifi-iface
option device radio0
option network meshnet
option mode adhoc
option ssid 'mesh'
option encryption none
option bssid '02:CA:FE:CA:CA:40'
option macaddr '00:aa:aa:aa:aa:99'
}}}
network node1
{{{
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option ifname 'eth0'
option force_link '1'
option proto 'static'
option macaddr '00:aa:aa:aa:aa:99'
config interface 'meshnet'
option ifname ''
option force_link '1'
option proto 'static'
config interface 'wan'
option ifname 'eth1'
option proto 'dhcp'
config interface 'wan6'
option ifname 'eth1'
option proto 'dhcpv6'
}}}
network node2
{{{
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option ifname 'eth0'
option force_link '1'
option proto 'static'
config interface 'meshnet'
option ifname ''
option force_link '1'
option proto 'static'
option ipaddr '192.168.2.3'
option netmask '255.255.255.0'
config interface 'wan'
option ifname 'eth1'
option proto 'dhcp'
config interface 'wan6'
option ifname 'eth1'
option proto 'dhcpv6'
}}}
trelay was started manually on node1 after the boot
{{{
echo "eth0-wlan0,eth0,wlan0" > /sys/kernel/debug/trelay/add
# must be removed before wlan0 is removed: echo 1 >
/sys/kernel/debug/trelay/eth0-wlan0/remove
}}}
Later I've dumped packets on both using wlan0 and mon0:
{{{
# just to test if adhoc would allow to receive packets with different dest
(no, didn't work. even with mon0 enabled): ifconfig wlan0 promisc
tcpdump -nxxxxxx -i wlan0
iw phy phy0 interface add mon0 type monitor
ifconfig mon0 up
tcpdump -nxxxxxx -i mon0
}}}
--
Ticket URL: <https://dev.openwrt.org/ticket/20313#comment:5>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
