Re: Problem with 802.11 ad hoc with WEP: NULL pointer dereference

On Sat, 25 Dec 2004, Robert Watson wrote:
>
> I recently upgraded a kernel on my notebook to Dec 23.  I don't have the
> date of the previous kernel on-hand, but I suspect it was late November
> from before I was on travel.  I have a local configuration I sometimes use
> with adhoc 802.11 on a prism card using WEP, using a FreeBSD notebook as a
> proxy to reach a wired network.  The other system is a Mac OS X notebook.
> As of the upgrade, I get a kernel page fault on the FreeBSD system
> whenever I attempt to use the Mac OS X box with wireless.  In fact,
> booting the Mac OS X box causes the FreeBSD box to panic, presumably as
> the Mac OS X box says "Hi, I'm here!".  The panic is a NULL pointer
> derefernece in ieee80211_find_rxnode().  I don't have the complete trap
> message due to not having a serial console for the box, but below is some
> core information.  This is highly reproduceable; please let me know if
> more information is needed.

   In this case, ieee80211_find_rxnode() needs to lock the node table
before further operations; however, IEEE80211_NODE_LOCK() panics due to
the node lock mutex was never initialised. From my observation, the
proper path to initialise the mutex is through ieee80211_create_ibss()
-> ieee80211_node_table_alloc(): the "neighbor" case in this example;
however, I suspect that the panic would also take place in if_wi HOSTAP 
mode....

   The latest net80211 has some assumptions and basic requirements
whilst the station is going to join the IBSS. Since most of the 802.11
state transitions(such like state involes probing/authentication/association
frames) in if_wi were firmware based, most of them would be bypassed
in wi_newstate and thus some vital initialisation functions such like
ieee80211_create_ibss() within ieee80211_end_scan() never get called.

   Sam said that unless someone steps out and deals with that, this issue
will have to wait until he has free time:

http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044462.html

   BTW, I'm still trying to figure out a workaround/bandaid to get over this
but still have no luck. One of the problem is that I'm not sure how to
tell that the hardware is associated with the IBSS. The other problem is
that the right path to ieee80211_create_ibss() is not very clear to me:
through ieee80211_newstate(S_INIT -> S_SCAN) or just create_ibss() directly?

> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research
>
> #21 0x00000002 in ?? ()
> #22 0xc05a6b2b in ieee80211_find_rxnode (ic=0xc1bcf25c, wh=0xc1bb8730)
>    at atomic.h:365
> #23 0xc04ca7c7 in wi_intr (arg=0xc1bcf000) at
> /usr/src/sys/dev/wi/if_wi.c:1533
> #24 0xc0506d8d in ithread_loop (arg=0xc197b780)
>    at /usr/src/sys/kern/kern_intr.c:547
> #25 0xc0505e8c in fork_exit (callout=0xc0506ce0 <ithread_loop>,
>    arg=0xc197b780, frame=0xd418fd48) at /usr/src/sys/kern/kern_fork.c:790
> #26 0xc069619c in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:209
> (kgdb) frame 22
> #22 0xc05a6b2b in ieee80211_find_rxnode (ic=0xc1bcf25c, wh=0xc1bb8730)
>    at atomic.h:365
> 365     {
> (kgdb) list
> 360     #define atomic_readandclear_32  atomic_readandclear_int
> 361
> 362     #if !defined(WANT_FUNCTIONS)
> 363     static __inline int
> 364     atomic_cmpset_ptr(volatile void *dst, void *exp, void *src)
> 365     {
> 366
> 367             return (atomic_cmpset_int((volatile u_int *)dst, (u_int)exp,
> 368                 (u_int)src));
> 369     }
> (kgdb) inspect nt
> $1 = (struct ieee80211_node_table *) 0x0
>
[...]