here is a backtrace for the panic:
panic: ieee80211_mesh_rt_add: adding self to the routing table
KDB: enter: panic
[ thread pid 0 tid 100030 ]
Stopped at kdb_enter+0x50: lui at,0x804e
db> bt
Tracing pid 0 tid 100030 td 0xc08952f0
db_trace_thread+30 (?,?,?,?) ra 8009b510 sp c76275e8 sz 24
8009b3f4+11c (0,?,ffffffff,?) ra 8009aaf8 sp c7627600 sz 32
8009a764+394 (?,?,?,?) ra 8009ac88 sp c7627620 sz 168
db_command_loop+78 (?,?,?,?) ra 8009d368 sp c76276c8 sz 24
8009d260+108 (?,?,?,?) ra 801ead50 sp c76276e0 sz 424
kdb_trap+108 (?,?,?,?) ra 803ad33c sp c7627888 sz 32
trap+c88 (?,?,?,?) ra 803a51d0 sp c76278a8 sz 168
MipsKernGenException+134 (0,a,80653fe4,109) ra 801eafd8 sp c7627950 sz 200
kdb_enter+50 (?,?,?,?) ra 801b3ec4 sp c7627a18 sz 24
panic+f8 (?,803f0dc0,0,df) ra 802aa5dc sp c7627a30 sz 40
ieee80211_mesh_rt_add+74 (?,?,?,?) ra 802a1210 sp c7627a58 sz 40
802a05b4+c5c (?,c0c85000,?,?) ra 8028a540 sp c7627a80 sz 336
ieee80211_recv_action+1b4 (?,?,?,?) ra 802ab868 sp c7627bd0 sz 24
802aafd4+894 (?,?,?,61) ra 800aaf0c sp c7627be8 sz 176
800aaec4+48 (?,?,?,?) ra 802add54 sp c7627c98 sz 56
802acc90+10c4 (?,?,?,ffffffa0) ra 800a8d20 sp c7627cd0 sz 200
800a8794+58c (?,?,?,?) ra 801f8284 sp c7627d98 sz 104
801f81cc+b8 (?,?,?,?) ra 801f8928 sp c7627e00 sz 40
taskqueue_thread_loop+68 (?,?,?,?) ra 801892a0 sp c7627e28 sz 48
fork_exit+b0 (?,?,?,?) ra 803b1c20 sp c7627e58 sz 40
fork_trampoline+10 (?,?,?,?) ra 0 sp c7627e80 sz 0
pid 0
db>
br,
On Tue, Feb 15, 2011 at 1:00 PM, Monthadar Al Jaberi
<montha...@gmail.com> wrote:
> Hej,
>
> I found that a panic can be generated when having a couple of
> ieee80211s nodes in a line topology with one of them being a ROOT
> node. A ping from ROOT in a newly started nodes causes a panic:
> panic: ieee80211_mesh_rt_add: adding self to the routing table
> KDB: enter: panic
> [ thread pid 0 tid 100030 ]
> Stopped at kdb_enter+0x50: lui at,0x804e
> db>
>
> This is because we receive a copy of our own generated
> IEEE80211_ELEMID_MESHPREP packet from our neighbor node.
> I added check code in the begining of hwmp_recv_prep(...) similar to
> the check code found in hwmp_recv_preq(...). Here is a diff output:
>
> --- freebsd/head/sys/net80211/ieee80211_hwmp.c 2010-11-03
> 09:29:25.023610380 +0000
> +++ src/head-current/sys/net80211/ieee80211_hwmp.c 2011-02-15
> 10:06:02.526163874 +0000
> @@ -28,7 +28,7 @@
> */
> #include <sys/cdefs.h>
> #ifdef __FreeBSD__
> -__FBSDID("$FreeBSD$");
> +__FBSDID("$FreeBSD: src/sys/net80211/ieee80211_hwmp.c,v 1.4.2.7.2.1
> 2010/12/21 17:09:25 kensmith Exp $");
> #endif
>
> /*
> @@ -951,6 +951,12 @@
> if (ni == vap->iv_bss ||
> ni->ni_mlstate != IEEE80211_NODE_MESH_ESTABLISHED)
> return;
> + /*
> + * Ignore PREPs from us. Could happen because someone forward it
> + * back to us.
> + */
> + if (IEEE80211_ADDR_EQ(vap->iv_myaddr, prep->prep_targetaddr))
> + return;
> if (!IEEE80211_ADDR_EQ(vap->iv_myaddr, prep->prep_origaddr) &&
> !(ms->ms_flags & IEEE80211_MESHFLAGS_FWD))
> return;
>
> --
> //Monthadar Al Jaberi
>
--
//Monthadar Al Jaberi
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
