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

From: Tai-hwa Liang (avatar_at_mmlab.cse.yzu.edu.tw)
Date: 12/26/04

  • Next message: Alexandre \: "Re: Problem with 802.11 ad hoc with WEP: NULL pointer dereference"
    Date: Sun, 26 Dec 2004 10:49:46 +0800 (CST)
    To: Robert Watson <rwatson@FreeBSD.org>
    
    

    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@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
    >
    [...]
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  • Next message: Alexandre \: "Re: Problem with 802.11 ad hoc with WEP: NULL pointer dereference"

    Relevant Pages

    • Re: Problem with 802.11 ad hoc with WEP: NULL pointer dereference
      ... > I recently upgraded a kernel on my notebook to Dec 23. ... > date of the previous kernel on-hand, but I suspect it was late November ... > As of the upgrade, I get a kernel page fault on the FreeBSD system ...
      (freebsd-current)
    • Re: gcc updates
      ... This breaks all of the C code I have written for the final phases of the processing chain. ... I assume a similar scheme would allow me to upgrade from F8 to F9. ... It then downloads the anaconda installer, and places an entry in grub that allows selection of an upgrade fedora item. ... This work is quite disk and processor intensive, yet I never saw any kernel or other issues during about two months, and in trimming 100GB of mpeg data. ...
      (Fedora)
    • Re: Problems with Xorg video
      ... I am using kernel 2.6.8-2-386. ... kernel part of the graphics drivers which is needed by Xorg. ... udev upgrade. ...
      (Debian-User)
    • Re: Aptitude/Grub Problem -- Is this a bug?
      ... aptitude update && aptitude upgrade ... unbootable -- ON SARGE!!! ... I lost a day tracking it down and finally found that when a kernel ... upgrade" on your Sarge partition and, at least on my recent one, ...
      (Debian-User)
    • RE: wuftpd problems (Juda Masamy) (Sorin Srbu)
      ... I think my fc6 redhat is 32bit, is it the reason why I cant compile wu-ftpd as 64bit? ... How to upgrade the kernel ... Re: Support Level ...
      (RedHat)