Steps to reproduce:
join a 802.11s mesh with a nodeA, and then join the same 802.11s mesh
with another nodeB, so that both nodes MAC addresses are exactly the
same (i.e. nodeB is "cloning" nodeA MAC)
Expected result:
nodeA and nodeB coexist in a conflicting state, silently
(not saying that this is a desired scenario, of course; just came across
this while testing radios that accidentally had the same (fake) address.
the warning might ring a bell to someone, so reporting it here just for
the record)
What actually happens:
both on nodeA and nodeB, the log is flooded with these warnings:
[ 957.948794] ------------[ cut here ]------------
[ 957.953651] WARNING: CPU: 0 PID: 2874 at
backports-2017-11-01/net/mac80211/sta_info.c:456
sta_info_insert_rcu+0xa8/0x654 [mac80211]
[ 957.965646] Modules linked in: pppoe ppp_async ath9k pppox
ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE
ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp
xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack
xt_comment xt_TCPMSS xt_REDIRECT xt_LOG slhc nf_reject_ipv4
nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4
nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
nf_conntrack macvlan mac80211 iptable_mangle iptable_filter ip_tables
ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark
ebt_limit ebt_ip6 ebt_among ebt_802_3 crc_ccitt br_netfilter ath9k_hw
ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6
nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables
x_tables dummy ip6_tunnel tunnel6 tun ehci_platform ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common crc16 crc32c_generic
crypto_hash
[ 958.050885] CPU: 0 PID: 2874 Comm: kworker/u2:1 Tainted: G W
4.9.67 #0
[ 958.058727] Workqueue: phy1 ieee80211_ibss_leave [mac80211]
[ 958.064394] Stack : 86eec818 00000088 80470000 800a9684 87da269c
80461247 80413b58 00000b3a
[ 958.072938] 80413ac4 873d3b84 80460000 800d8d3c 80470000
800a9684 80419374 80460000
[ 958.081483] 00000003 873d3b84 80460000 80094ee0 80470000
873d3bbc 00000000 802228f8
[ 958.090019] 804737d0 80222800 87693a04 87fa4d00 87fa4c00
70687931 00000000 00000000
[ 958.098563] 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 958.107109] ...
[ 958.109601] Call Trace:
[ 958.112098] [<8006b2e8>] show_stack+0x54/0x88
[ 958.116530] [<8007ff60>] __warn+0xe4/0x118
[ 958.120697] [<80080028>] warn_slowpath_null+0x1c/0x34
[ 958.125919] [<87684f3c>] sta_info_insert_rcu+0xa8/0x654 [mac80211]
[ 958.132306] [<876cd328>] mesh_pathtbl_unregister+0xc64/0xcf4 [mac80211]
[ 958.139083] ---[ end trace cca096df034d04e6 ]---
On Mon, 2017-12-18 at 03:44 +0100, Gui Iribarren wrote:
> Steps to reproduce:
> join a 802.11s mesh with a nodeA, and then join the same 802.11s mesh
> with another nodeB, so that both nodes MAC addresses are exactly the
> same (i.e. nodeB is "cloning" nodeA MAC)
>
> Expected result:
> nodeA and nodeB coexist in a conflicting state, silently
> (not saying that this is a desired scenario, of course; just came across
> this while testing radios that accidentally had the same (fake) address.
> the warning might ring a bell to someone, so reporting it here just for
> the record)
>
> What actually happens:
> both on nodeA and nodeB, the log is flooded with these warnings:
That's hardly an "oops", but yeah, not nice.
Somewhere we should drop packets if they appear to come from ourselves.
Perhaps like this:
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b3cff69bfd66..fd580614085b 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3625,6 +3625,8 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx)
}
return true;
case NL80211_IFTYPE_MESH_POINT:
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2))
+ return false;
if (multicast)
return true;
return ether_addr_equal(sdata->vif.addr, hdr->addr1);
johannes
On Tue, Dec 19, 2017 at 2:05 AM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2017-12-18 at 03:44 +0100, Gui Iribarren wrote:
>> Steps to reproduce:
>> join a 802.11s mesh with a nodeA, and then join the same 802.11s mesh
>> with another nodeB, so that both nodes MAC addresses are exactly the
>> same (i.e. nodeB is "cloning" nodeA MAC)
>>
>> Expected result:
>> nodeA and nodeB coexist in a conflicting state, silently
>> (not saying that this is a desired scenario, of course; just came across
>> this while testing radios that accidentally had the same (fake) address.
>> the warning might ring a bell to someone, so reporting it here just for
>> the record)
>>
>> What actually happens:
>> both on nodeA and nodeB, the log is flooded with these warnings:
>
> That's hardly an "oops", but yeah, not nice.
>
> Somewhere we should drop packets if they appear to come from ourselves.
> Perhaps like this:
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index b3cff69bfd66..fd580614085b 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -3625,6 +3625,8 @@ static bool ieee80211_accept_frame(struct ieee80211_rx_data *rx)
> }
> return true;
> case NL80211_IFTYPE_MESH_POINT:
> + if (ether_addr_equal(sdata->vif.addr, hdr->addr2))
> + return false;
> if (multicast)
> return true;
> return ether_addr_equal(sdata->vif.addr, hdr->addr1);
Makes sense.
--
thomas