Re: RE: RADIX_MPATH usage information
How about the documentation? I enjoyed one of your article about routing architecture in FreeBSD8, so I'm looking forward to this one. Thanks 2010-10-09 beezarliu 发件人： Li, Qing 发送时间： 2010-08-28 00:01:06 收件人： zeus.panche...@gmail.com; freebsd-net@freebsd.org 抄送： 主题： RE: RADIX_MPATH usage information There are a couple of items I need to take care of in this area, including the documentation, so I will get it done this weekend. --Qing > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- > n...@freebsd.org] On Behalf Of Zeus V Panchenko > Sent: Thursday, August 26, 2010 11:25 PM > To: freebsd-net@freebsd.org > Subject: Re: RADIX_MPATH usage information > > +1 > > -- > Zeus V. Panchenko > IT Dpt., IBS ltdGMT+2 (EET) > ___ > 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" ___ 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" ___ 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"
Re: Monitor mode not working for iwi(4) on 7.X
On 10/9/10, Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 06:07:31PM +, Paul B Mahol wrote: >> Just to clear this up, iwi(4) can not support injection (see >> iwi_raw_xmit()) >> unless you manage to hack firmware ... > > Can you perhaps comment on this thread: > > http://ubuntuforums.org/showthread.php?t=242556 > > At a glance it looks like guys use dummy interface for packet injection, > and I don't see they patch firmware in any way. If it's not a hoax, I > wonder if similar techniques can be used under FreeBSD. That patch allows only data injection so it is near to useless. ___ 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"
Re: VIMAGE + NDIS
Paul B Mahol wrote:
On 9/27/10, Julian Elischer wrote:
anyone here have NDIS experience?
On 9/27/10 10:51 AM, Nikos Vassiliadis wrote:
Julian Elischer wrote:
#10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at
/usr/src/sys/net/rtsock.c:1374
1374if (V_loif)
(kgdb) list
1369}
1370*(unsigned short *)(tag + 1) = sa->sa_family;
1371m_tag_prepend(m, tag);
1372}
1373#ifdef VIMAGE
1374if (V_loif)
1375m->m_pkthdr.rcvif = V_loif;
1376else {
1377m_freem(m);
1378return;
(kgdb)
ok so probably there is a code-path to this point that does not first
set up the current-vnet pointer before doing this.
what you need to do is to produce a stack-trace so we can see how
it got here,
and then we can figure out where on that path we should set the
pointer.
Here it is:
(kgdb) #0 doadump () at pcpu.h:231
#1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808,
dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548
#2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0,
dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#3 0xc04d4e0a in db_command_loop () at
/usr/src/sys/ddb/db_command.c:498
#4 0xc04d6d0d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948)
at /usr/src/sys/kern/subr_kdb.c:535
#6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24)
at /usr/src/sys/i386/i386/trap.c:929
#7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24)
at /usr/src/sys/i386/i386/trap.c:851
#8 0xc0c0bad5 in trap (frame=0xeef1d948) at
/usr/src/sys/i386/i386/trap.c:533
#9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0)
at /usr/src/sys/net/rtsock.c:1374
#11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at
/usr/src/sys/net/rtsock.c:1168
#12 0xc76704a1 in ?? ()
#13 0xc6c3d400 in ?? ()
#14 0xeef1daa8 in ?? ()
#15 0xeef1daf4 in ?? ()
#16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200)
at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105
#17 0xc766d8a1 in ?? ()
#18 0xc76b9200 in ?? ()
#19 0xc76c in ?? ()
#20 0xc76f1000 in ?? ()
#21 0xeef1dacc in ?? ()
#22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#23 0x006c in ?? ()
#24 0xeef1dbb4 in ?? ()
#25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#26 0xc76c in ?? ()
#27 0xc76c in ?? ()
#28 0xc7340800 in ?? ()
#29 0xc086adcc in hardclock_cpu (usermode=7077888)
at /usr/src/sys/kern/kern_clock.c:447
whoa!
hardclock interrupted itself?
#30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#31 0x006c in ?? ()
#32 0xeef1dbb4 in ?? ()
#33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#34 0xc76c in ?? ()
#35 0xc76c in ?? ()
#36 0xc7340800 in ?? ()
hmmm maybe we need to get ndis to put in a wrapper at this point that
is called form hardclock and sets the value before going further
I'd have to look at the code to see what happens here..
*wonders who has their fingers in this code*..
#37 0xc086adcc in hardclock_cpu (usermode=-949223424)
at /usr/src/sys/kern/kern_clock.c:447
Previous frame inner to this frame (corrupt stack?)
(kgdb)
and the panic, in case it helps:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x18
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0978200
stack pointer = 0x28:0xeef1d988
frame pointer = 0x28:0xeef1d9a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1404 (Windows Workitem 3)
panic: from debugger
cpuid = 1
KDB: stack backtrace:
Physical memory: 2916 MB
Dumping 113 MB: 98 82 66 50 34 18 2
Thanks, Nikos
Please give more background information of this case.
Personally I never tested VIMAGE.
Sorry for the delayed response,
It is easily producible. Build a kernel with VIMAGE, associate
with an AP, run dhclient and then change the SSID to something
random.
If there is something I can do to help you debug this problem,
please don't hesitate to ask.
Thanks, Nikos
___
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"
Re: VIMAGE + NDIS
On 10/9/10, Nikos Vassiliadis wrote:
> Paul B Mahol wrote:
>> On 9/27/10, Julian Elischer wrote:
>>> anyone here have NDIS experience?
>>>
>>> On 9/27/10 10:51 AM, Nikos Vassiliadis wrote:
Julian Elischer wrote:
>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at
>> /usr/src/sys/net/rtsock.c:1374
>> 1374if (V_loif)
>> (kgdb) list
>> 1369}
>> 1370*(unsigned short *)(tag + 1) = sa->sa_family;
>> 1371m_tag_prepend(m, tag);
>> 1372}
>> 1373#ifdef VIMAGE
>> 1374if (V_loif)
>> 1375m->m_pkthdr.rcvif = V_loif;
>> 1376else {
>> 1377m_freem(m);
>> 1378return;
>> (kgdb)
>>
> ok so probably there is a code-path to this point that does not first
> set up the current-vnet pointer before doing this.
> what you need to do is to produce a stack-trace so we can see how
> it got here,
> and then we can figure out where on that path we should set the
> pointer.
Here it is:
(kgdb) #0 doadump () at pcpu.h:231
#1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808,
dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548
#2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0,
dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#3 0xc04d4e0a in db_command_loop () at
/usr/src/sys/ddb/db_command.c:498
#4 0xc04d6d0d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948)
at /usr/src/sys/kern/subr_kdb.c:535
#6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24)
at /usr/src/sys/i386/i386/trap.c:929
#7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24)
at /usr/src/sys/i386/i386/trap.c:851
#8 0xc0c0bad5 in trap (frame=0xeef1d948) at
/usr/src/sys/i386/i386/trap.c:533
#9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0)
at /usr/src/sys/net/rtsock.c:1374
#11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at
/usr/src/sys/net/rtsock.c:1168
#12 0xc76704a1 in ?? ()
#13 0xc6c3d400 in ?? ()
#14 0xeef1daa8 in ?? ()
#15 0xeef1daf4 in ?? ()
#16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200)
at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105
#17 0xc766d8a1 in ?? ()
#18 0xc76b9200 in ?? ()
#19 0xc76c in ?? ()
#20 0xc76f1000 in ?? ()
#21 0xeef1dacc in ?? ()
#22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#23 0x006c in ?? ()
#24 0xeef1dbb4 in ?? ()
#25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#26 0xc76c in ?? ()
#27 0xc76c in ?? ()
#28 0xc7340800 in ?? ()
#29 0xc086adcc in hardclock_cpu (usermode=7077888)
at /usr/src/sys/kern/kern_clock.c:447
>>>
>>> whoa!
>>> hardclock interrupted itself?
>>>
#30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#31 0x006c in ?? ()
#32 0xeef1dbb4 in ?? ()
#33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#34 0xc76c in ?? ()
#35 0xc76c in ?? ()
#36 0xc7340800 in ?? ()
>>> hmmm maybe we need to get ndis to put in a wrapper at this point that
>>> is called form hardclock and sets the value before going further
>>>
>>> I'd have to look at the code to see what happens here..
>>>
>>> *wonders who has their fingers in this code*..
>>>
#37 0xc086adcc in hardclock_cpu (usermode=-949223424)
at /usr/src/sys/kern/kern_clock.c:447
Previous frame inner to this frame (corrupt stack?)
(kgdb)
and the panic, in case it helps:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x18
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0978200
stack pointer = 0x28:0xeef1d988
frame pointer = 0x28:0xeef1d9a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1404 (Windows Workitem 3)
panic: from debugger
cpuid = 1
KDB: stack backtrace:
Physical memory: 2916 MB
Dumping 113 MB: 98 82 66 50 34 18 2
Thanks, Nikos
>>
>> Please give more background information of this case.
>> Personally I never tested VIMAG
Re: Monitor mode not working for iwi(4) on 7.X
On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 07:44:50PM +0200, Bernhard Schmidt wrote: > > On Friday 08 October 2010 19:36:13 Bernhard Schmidt wrote: > > > After having another cup of coffee it's pretty obvious what's wrong. > > > The only difference between what I did and your scenario is, that I > > > didn't use > > > ifconfig iwi0 mediaopt monitor > > > but > > > ifconfig iwi0 monitor > > I haven't look in the source yet, but what is the difference between > "mediaopt monitor" and "monitor"? The first is SIOCSIFMEDIA the other SIOCGIFFLAGS. The later probably only worked by accident.. > > > instead.. anyways.. > > > > > > Attached patched should behave better now. > > > > Sorry.. correct one this time. > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > does not work after that (and "list scan" returns no results) even if I > put adapter back to normal (from promisc and monitor modes) with > ifconfig(8). kldunloading and loading module again fixes the issue. Due to enqueueing the scan command in an infinite loop (yeah.. scanning returns every frame, that's monitor mode for that device.. *sigh*) we might increment a queue index but never actually dequeueing the command. On 'down' we clear the command queue but not the indicies resulting in the cur index not pointing to a filled entry. Attached patch should fix that. On a side note, you should never be required to run 'ifconfig dev scan', because after 'ifconfig dev up' the device is always in SCAN state (at least in station mode). Using 'ifconfig dev list scan' is sufficient enough. The 'scan' command is usally used to trigger a background scan while not being in SCAN state and those tend to get suspended pretty often (eg. when packets need to be sent), this is what you see as a hang. > Injection test "aireplay-ng -9 iwi0" still fails, but as I've been told > this is firmware issue (i.e. not possible with iwi(4)), which is also > inline with dmesg: > >kernel: iwi0: firmware error >kernel: iwi0: iwi_cmd: cmd 6 not sent, busy >kernel: iwi0: device configuration failed > > Googling shows that people patch Linux drivers to support injection, but > I do not know if any of that information is applicable to FreeBSD. It might be possible with lots of ugly hacks to get that device sending some kind of frames, 'injecting' those frames via net80211 shouldn't be that hard. At least the code is there according to comments in ieee80211_output.c. I do not consider this worth the effort though, if someone wants to work on that, let me know. > Apart from that, machine seems stable, and monitor mode is fixed. Thanks > a lot! You're welcome :) -- Bernhard Index: sys/dev/iwi/if_iwi.c === --- sys/dev/iwi/if_iwi.c (revision 213584) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -3267,6 +3298,7 @@ iwi_stop(void *priv) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); memset(sc->sc_cmd, 0, sizeof(sc->sc_cmd)); + sc->sc_cmd_cur = sc->sc_cmd_next = 0; sc->sc_tx_timer = 0; sc->sc_rfkill_timer = 0; sc->sc_state_timer = 0; ___ 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"
Re: VIMAGE + NDIS
Paul B Mahol wrote: First remove rt_ifmsg() call from if_ndis.c rebuild & load if_ndis module and tell me if it still happens. No, it doesn't panic anymore. Thanks a lot for your help! Nikos ___ 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"
