Re: [PATCH] ndis: safe fpu on amd64

[Paul B. Mahol]

On 11/22/11, Kostik Belousov  wrote:
> On Mon, Nov 21, 2011 at 03:49:16PM +0000, Paul B. Mahol wrote:
>> Hi,
>>
>> This patch should fix panic on amd64 when using ndis with drivers
>> which make use of fpu registers.
> Do not allocate fpu_kern_ctx on stack. Its size is 528 bytes on amd64 right
> now, and potentially can grow after AVX support is finished.

So I need to introduce locks and allocate fpu_kern_ctx per CPU because otherwise
memory leaks are possible.
___
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"

[PATCH] ndis: safe fpu on amd64

[Paul B. Mahol]

Hi,

This patch should fix panic on amd64 when using ndis with drivers
which make use of fpu registers.
diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
index 5572988..1a93b54 100644
--- a/sys/compat/ndis/kern_windrv.c
+++ b/sys/compat/ndis/kern_windrv.c
@@ -55,6 +55,9 @@ __FBSDID("$FreeBSD$");
 #ifdef __i386__
 #include 
 #endif
+#ifdef __amd64__
+#include 
+#endif
 
 #include 
 
@@ -613,6 +616,86 @@ windrv_wrap(func, wrap, argcnt, ftype)
 
 	return (0);
 }
+
+uint64_t
+_x86_64_call1(void *fn, uint64_t a)
+{
+	struct fpu_kern_ctx fpu_ctx_save;
+	uint64_t ret;
+
+	fpu_kern_enter(curthread, &fpu_ctx_save, FPU_KERN_NORMAL);
+	ret = x86_64_call1(fn, a);
+	fpu_kern_leave(curthread, &fpu_ctx_save);
+
+	return (ret);
+}
+
+uint64_t
+_x86_64_call2(void *fn, uint64_t a, uint64_t b)
+{
+	struct fpu_kern_ctx fpu_ctx_save;
+	uint64_t ret;
+
+	fpu_kern_enter(curthread, &fpu_ctx_save, FPU_KERN_NORMAL);
+	ret = x86_64_call2(fn, a, b);
+	fpu_kern_leave(curthread, &fpu_ctx_save);
+
+	return (ret);
+}
+
+uint64_t
+_x86_64_call3(void *fn, uint64_t a, uint64_t b, uint64_t c)
+{
+	struct fpu_kern_ctx fpu_ctx_save;
+	uint64_t ret;
+
+	fpu_kern_enter(curthread, &fpu_ctx_save, FPU_KERN_NORMAL);
+	ret = x86_64_call3(fn, a, b, c);
+	fpu_kern_leave(curthread, &fpu_ctx_save);
+
+	return (ret);
+}
+
+uint64_t
+_x86_64_call4(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d)
+{
+	struct fpu_kern_ctx fpu_ctx_save;
+	uint64_t ret;
+
+	fpu_kern_enter(curthread, &fpu_ctx_save, FPU_KERN_NORMAL);
+	ret = x86_64_call4(fn, a, b, c, d);
+	fpu_kern_leave(curthread, &fpu_ctx_save);
+
+	return (ret);
+}
+
+uint64_t
+_x86_64_call5(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d,
+uint64_t e)
+{
+	struct fpu_kern_ctx fpu_ctx_save;
+	uint64_t ret;
+
+	fpu_kern_enter(curthread, &fpu_ctx_save, FPU_KERN_NORMAL);
+	ret = x86_64_call5(fn, a, b, c, d, e);
+	fpu_kern_leave(curthread, &fpu_ctx_save);
+
+	return (ret);
+}
+
+uint64_t
+_x86_64_call6(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d,
+uint64_t e, uint64_t f)
+{
+	struct fpu_kern_ctx fpu_ctx_save;
+	uint64_t ret;
+
+	fpu_kern_enter(curthread, &fpu_ctx_save, FPU_KERN_NORMAL);
+	ret = x86_64_call6(fn, a, b, c, d, e, f);
+	fpu_kern_leave(curthread, &fpu_ctx_save);
+
+	return (ret);
+}
 #endif /* __amd64__ */
 
 
diff --git a/sys/compat/ndis/pe_var.h b/sys/compat/ndis/pe_var.h
index 84e0162..276ad1c 100644
--- a/sys/compat/ndis/pe_var.h
+++ b/sys/compat/ndis/pe_var.h
@@ -460,22 +460,29 @@ extern uint64_t x86_64_call5(void *, uint64_t, uint64_t, uint64_t, uint64_t,
 extern uint64_t x86_64_call6(void *, uint64_t, uint64_t, uint64_t, uint64_t,
 	uint64_t, uint64_t);
 
-
-#define	MSCALL1(fn, a)		\
-	x86_64_call1((fn), (uint64_t)(a))
-#define	MSCALL2(fn, a, b)	\
-	x86_64_call2((fn), (uint64_t)(a), (uint64_t)(b))
-#define	MSCALL3(fn, a, b, c)	\
-	x86_64_call3((fn), (uint64_t)(a), (uint64_t)(b),		\
-	(uint64_t)(c))
-#define	MSCALL4(fn, a, b, c, d)	\
-	x86_64_call4((fn), (uint64_t)(a), (uint64_t)(b),		\
+uint64_t _x86_64_call1(void *, uint64_t);
+uint64_t _x86_64_call2(void *, uint64_t, uint64_t);
+uint64_t _x86_64_call3(void *, uint64_t, uint64_t, uint64_t);
+uint64_t _x86_64_call4(void *, uint64_t, uint64_t, uint64_t, uint64_t);
+uint64_t _x86_64_call5(void *, uint64_t, uint64_t, uint64_t, uint64_t,
+uint64_t);
+uint64_t _x86_64_call6(void *, uint64_t, uint64_t, uint64_t, uint64_t,
+uint64_t, uint64_t);
+
+#define	MSCALL1(fn, a)			\
+	_x86_64_call1((fn), (uint64_t)(a))
+#define	MSCALL2(fn, a, b)		\
+	_x86_64_call2((fn), (uint64_t)(a), (uint64_t)(b))
+#define	MSCALL3(fn, a, b, c)		\
+	_x86_64_call3((fn), (uint64_t)(a), (uint64_t)(b), (uint64_t)(c))
+#define	MSCALL4(fn, a, b, c, d)		\
+	_x86_64_call4((fn), (uint64_t)(a), (uint64_t)(b),		\
 	(uint64_t)(c), (uint64_t)(d))
-#define	MSCALL5(fn, a, b, c, d, e)\
-	x86_64_call5((fn), (uint64_t)(a), (uint64_t)(b),		\
+#define	MSCALL5(fn, a, b, c, d, e)	\
+	_x86_64_call5((fn), (uint64_t)(a), (uint64_t)(b),		\
 	(uint64_t)(c), (uint64_t)(d), (uint64_t)(e))
-#define	MSCALL6(fn, a, b, c, d, e, f)\
-	x86_64_call6((fn), (uint64_t)(a), (uint64_t)(b),		\
+#define	MSCALL6(fn, a, b, c, d, e, f)	\
+	_x86_64_call6((fn), (uint64_t)(a), (uint64_t)(b),		\
 	(uint64_t)(c), (uint64_t)(d), (uint64_t)(e), (uint64_t)(f))
 
 #endif /* __amd64__ */
___
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: kern/142197: [ndis] [patch] ndis is missing media status reporting

[Paul B. Mahol]

On Wed, Jan 6, 2010 at 1:04 PM,   wrote:
> Synopsis: [ndis] [patch] ndis is missing media status reporting
>
> State-Changed-From-To: open->patched
> State-Changed-By: gavin
> State-Changed-When: Wed Jan 6 12:02:52 UTC 2010
> State-Changed-Why:
> Committed to HEAD in r201620
>
>
> Responsible-Changed-From-To: freebsd-net->rpaulo
> Responsible-Changed-By: gavin
> Responsible-Changed-When: Wed Jan 6 12:02:52 UTC 2010
> Responsible-Changed-Why:
> Over to rpaulo as MFC reminder
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=142197
>

Please close this bug report.
___
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: bwi vs. bwn

[Paul B. Mahol]

On Fri, Feb 18, 2011 at 11:26 PM, grarpamp  wrote:
>>> Doesn't FreeBSD have some sort of ndiswrapper function for this?
>>> http://www.broadcom.com/support/802.11/linux_sta.php
>> NDISulator, ndis(4).
>
> Hmm, maybe that only applies to the Windows driver bundles as
> distributed by the vendors (Dell, HP, Lenovo, etc). Or from Microsoft
> itself as part of the OS. And not to this Linux thing.

You need inf and sys file(s), Windows drivers.
Everything is explained in documentation.
___
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: bwi vs. bwn

[Paul B. Mahol]

On Fri, Feb 18, 2011 at 9:54 PM, grarpamp  wrote:
> Doesn't FreeBSD have some sort of ndiswrapper function for this?

NDISulator, ndis(4).
___
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"

ndis: fix panic on i386

[Paul B Mahol]

Hi,

Following patch fix panic on i386 for drivers using such functions.

Those two functions take 64-bit variable(s) for their arguments.
On i386 that takes additional 32-bit variable per argument.
This is required so that windrv_wrap() can correctly wrap function that
miniport driver calls with stdcall convention.
Similar explanation is provided in subr_ndis.c for other functions.
On amd64 we do not use these numbers.

diff --git a/sys/compat/ndis/subr_ntoskrnl.c b/sys/compat/ndis/subr_ntoskrnl.c
index f169de5..0335561 100644
--- a/sys/compat/ndis/subr_ntoskrnl.c
+++ b/sys/compat/ndis/subr_ntoskrnl.c
@@ -4212,8 +4212,8 @@ image_patch_table ntoskrnl_functbl[] = {
IMPORT_FFUNC(ExInterlockedAddLargeStatistic, 2),
IMPORT_SFUNC(IoAllocateMdl, 5),
IMPORT_SFUNC(IoFreeMdl, 1),
-   IMPORT_SFUNC(MmAllocateContiguousMemory, 2),
-   IMPORT_SFUNC(MmAllocateContiguousMemorySpecifyCache, 5),
+   IMPORT_SFUNC(MmAllocateContiguousMemory, 2 + 1),
+   IMPORT_SFUNC(MmAllocateContiguousMemorySpecifyCache, 5 + 3),
IMPORT_SFUNC(MmFreeContiguousMemory, 1),
IMPORT_SFUNC(MmFreeContiguousMemorySpecifyCache, 3),
IMPORT_SFUNC_MAP(MmGetPhysicalAddress, pmap_kextract, 1),
___
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"

ndis: properly allocate memory

[Paul B Mahol]

Hi,

Attached patch resolves buggy allocation of memory in NDISulator.
Correct behavior is to not ignore parameters specified by miniport driver.
diff --git a/src/sys/compat/ndis/subr_ntoskrnl.c 
b/src/sys/compat/ndis/subr_ntoskrnl.c
index 04184ae..f169de5 100644
--- a/src/sys/compat/ndis/subr_ntoskrnl.c
+++ b/src/sys/compat/ndis/subr_ntoskrnl.c
@@ -2426,12 +2426,9 @@ MmAllocateContiguousMemorySpecifyCache(size, lowest, 
highest,
uint64_tboundary;
uint32_tcachetype;
 {
-   void *addr;
-   size_t pagelength = roundup(size, PAGE_SIZE);
-
-   addr = ExAllocatePoolWithTag(NonPagedPool, pagelength, 0);
 
-   return (addr);
+   return (contigmalloc(size, M_DEVBUF, M_ZERO|M_NOWAIT, lowest,
+   highest, PAGE_SIZE, boundary));
 }
 
 static void
@@ -2447,7 +2444,7 @@ MmFreeContiguousMemorySpecifyCache(base, size, cachetype)
uint32_tsize;
uint32_tcachetype;
 {
-   ExFreePool(base);
+   contigfree(base, size, M_DEVBUF);
 }
 
 static uint32_t
___
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: ndis: patch for review

[Paul B Mahol]

On 10/20/10, Bernhard Schmidt  wrote:
> 9, 2010 at 23:53, Paul B Mahol  wrote:
>> Hi,
>>
>> First: we should pin curthread on CPU before we check on which CPU is
>> curthread.
>>
>> Second: instead of sti & cli use critical sections when saving %fs
>> register.
>>
>> Third: I do not know what happens if we get preempted while windows
>> code were running,
>> so leave critical section only _after_ executing windows code.
>
>
> Do you have a test case for that? If so, can you post it?

Unfortunately I do not have test case for third problem.

But not using sched_pin or/and critical sections correctly cause
NTOS: timer %p fired even though it was canceled
in my environment - causing watchdog on ndisX.

And attempt to unload miniport driver after that will cause panic
because something got corrupted.

Theoretically when executing windows code there is small chance for
our thread to be preempted and than it will actually cause %fs corruption
on CPU we were running, and reading comments it appears FreeBSD use %fs
for PCPU.

>
>> diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
>> index f231863..ba29fd2 100644
>> --- a/sys/compat/ndis/kern_windrv.c
>> +++ b/sys/compat/ndis/kern_windrv.c
>> @@ -613,8 +613,6 @@ struct gdt {
>>  extern uint16_tx86_getfs(void);
>>  extern void x86_setfs(uint16_t);
>>  extern void *x86_gettid(void);
>> -extern void x86_critical_enter(void);
>> -extern void x86_critical_exit(void);
>>  extern void x86_getldt(struct gdt *, uint16_t *);
>>  extern void x86_setldt(struct gdt *, uint16_t);
>>
>> @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t);
>>  void
>>  ctxsw_utow(void)
>>  {
>> -   struct tid  *t;
>> +   struct tid *t;
>>
>> +   sched_pin();
>> +   critical_enter();
>>t = &my_tids[curthread->td_oncpu];
>>
>>/*
>> @@ -685,12 +685,9 @@ ctxsw_utow(void)
>>if (t->tid_self != t)
>>x86_newldt(NULL);
>>
>> -   x86_critical_enter();
>>t->tid_oldfs = x86_getfs();
>>t->tid_cpu = curthread->td_oncpu;
>> -   sched_pin();
>>x86_setfs(SEL_TO_FS(t->tid_selector));
>> -   x86_critical_exit();
>>
>>/* Now entering Windows land, population: you. */
>>  }
>> @@ -706,11 +703,10 @@ ctxsw_wtou(void)
>>  {
>>struct tid  *t;
>>
>> -   x86_critical_enter();
>>t = x86_gettid();
>>x86_setfs(t->tid_oldfs);
>> +   critical_exit();
>>sched_unpin();
>> -   x86_critical_exit();
>>
>>/* Welcome back to UNIX land, we missed you. */
>>
>> diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S
>> index c051504..fa4aa87 100644
>> --- a/sys/compat/ndis/winx32_wrap.S
>> +++ b/sys/compat/ndis/winx32_wrap.S
>> @@ -375,11 +375,3 @@ ENTRY(x86_setfs)
>>  ENTRY(x86_gettid)
>>mov %fs:12,%eax
>>ret
>> -
>> -ENTRY(x86_critical_enter)
>> -   cli
>> -   ret
>> -
>> -ENTRY(x86_critical_exit)
>> -   sti
>> -   ret
>> ___
>> 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"
>>
>
>
>
> --
> Bernhard
>
___
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"

ndis: patch for review

[Paul B Mahol]

Hi,

First: we should pin curthread on CPU before we check on which CPU is curthread.

Second: instead of sti & cli use critical sections when saving %fs register.

Third: I do not know what happens if we get preempted while windows
code were running,
so leave critical section only _after_ executing windows code.


diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
index f231863..ba29fd2 100644
--- a/sys/compat/ndis/kern_windrv.c
+++ b/sys/compat/ndis/kern_windrv.c
@@ -613,8 +613,6 @@ struct gdt {
 extern uint16_tx86_getfs(void);
 extern void x86_setfs(uint16_t);
 extern void *x86_gettid(void);
-extern void x86_critical_enter(void);
-extern void x86_critical_exit(void);
 extern void x86_getldt(struct gdt *, uint16_t *);
 extern void x86_setldt(struct gdt *, uint16_t);

@@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t);
 void
 ctxsw_utow(void)
 {
-   struct tid  *t;
+   struct tid *t;

+   sched_pin();
+   critical_enter();
t = &my_tids[curthread->td_oncpu];

/*
@@ -685,12 +685,9 @@ ctxsw_utow(void)
if (t->tid_self != t)
x86_newldt(NULL);

-   x86_critical_enter();
t->tid_oldfs = x86_getfs();
t->tid_cpu = curthread->td_oncpu;
-   sched_pin();
x86_setfs(SEL_TO_FS(t->tid_selector));
-   x86_critical_exit();

/* Now entering Windows land, population: you. */
 }
@@ -706,11 +703,10 @@ ctxsw_wtou(void)
 {
struct tid  *t;

-   x86_critical_enter();
t = x86_gettid();
x86_setfs(t->tid_oldfs);
+   critical_exit();
sched_unpin();
-   x86_critical_exit();

/* Welcome back to UNIX land, we missed you. */

diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S
index c051504..fa4aa87 100644
--- a/sys/compat/ndis/winx32_wrap.S
+++ b/sys/compat/ndis/winx32_wrap.S
@@ -375,11 +375,3 @@ ENTRY(x86_setfs)
 ENTRY(x86_gettid)
mov %fs:12,%eax
ret
-
-ENTRY(x86_critical_enter)
-   cli
-   ret
-
-ENTRY(x86_critical_exit)
-   sti
-   ret
___
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: if_ndis: fix for panic with VIMAGE

[Paul B Mahol]

On 10/13/10, Paul B Mahol  wrote:
> On 10/12/10, Paul B Mahol  wrote:
>> On 10/11/10, Paul B Mahol  wrote:
>>> Hi,
>>>
>>> There is no single valid reason to call rt_ifmsg() in
>>> ndis_linksts_done()
>>>
>>> Patch attached.
>>>
>> Ping.
> Pong.
Ping.
___
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: if_ndis: fix for panic with VIMAGE

[Paul B Mahol]

On 10/12/10, Paul B Mahol  wrote:
> On 10/11/10, Paul B Mahol  wrote:
>> Hi,
>>
>> There is no single valid reason to call rt_ifmsg() in ndis_linksts_done()
>>
>> Patch attached.
>>
> Ping.
Pong.
___
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: if_ndis: fix for panic with VIMAGE

[Paul B Mahol]

On 10/11/10, Paul B Mahol  wrote:
> Hi,
>
> There is no single valid reason to call rt_ifmsg() in ndis_linksts_done()
>
> Patch attached.
>
Ping.
___
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"

if_ndis: fix for panic with VIMAGE

[Paul B Mahol]

Hi,

There is no single valid reason to call rt_ifmsg() in ndis_linksts_done()

Patch attached.
diff --git a/sys/dev/if_ndis/if_ndis.c b/sys/dev/if_ndis/if_ndis.c
index 2ec9d0e..a4672e0 100644
--- a/sys/dev/if_ndis/if_ndis.c
+++ b/sys/dev/if_ndis/if_ndis.c
@@ -1644,10 +1644,6 @@ ndis_linksts_done(adapter)
default:
break;
}
-
-   /* Notify possible listners of interface change. */
-
-   rt_ifmsg(ifp);
 }
 
 static void
___
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]

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 

Re: Monitor mode not working for iwi(4) on 7.X

[Paul B Mahol]

On 10/9/10, Alexey Dokuchaev  wrote:
> On Fri, Oct 08, 2010 at 06:07:31PM +0000, 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: Monitor mode not working for iwi(4) on 7.X

[Paul B Mahol]

On 10/7/10, Alexey Dokuchaev  wrote:
> On Wed, Oct 06, 2010 at 11:56:25AM -0500, Brandon Gooch wrote:
>> 2010/10/6 Alexey Dokuchaev :
>> > On Fri, Dec 14, 2007 at 11:19:25PM +0100, Jan Henrik Sylvester wrote:
>> >> In contrast to 6.2-RELEASE, monitor mode does not work. Kismet does
>> >> not receive anything, while it does with ath or ural (even at the same
>> >> time). dmesg with debug.iwi=2 is below -- anything unusual?
>> >>
>> >> Moreover, "ifconfig iwi0 scan" sometimes just hangs, which never
>> >> happened on 6.2-RELEASE.
>> >
>> > Just found this email sent to stable@ almost three years ago; sadly I
>> > have to confirm iwi(4) still exhibits these problems on fairly recent
>> > 7-STABLE (early Juneish).  Maybe I have better luck on net@ (I am
>> > particularly interested in working monitor mode).  Thanks.  Any debug
>> > information will be gladly provided.  Pointers where to look (revisions
>> > to try, patches, etc.) are greatly appreciated.
>>
>> I know this response isn't too helpful, but the whole Intel
>> PRO/Wireless 2200BG/2225BG/2915ABG open-source driver situation is not
>> too good.
>
> I could understand that, but it looks like FreeBSD has a *regression*
> between 6.2 and 7.x, which is different from just "overall not too good
> situation".  Regressions are presumably should not happen and should be
> easier to fix than improving entire support stack in FOSS industry.  :-)
>
>> Same goes for the Intel 3945ABG (wpi(4)); it's very easy in both Linux
>> and *BSDs to befuddle the Intel Wifi chips.
>>
>> Having said that, Bernhard Schmidt has made outstanding progress with
>> the iwn(4) driver, supporting Intel Wireless WiFi Link
>> 4965/1000/5000/5150/5300/6000/6050 series.
>>
>> Is it possible in your situation to try another wireless card? I know
>> some notebook computers only whitelist a small set of PCI devices...
>
> I think there are no technical obstacles w/my laptop, and I'd gladly try
> something else, preferably fully working under FreeBSD (inc. monitor
> mode and packet injection).  Any particular recommendations (aside from
> iwn(4) supported chips mentioned above)?  Thanks.

Just to clear this up, iwi(4) can not support injection (see iwi_raw_xmit())
unless you manage to hack firmware ...
i
___
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

[Paul B Mahol]

On 10/8/10, Alexey Dokuchaev  wrote:
> On Fri, Oct 08, 2010 at 03:20:08PM +0000, Paul B Mahol wrote:
>> On 10/8/10, Alexey Dokuchaev  wrote:
>> > On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote:
>> >> Try the attached patch, this is basically the code from stable/6
>> >> ported to head and stable/7. I did only some basic tests but monitor
>> >> mode seems to work and it is still possible to use the card in STA
>> >> mode.
>> >
>> > Unfortunately, I am getting instant panic when trying any of aircrack-ng
>> > suite utilities ("ifconfig iwi0 scan/list scan" works though):
>> >
>> > Fatal trap 12: page fault while in kernel mode
>> > processor eflags= interrupt enabled, resume, IOPL = 0
>> > current process = 35 (iwi0 taskq)
>> >
>> > Any suggestions?
>>
>> 7.X is buggy regarding taskqueue, I think (maybe it is net80211 bug
>> and not iwi fault).
>
> That's a sad thing to hear about stable branch.
>
>> Does it panic with tcpdump too?
>
> Bernhard's tests indicate it's not.  However, me doing "ifconfig iwi0
> mediaopt monitor" here resulted in immediate panic (did not catch the
> core this time, but I'm positive it's the same as with aircrack-ng).
>
Looks like SMP issue.
Let me look if it is something obvious.
___
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

[Paul B Mahol]

On 10/8/10, Alexey Dokuchaev  wrote:
> On Thu, Oct 07, 2010 at 08:43:37PM +0200, Bernhard Schmidt wrote:
>> Try the attached patch, this is basically the code from stable/6
>> ported to head and stable/7. I did only some basic tests but monitor
>> mode seems to work and it is still possible to use the card in STA
>> mode.
>>
>> I'm not sure why that got lost, but there must be a reason I'm not
>> seeing right now. If someone has more knowledge about that, please
>> let me know, otherwise I intend to commit it this weekend.
>
> Unfortunately, I am getting instant panic when trying any of aircrack-ng
> suite utilities ("ifconfig iwi0 scan/list scan" works though):
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x0
> fault code  = supervisor read, page not present
> instruction pointer = 0x20:0xc0768d42
> stack pointer   = 0x28:0xe4112c80
> frame pointer   = 0x28:0xe4112c98
> 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 = 35 (iwi0 taskq)
>
> (kgdb) bt
> ...
> #6  0xc060cae0 in trap_fatal (frame=0xe4112c40, eva=0)
> at /usr/src/sys/i386/i386/trap.c:941
> #7  0xc060cd90 in trap_pfault (frame=0xe4112c40, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:863
> #8  0xc060d7f7 in trap (frame=0xe4112c40) at
> /usr/src/sys/i386/i386/trap.c:541
> #9  0xc05f4d9b in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> #10 0xc0768d42 in iwi_monitor_scan (arg=0xc3dcc000, npending=4)
> at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2744
> ...
> (kgdb) f 10
> #10 0xc0768d42 in iwi_monitor_scan (arg=0xc3dcc000, npending=4)
> at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2744
> 2744struct iwi_softc *sc = ic->ic_ifp->if_softc;
> (kgdb) l
> 2739
> 2740static void
> 2741iwi_monitor_scan(void *arg, int npending)
> 2742{
> 2743struct ieee80211com *ic = arg;
> 2744struct iwi_softc *sc = ic->ic_ifp->if_softc;
> 2745IWI_LOCK_DECL;
> 2746
> 2747IWI_LOCK(sc);
> 2748(void) iwi_scanchan(sc, 2000, 0);
> (kgdb) p ((struct ieee80211com *)arg)->ic_ifp
> $1 = (struct ifnet *) 0x0
>
> Any suggestions?

7.X is buggy regarding tasqueue, I think (maybe it is net80211 bug and
not iwi fault).
Does it panic with tcpdump too?
Try to reproduce it on CURRENT.
___
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

[Paul B Mahol]

On 10/8/10, Alexey Dokuchaev  wrote:
> On Fri, Oct 08, 2010 at 11:48:57AM +0000, Paul B Mahol wrote:
>> On 10/8/10, Alexey Dokuchaev  wrote:
>> > On Thu, Oct 07, 2010 at 12:44:20PM +, Paul B Mahol wrote:
>> >> Monitor and injection work commpletly different after vap.
>> >>
>> >> I do not think that kismet and aircrack-ng from ports are patched at
>> >> all.
>> >
>> > This is at least partially true; SVN trunk of aircrack-ng behaves better
>> > than 1.1 version from ports (WRT infamous wi_write() problem).  I will
>> > work out patches for the port after kernel side will get fixed.
>>
>> Heh, you are wrong, svn trunk of aircrack-ng is broken versus
>> wi_write() "problem".
>>
>> Look at "famous" ticket number 666
>
> Oh, that's right, I think I've been testing SVN trunk with this patch
> applied (maybe with =| MONITOR hunk, which I found in another version of
> similar patch).  Without a patch injection test fails immediately,
> before wi_write() gets a chance to trigger.
>
>> Injection on FreeBSD (I forgot exact revision) will work only in AHDEMO
>> mode.
>> Unlike before you can not inject in MONITOR mode.
>
> I've seen people say this, but I could not find more elaborative answer.
> I am also not sure about AHDEMO mode, since iwi(4) reports this for me:
>
> $ ifconfig iwi0 list caps
> iwi0=25818300

I'm talking about after VAP, not about 7.X, where that does not apply.

Support for AHDEMO is somehow similar to MONITOR, look how bwn(4) does it.
It is very straightforward.
___
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

[Paul B Mahol]

On 10/8/10, Alexey Dokuchaev  wrote:
> On Thu, Oct 07, 2010 at 12:44:20PM +0000, Paul B Mahol wrote:
>> On 10/7/10, Adrian Chadd  wrote:
>> > finding where the regression happened - eg, which revision along the
>> > 6.x/head branch at the time caused the issue, would likely help
>> > Bernard very much..
>
> Certainly, if my resources would permit, I'd bisect to offending
> revision(s) myself.  However, I'm away from home right now, with just my
> laptop with me with no free space to host another FreeBSD installation.
>
>> Also, exact instructions how to reproduce problem would help.
>
> That's easy:
> # aireplay-ng -9 iwi0  ;-)
>
>> Monitor and injection work commpletly different after vap.
>>
>> I do not think that kismet and aircrack-ng from ports are patched at all.
>
> This is at least partially true; SVN trunk of aircrack-ng behaves better
> than 1.1 version from ports (WRT infamous wi_write() problem).  I will
> work out patches for the port after kernel side will get fixed.

Heh, you are wrong, svn trunk of aircrack-ng is broken versus
wi_write() "problem".

Look at "famous" ticket number 666

Injection on FreeBSD (I forgot exact revision) will work only in AHDEMO mode.
Unlike before you can not inject in MONITOR mode.
___
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

[Paul B Mahol]

On 10/7/10, Adrian Chadd  wrote:
> finding where the regression happened - eg, which revision along the
> 6.x/head branch at the time caused the issue, would likely help
> Bernard very much..
>

Also, exact instructions how to reproduce problem would help.

Monitor and injection work commpletly different after vap.

I do not think that kismet and aircrack-ng from ports are patched at all.
___
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: ndis: fix ugly code

[Paul B Mahol]

On 10/6/10, Julian Elischer  wrote:
>   On 10/5/10 5:27 PM, Paul B Mahol wrote:
>> On 10/5/10, Julian Elischer  wrote:
>>>On 10/5/10 1:19 PM, Paul B Mahol wrote:
>>>> Hi,
>>>>
>>>> If clang did not complain, I would probbaly never spot it.
>>>>
>>>> Patch attached.
>>> personally I think you could use kproc_kthread_add so that a single
>>> NDIS process had three threads.
>> Patch attached. Now we have single "ndis" kernel process with own threads.
> I don't know how ndis works. Is it possible that each ndis driver
> would have it's own process? or would each instance?
> I don't even know if it's possible to run two different ndis drivers
> in the same kernel.
> if that was the case we'd want to have a different name for each one
> so you can tell them,
> but I just don't know enough about it.

Nothing have changed in funcionality. We are just using kernel thread
instead of kernel process.
___
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: ndis: fix ugly code

[Paul B Mahol]

On 10/5/10, Julian Elischer  wrote:
>   On 10/5/10 1:19 PM, Paul B Mahol wrote:
>> Hi,
>>
>> If clang did not complain, I would probbaly never spot it.
>>
>> Patch attached.
>
> personally I think you could use kproc_kthread_add so that a single
> NDIS process had three threads.

Patch attached. Now we have single "ndis" kernel process with own threads.
diff --git a/sys/compat/ndis/subr_ntoskrnl.c b/sys/compat/ndis/subr_ntoskrnl.c
index 714fcd8..eafbb7c 100644
--- a/sys/compat/ndis/subr_ntoskrnl.c
+++ b/sys/compat/ndis/subr_ntoskrnl.c
@@ -254,6 +254,7 @@ static int32_t KeDelayExecutionThread(uint8_t, uint8_t, 
int64_t *);
 static int32_t KeSetPriorityThread(struct thread *, int32_t);
 static void dummy(void);
 
+static struct proc *ndisproc;
 static struct mtx ntoskrnl_dispatchlock;
 static struct mtx ntoskrnl_interlock;
 static kspin_lock ntoskrnl_cancellock;
@@ -270,7 +271,7 @@ ntoskrnl_libinit()
 {
image_patch_table   *patch;
int error;
-   struct proc *p;
+   struct thread   *t;
kdpc_queue  *kq;
callout_entry   *e;
int i;
@@ -320,8 +321,9 @@ ntoskrnl_libinit()
 #endif
kq = kq_queues + i;
kq->kq_cpu = i;
-   error = kproc_create(ntoskrnl_dpc_thread, kq, &p,
-   RFHIGHPID, NDIS_KSTACK_PAGES, "Windows DPC %d", i);
+   error = kproc_kthread_add(ntoskrnl_dpc_thread, kq,
+   &ndisproc, &t, RFHIGHPID, NDIS_KSTACK_PAGES, "ndis",
+   "Windows DPC %d", i);
if (error)
panic("failed to launch DPC thread");
}
@@ -332,8 +334,9 @@ ntoskrnl_libinit()
 
for (i = 0; i < WORKITEM_THREADS; i++) {
kq = wq_queues + i;
-   error = kproc_create(ntoskrnl_workitem_thread, kq, &p,
-   RFHIGHPID, NDIS_KSTACK_PAGES, "Windows Workitem %d", i);
+   error = kproc_kthread_add(ntoskrnl_workitem_thread, kq,
+   &ndisproc, &t, RFHIGHPID, NDIS_KSTACK_PAGES, "ndis",
+   "Windows Workitem %d", i);
if (error)
panic("failed to launch workitem thread");
}
@@ -2701,7 +2704,7 @@ ntoskrnl_workitem_thread(arg)
 #if __FreeBSD_version < 502113
mtx_lock(&Giant);
 #endif
-   kproc_exit(0);
+   kthread_exit();
return; /* notreached */
 }
 
@@ -3380,7 +3383,7 @@ PsCreateSystemThread(handle, reqaccess, objattrs, phandle,
 {
int error;
thread_context  *tc;
-   struct proc *p;
+   struct thread   *t;
 
tc = malloc(sizeof(thread_context), M_TEMP, M_NOWAIT);
if (tc == NULL)
@@ -3389,15 +3392,16 @@ PsCreateSystemThread(handle, reqaccess, objattrs, 
phandle,
tc->tc_thrctx = thrctx;
tc->tc_thrfunc = thrfunc;
 
-   error = kproc_create(ntoskrnl_thrfunc, tc, &p,
-   RFHIGHPID, NDIS_KSTACK_PAGES, "Windows Kthread %d", ntoskrnl_kth);
+   error = kproc_kthread_add(ntoskrnl_thrfunc, tc, &ndisproc, &t,
+   RFHIGHPID, NDIS_KSTACK_PAGES, "ndis",
+   "Windows Kthread %d", ntoskrnl_kth);
 
if (error) {
free(tc, M_TEMP);
return (STATUS_INSUFFICIENT_RESOURCES);
}
 
-   *handle = p;
+   *handle = t;
ntoskrnl_kth++;
 
return (STATUS_SUCCESS);
@@ -3432,7 +3436,7 @@ PsTerminateSystemThread(status)
 #if __FreeBSD_version < 502113
mtx_lock(&Giant);
 #endif
-   kproc_exit(0);
+   kthread_exit();
return (0); /* notreached */
 }
 
@@ -3740,7 +3744,7 @@ ntoskrnl_dpc_thread(arg)
 #if __FreeBSD_version < 502113
mtx_lock(&Giant);
 #endif
-   kproc_exit(0);
+   kthread_exit();
return; /* notreached */
 }
 
___
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"

ndis: fix ugly code

[Paul B Mahol]

Hi,

If clang did not complain, I would probbaly never spot it.

Patch attached.
diff --git a/sys/compat/ndis/subr_ntoskrnl.c b/sys/compat/ndis/subr_ntoskrnl.c
index ba1e49f..714fcd8 100644
--- a/sys/compat/ndis/subr_ntoskrnl.c
+++ b/sys/compat/ndis/subr_ntoskrnl.c
@@ -274,7 +274,6 @@ ntoskrnl_libinit()
kdpc_queue  *kq;
callout_entry   *e;
int i;
-   charname[64];
 
mtx_init(&ntoskrnl_dispatchlock,
"ntoskrnl dispatch lock", MTX_NDIS_LOCK, MTX_DEF|MTX_RECURSE);
@@ -321,9 +320,8 @@ ntoskrnl_libinit()
 #endif
kq = kq_queues + i;
kq->kq_cpu = i;
-   sprintf(name, "Windows DPC %d", i);
error = kproc_create(ntoskrnl_dpc_thread, kq, &p,
-   RFHIGHPID, NDIS_KSTACK_PAGES, name);
+   RFHIGHPID, NDIS_KSTACK_PAGES, "Windows DPC %d", i);
if (error)
panic("failed to launch DPC thread");
}
@@ -334,9 +332,8 @@ ntoskrnl_libinit()
 
for (i = 0; i < WORKITEM_THREADS; i++) {
kq = wq_queues + i;
-   sprintf(name, "Windows Workitem %d", i);
error = kproc_create(ntoskrnl_workitem_thread, kq, &p,
-   RFHIGHPID, NDIS_KSTACK_PAGES, name);
+   RFHIGHPID, NDIS_KSTACK_PAGES, "Windows Workitem %d", i);
if (error)
panic("failed to launch workitem thread");
}
@@ -3382,7 +3379,6 @@ PsCreateSystemThread(handle, reqaccess, objattrs, phandle,
void*thrctx;
 {
int error;
-   chartname[128];
thread_context  *tc;
struct proc *p;
 
@@ -3393,9 +3389,8 @@ PsCreateSystemThread(handle, reqaccess, objattrs, phandle,
tc->tc_thrctx = thrctx;
tc->tc_thrfunc = thrfunc;
 
-   sprintf(tname, "windows kthread %d", ntoskrnl_kth);
error = kproc_create(ntoskrnl_thrfunc, tc, &p,
-   RFHIGHPID, NDIS_KSTACK_PAGES, tname);
+   RFHIGHPID, NDIS_KSTACK_PAGES, "Windows Kthread %d", ntoskrnl_kth);
 
if (error) {
free(tc, M_TEMP);
___
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: Re: VIMAGE + NDIS

[Paul B Mahol]

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.

Note that, for unknown reason (must be bug from old days) if_ndis.c calls
rt_ifmsg() on its own via NdisMIndicateStatusComplete(), and I see no
point to do that.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre

Re: Re: convert Windows NDIS drivers for use with FreeBSD

[Paul B Mahol]

On 5/14/10, jiani1012  wrote:
> Yes, I use ndisgen(8) instead. Input the netathw.inf and athw.sys file,
> appears:
> segmentation fault (core dumped)
> CONVERSION FAILED

inf file have missing end of line at end, open file in text editor and
add empty line at and, and try again.
___
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: convert Windows NDIS drivers for use with FreeBSD

[Paul B Mahol]

On 5/7/10, jiani1012  wrote:
> Hi all,
>   I am using xp3264-7.7.0.329-whql.zip file from Atheros.
>  #cd /sys/modules/ndis
>  #make install
>  #cd /sys/modules/if_ndis
>  #make install
>  #ndiscvt -i netathwx.inf -s athwx.sys -o ndis_driver_data.h
> (syntax error)
>  When trying to convert the ones athwx.sys and netathwx.inf I am getting
> the error:
> > ndiscvt: line 5117: : syntax error.
> > CONVERSION FAILED
>  same for  netathw.inf athw.sys
>  How to do it?
> Thank you in advance!
>
> Jeny

Why you are not using ndisgen(8)?
___
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"

NDISulator bug on amd64

[Paul B Mahol]

On 1/16/10, Paul B Mahol  wrote:
> On 1/11/10, Paul B Mahol  wrote:
>> On 1/11/10, Bob Johnson  wrote:
>>> On 1/9/10, Paul B Mahol  wrote:
>>>> On 12/16/09, Bob Johnson  wrote:
>>>>> I'm using an ExpressCard for wireless networking because there seems
>>>>> to be no driver for the internal card in my laptop (and NDIS panics
>>>>> the system). The Expresscard shows up as a PCI device and works fine,
>>>>
>>>> How are you using NDIS and when system panic what is displayed?
>>>
>>> I tried to use ndisgen with the internal Dell 1397 card. I don't have
>>> details available right now, although if you need them I can try it
>>> again. When I did the kldload the system spit out error messages about
>>> unknown symbols and then panic-ed. I did some searching of the
>>> archives and found a message describing the same symptoms, and the
>>> response posted was that it indicated that the Windows driver made API
>>> calls that were not implemented in the NDIS wrapper.
>>>
>>> This was a 64-bit Windows driver and an amd64 FreeBSD system. Similar
>>> results in both
>>> FreeBSD 7.2 and 8.0.
>>>
>>> It appears that kern/132672 is describing the same or a very similar
>>> issue.  It also suggests that there is a more fundamental problem than
>>> the unrecognized symbols.
>>>
>>> I can try to reproduce the problem tonight if you want me to.
>>>
>>> Thanks,
>>
>> If you have debug kernel, then make breakpoint for MSCALL2 (kldload
>> ndis.ko before that): `break MSCALL2'
>
> Should be `break w86_64_call2'
>> Then load ndisgen module.
>>
>> Then single step it with `s' it should panic after few steps.
>> At least this is issue I'm experiencing on amd64, it fails in
>> DriverEntry().
>
> with the same virtual address as in kern/132672.

I fixed bug that caused panic on amd64 in DriverEntry().

Code is available from here:

www.gitorious.org/NDISulator
___
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: kern/142197: [ndis] [patch] ndis is missing media status reporting

[Paul B Mahol]

The following reply was made to PR kern/142197; it has been noted by GNATS.

From: Paul B Mahol 
To: Roman Bogorodskiy 
Cc: bug-follo...@freebsd.org, rpa...@freebsd.org
Subject: Re: kern/142197: [ndis] [patch] ndis is missing media status 
reporting
Date: Wed, 6 Jan 2010 11:54:48 +0100

 On 1/6/10, Roman Bogorodskiy  wrote:
 > Hello,
 >
 > Seems like there's a minor problem with that:
 >
 > cc1: warnings being treated as errors
 > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function
 > 'ndis_media_status':
 > /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:2252: warning:
 > passing argument 4 of 'ndis_get_info' from incompatible pointer type
 > *** Error code 1
 >
 > As ndis_get_info accepts 'int', not 'size_t', so after applying this:
 >
 > --- if_ndis.c.orig   2010-01-06 12:15:17.0 +0300
 > +++ if_ndis.c2010-01-06 12:17:03.0 +0300
 > @@ -2243,7 +2243,7 @@
 >  struct ieee80211vap *vap = ifp->if_softc;
 >  struct ndis_softc *sc = vap->iv_ic->ic_ifp->if_softc;
 >  uint32_t txrate;
 > -size_t len;
 > +int len;
 >
 >  if (!NDIS_INITIALIZED(sc))
 >  return;
 >
 > it compiles fine.
 >
 > Roman Bogorodskiy
 >
 
 Right, I generated patch from my git repo which is less broken then
 code in CURRENT.
 
 ndis_get_info should really use size_t and not int for *buflen
 
 -- 
 Paul B Mahol
___
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: ndis: missing media status reporting

[Paul B Mahol]

On 12/31/09, Paul B Mahol  wrote:
> Hi,
>
> if_ndis.c doesnt update link speed when associated.
>
> Patch is available here:
> misc/142197: ndis is missing media status reporting
> http://www.freebsd.org/cgi/query-pr.cgi?pr=142197

Anyone?

-- 
Paul B Mahol
___
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"

ndis: missing media status reporting

[Paul B Mahol]

Hi,

if_ndis.c doesnt update link speed when associated.

Patch is available here:
misc/142197: ndis is missing media status reporting
http://www.freebsd.org/cgi/query-pr.cgi?pr=142197
-- 
Paul B Mahol
___
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: ap_scan values

[Paul B Mahol]

On 12/20/09, Steven Friedrich  wrote:
> I've been using a Project Evil Windows ethernet driver wrapped by NDIS.
> I use wpa, and in /etc/wpa_supplicant.conf, I have the following line:
> ap_scan=2
>
> Our man page, for wpa_supplicant.conf states that this value should always
> be
> 1, but I had to set it to 2 to get it to work. I believe this is because
> we're
> using a windows driver so we need to pretend we're running Windows.
>
> So I had to set it to 1 when I want to use the bwi driver (new for 8.0) or
> uath driver.
>
> Once I made this change, bwi works.
> uath still escapes me.
>
> I hope someone changes the man page to let people know they need to use 2
> when
> using the NDIS driver.

I dont use ap_scan at all and it works for me.
Using ap_scan=2 is just workaround for buggy/broken scan results.

-- 
Paul B Mahol
___
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: 8.0R, AMD64 and wpi is giving me major grief

[Paul B Mahol]

On 12/17/09, Kurt Buff  wrote:
> Anyone?
>
> BTW - I dual-boot this with XP, and don't have any issues with
> wireless when running that. Also works flawlessly when running wired,
> over em0.
>
> I've just done a BIOS update - I'll be trying that out tomorrow, and
> will update this with results.
>
> Kurt
>
> On Mon, Dec 14, 2009 at 19:21, Kurt Buff  wrote:
>> All,
>>
>> I've got a Lenovo t61 with 4gbytes RAM that is giving me fits.
>>
>> It's got a 3945abg chip in it, and it's getting really flaky. I can
>> boot it up, and work at the console for a while, and that seems to
>> work OK, usually.
>>
>> However, today, when I start up my gui (xfce4), wireless just dies on
>> me. For a week before, it would usually run for a while (sometimes
>> days) before dying on me and requiring a reboot.
>>
>> Below is a snippet of /var/log/messages - Does this mean anything to
>> anyone? Is there anything I can do to recover once this happens?
>>
>> Thanks,
>>
>> Kurt
>>
>> Dec 14 07:16:43 grimsqueaker kernel: wlan0: Ethernet address:
>> 00:1f:3c:4d:e2:55
>> Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 1
>> Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 3
>> Dec 14 07:16:43 grimsqueaker kernel: wpi0: timeout resetting Tx ring 4
>> Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification
>> version 10e02 alive 1
>> Dec 14 07:16:43 grimsqueaker kernel: microcode alive notification
>> version 10e02 alive 1
>> Dec 14 07:16:43 grimsqueaker kernel: wpi_newstate: INIT -> SCAN flags 0x0
>> Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-SCAN-RESULTS
>> Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Trying to associate
>> with 00:23:69:82:b2:bf (SSID='5705NE197th' freq=2462 MHz)
>> Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: SCAN -> AUTH flags 0x0
>> Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8005 cck f ofdm
>> 15
>> Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: AUTH -> ASSOC flags 0x0
>> Dec 14 07:16:45 grimsqueaker kernel:
>> Dec 14 07:16:45 grimsqueaker wpa_supplicant[381]: Associated with
>> 00:23:69:82:b2:bf
>> Dec 14 07:16:45 grimsqueaker kernel: wpi_newstate: ASSOC -> RUN flags 0x0
>> Dec 14 07:16:45 grimsqueaker kernel: config chan 11 flags 8035
>> Dec 14 07:16:45 grimsqueaker kernel: wlan0: link state changed to UP
>> Dec 14 07:16:45 grimsqueaker kernel: wpi0: need multicast update callback
>> Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: WPA: Key negotiation
>> completed with 00:23:69:82:b2:bf [PTK=CCMP GTK=CCMP]
>> Dec 14 07:16:46 grimsqueaker wpa_supplicant[381]: CTRL-EVENT-CONNECTED
>> - Connection to 00:23:69:82:b2:bf completed (auth) [id=0 id_str=]
>> Dec 14 07:16:53 grimsqueaker dhclient: New IP Address (wlan0):
>> 192.168.151.104
>> Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback
>> Dec 14 07:16:53 grimsqueaker kernel: wpi0: need multicast update callback
>> Dec 14 07:16:53 grimsqueaker dhclient: New Subnet Mask (wlan0):
>> 255.255.255.0
>> Dec 14 07:16:53 grimsqueaker dhclient: New Broadcast Address (wlan0):
>> 192.168.151.255
>> Dec 14 07:16:53 grimsqueaker dhclient: New Routers (wlan0): 192.168.151.1
>> Dec 14 07:17:56 grimsqueaker kernel: drm0:  on vgapci0
>> Dec 14 07:17:56 grimsqueaker kernel: info: [drm] MSI enabled 1 message(s)
>> Dec 14 07:17:56 grimsqueaker kernel: vgapci0: child drm0 requested
>> pci_enable_busmaster
>> Dec 14 07:17:56 grimsqueaker kernel: info: [drm] AGP at 0xe000 256MB
>> Dec 14 07:17:56 grimsqueaker kernel: info: [drm] Initialized i915 1.6.0
>> 20080730
>> Dec 14 07:17:57 grimsqueaker kernel: drm0: [ITHREAD]
>> Dec 14 07:18:24 grimsqueaker kernel: pid 1424 (xfce4-panel), uid 1001:
>> exited on signal 11 (core dumped)
>> Dec 14 07:25:43 grimsqueaker wpa_supplicant[381]: WPA: Group rekeying
>> completed with 00:23:69:82:b2:bf [GTK=CCMP]
>> Dec 14 07:48:38 grimsqueaker kernel: wpi0: device timeout
>> Dec 14 07:48:39 grimsqueaker kernel: wpi0: could not set power mode
>>

Enable all wpi debug messages?

-- 
Paul B Mahol
___
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: kern/141376: [ndis] [patch] broken scan by passing ies and ies_len pointer to net80211

[Paul B Mahol]

On 12/11/09, lini...@freebsd.org  wrote:
> Old Synopsis: ndis: broken scan
> New Synopsis: [ndis] [patch] broken scan by passing ies and ies_len pointer
  New Synopsis: [ndis] [patch] broken scan by _not_ passing ies and
ies_len pointer
> to net80211
>
> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
> Responsible-Changed-By: linimon
> Responsible-Changed-When: Fri Dec 11 19:48:19 UTC 2009
> Responsible-Changed-Why:
> Over to maintainer(s).
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=141376
> ___
> 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"
>
-- 
Paul B Mahol
___
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"

patch: ndisusb: show device description on attach

[Paul B Mahol]

--- /sys/dev/if_ndis/if_ndis_usb.c  2009-11-25 21:49:03.0 +
+++ if_ndis_usb.c   2009-12-12 12:17:27.0 +
@@ -165,6 +165,7 @@
driver_object   *drv;
int devidx = 0;

+   device_set_usb_desc(self);
db = uaa->driver_ivar;
sc = (struct ndis_softc *)dummy;
sc->ndis_dev = self;

-- 
Paul B Mahol
___
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: ndis: broken scan

[Paul B Mahol]

On 12/7/09, Paul B Mahol  wrote:
> Patch attached to fix scan results.
> Bug is obvious if you use -v flag:
> ifconfig -v wlan0 list scan
>
> It is interesting, that it never got noticed. I got hit with this one
> when working on WPA instead of WPA2(RSN). In that case wpa_supplicant
> would never pick AP because it doesnt see WPA, it could see only RSN,
> now with this patch it see much more, like WME; and
> ifconfig  wlan0 list scan
> output is more useful.
>
http://www.freebsd.org/cgi/query-pr.cgi?pr=141376
Bump!
-- 
Paul B Mahol
___
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"

ndis: broken scan

[Paul B Mahol]

Patch attached to fix scan results.
Bug is obvious if you use -v flag:
ifconfig -v wlan0 list scan

It is interesting, that it never got noticed. I got hit with this one
when working on WPA instead of WPA2(RSN). In that case wpa_supplicant
would never pick AP because it doesnt see WPA, it could see only RSN,
now with this patch it see much more, like WME; and
ifconfig  wlan0 list scan
output is more useful.


if_ndis.c.patch
Description: Binary data
___
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: wlan adhoc mode crash

[Paul B Mahol]

On 12/1/09, John Hay  wrote:
> Hi,
>
> I'm not sure if this is the best list.
>
> I'm trying to get our Avila (arm) boards with atheros wireless cards
> upgraded from 7.2 to 8.0. We use adhoc mode and I get a panic in
> ieee80211_getcapinfo() because the chan pointer is 0x which seems
> to mean IEEE80211_CHAN_ANY in other places. So the question is, should
> ieee80211_getcapinfo() never be called with chan being 0x or should
> it know how to handle that case?

IEEE80211_CHAN_ANY is there to mean no channel is selected, so you can not call
getcapinfo with such argument.
___
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: if_ndis patch

[Paul B Mahol]

On 10/31/09, Coleman Kane  wrote:
> Paul,
>
> Did you get to send this to sam@, etc ?

Negative, now let @net know about it too.

> On Fri, 2009-10-30 at 16:52 +0100, Paul B Mahol wrote:
>> Hi,
>>
>> There is no point to do scanning how it is currently done:
>>
>> Index: if_ndis.c
>> ===
>> --- if_ndis.c   (revision 198675)
>> +++ if_ndis.c   (working copy)
>> @@ -3398,11 +3398,8 @@
>> struct ifnet *ifp = ic->ic_ifp;
>> struct ndis_softc *sc = ifp->if_softc;
>> struct ieee80211vap *vap;
>> -   struct ieee80211_scan_state *ss;
>> -   ndis_80211_ssid ssid;
>> int error, len;
>>
>> -   ss = ic->ic_scan;
>> vap = TAILQ_FIRST(&ic->ic_vaps);
>>
>> if (!NDIS_INITIALIZED(sc)) {
>> @@ -3411,20 +3408,6 @@
>> return;
>> }
>>
>> -   len = sizeof(ssid);
>> -   bzero((char *)&ssid, len);
>> -   if (ss->ss_nssid == 0)
>> -   ssid.ns_ssidlen = 1;
>> -   else {
>> -   /* Perform a directed scan */
>> -   ssid.ns_ssidlen = ss->ss_ssid[0].len;
>> -   bcopy(ss->ss_ssid[0].ssid, ssid.ns_ssid, ssid.ns_ssidlen);
>> -   }
>> -
>> -   error = ndis_set_info(sc, OID_802_11_SSID, &ssid, &len);
>> -   if (error)
>> -   DPRINTF(("%s: set ESSID failed\n", __func__));
>> -
>> len = 0;
>> error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN,
>> NULL, &len);
___
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: PCI card for wlan AP

[Paul B Mahol]

On 10/7/09, Boris Kochergin  wrote:
> Rui Paulo wrote:
>> On 7 Oct 2009, at 20:04, Boris Kochergin wrote:
>>>
>>> The heavily-used ones exhibit the problem described at:
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022894.html
>>>
>>>
>>>
>>> ...but that's a driver, not a hardware, issue. The one in the router
>>> at my house doesn't exhibit the problem, the two differences there
>>> being that the machine is 7.0-RELEASE, and there are only a couple of
>>> clients connected to it, as opposed to the ~30 connected to my
>>> heavily-used ones.
>>
>> Are you sure you have sufficient RAM to hold 30 users?
>>
>> What you seem to be saying is that the ath driver is leaking mbufs and
>> hence you get a panic, right?
>>
>> --
>> Rui Paulo
>>
>>
>>
> Pretty sure. The Soekris has 256 MB of RAM. I suspect that it's a leak
> because things are usually great, even with ~30 users, with the
> "80211node" portion from "vmstat -m" only taking a few hundred KiB of
> RAM. Every few days, it spikes to over 100 MiB, and the "ath0:

Interesting, is it actually memory leak?
(I try to hunt one down when using if_ndis(4) but without success)

> ath_rx_proc: no mbuf!" kernel messages appear, often followed by a
> panic. I haven't had time to try another rate-control algorithm, as per
> the responses to my post, but I'll report back when I do get around to it.
___
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: WLAN performance Windows/XP ./. FreeBSD 8-CURRENT

[Paul B. Mahol]

On 9/28/09, Matthias Apitz  wrote:
>
> Hello,
>
> I am wondering what could cause the following WLAN performance diff
> between a XP and 8-CURRENT laptop, sitting side by side and connected to
> the same AP:
>
> OS   XP   8-CURRENT
> NIC  Intel 3945ABGAtheros 5424/2424
> Ping 6ms  116ms
> downstream   9.05Mbit/s   6.58Mbit/s
> upstream 6.58Mbit/s   4.55Mbit/s
>
> measured with http://www.speedtest.net/ against the same remote server
> at the same time... Any ideas?

Emulated flash?

-- 
Paul
___
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: ndis lor: hal preemption lock

[Paul B. Mahol]

On 7/15/09, Paul B. Mahol  wrote:
> On 7/4/09, Paul B. Mahol  wrote:
>> On 6/18/09, Coleman Kane  wrote:
>>> I've committed this one as r194432.
>>
>> Ah, that one introduced regression.
>> Switching ndisX up before creating vap will cause panic.
>> Here is fix:
>>
>> --- /sys/dev/if_ndis/if_ndis.c  2009-06-28 09:15:54.0 +
>> +++ if_ndis.c   2009-07-04 10:23:41.0 +
>> @@ -2292,6 +2292,8 @@
>> ifp = sc->ifp;
>> ic = ifp->if_l2com;
>> vap = TAILQ_FIRST(&ic->ic_vaps);
>> +   if (vap == NULL)
>> +   return;
>>
>> if (!NDIS_INITIALIZED(sc)) {
>> DPRINTF(("%s: NDIS not initialized\n", __func__));
>
> Bump!
>
> Please commit.

Beep!

kern/136895

-- 
Paul
___
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: ndis lor: hal preemption lock

[Paul B. Mahol]

On 7/4/09, Paul B. Mahol  wrote:
> On 6/18/09, Coleman Kane  wrote:
>> I've committed this one as r194432.
>
> Ah, that one introduced regression.
> Switching ndisX up before creating vap will cause panic.
> Here is fix:
>
> --- /sys/dev/if_ndis/if_ndis.c  2009-06-28 09:15:54.0 +
> +++ if_ndis.c   2009-07-04 10:23:41.0 +
> @@ -2292,6 +2292,8 @@
> ifp = sc->ifp;
> ic = ifp->if_l2com;
> vap = TAILQ_FIRST(&ic->ic_vaps);
> +   if (vap == NULL)
> +   return;
>
> if (!NDIS_INITIALIZED(sc)) {
> DPRINTF(("%s: NDIS not initialized\n", __func__));

Bump!

Please commit.

-- 
Paul
___
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: system panic when i use ath without swap,some advice?

[Paul B. Mahol]

On 7/10/09, **  wrote:
> Hi all
>
> My system is atom n270 1G RAM, freebsd 7.2 release .without swap.
> When my ath is associated with an AP, and the traffic is high, the
> system will panic and reboot. this happened many times.
> Can you give me some advice please.
> thanks
>
> Micheal Kevin
> ___
> 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"
>

Provide backtrace from crash, and "vmstat -m" output.

-- 
Paul
___
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: ndis and USB wirelless ethernet

[Paul B. Mahol]

On 6/27/09, Nikos Vassiliadis  wrote:
> Weongyo Jeong wrote:
>> Could you show me the *full* result after enabling `sysctl debug.ndis=1'?
>> Maybe steps would be as follows:
>>
>>  # kldload ndis if_ndis NDIS_module
>>  # sysctl debug.ndis=1
>>  [then plug-in USB stick]
>
> It goes like this:
>
> ugen1.2:  at usbus1
> ndis0: NDIS API version: 5.1
> attach done.
> lock order reversal:
>   1st 0xc0edc900 HAL preemption lock (HAL lock) @
> /usr/src/sys/compat/ndis/subr_hal.c:416
>   2nd 0xc23b19ec NDIS USB (network driver) @
> /usr/src/sys/compat/ndis/subr_usbd.c:803
> KDB: stack backtrace:
> db_trace_self_wrapper(c0c0f65b,c755e8b8,c08af235,c08a015b,c0c1249e,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c08a015b,c0c1249e,c2117a58,c2114040,c755e914,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0c1249e,c23b19ec,c0c3cf54,c2114040,c0c36d8d,...) at
> _witness_debugger+0x25
> witness_checkorder(c23b19ec,9,c0c36d8d,323,0,...) at
> witness_checkorder+0x839
> _mtx_lock_flags(c23b19ec,0,c0c36d8d,323,c2692400,...) at
> _mtx_lock_flags+0xc4
> usbd_irpcancel(c24f1400,c2692400,c755ea28,c755ea74,c0acfe2a,...) at
> usbd_irpcancel+0x5c
> end(c2692400,c2976b80,c26ea000,c26ea000,c755ea5c,...) at 0xc220c2e1
> end(c26ea000,0,0,c26ea294,c755ea78,...) at 0xc22036e1
> ndis_wg111v3_sys_drv_data_start(c26ea000,0,c26ea000,c26ea000,0,...) at
> ndis_wg111v3_sys_drv_data_start+0x5cac
> ndis_wg111v3_sys_drv_data_start(c26ea000,c2202000,c26ea000,0,c755eaa8,...)
> at ndis_wg111v3_sys_drv_data_start+0x5fec
> ndis_wg111v3_sys_drv_data_start(c26ea000,c755eab4,c755eacc,c26b206a,c755eae4,...)
> at ndis_wg111v3_sys_drv_data_start+0x603f
> ndis_wg111v3_sys_drv_data_start(c26ea000,c23b186c,c26ea000,c0ac7429,c26b206a,...)
> at ndis_wg111v3_sys_drv_data_start+0x611f
> x86_stdcall_call(c23b1800,c755eb0e,c755eb14,c755eb18,c2aa60e4,...) at
> x86_stdcall_call+0x1e
> ndis_attach(c23d6b80,c23d6b80,c0bb64fd,0,c238da24,...) at ndis_attach+0xf71
> ndisusb_attach(c23d6b80,c221885c,c0cef938,c0bfc63d,8000,...) at
> ndisusb_attach+0xdb
> device_attach(c23d6b80,4,c0c0ed75,9f1) at device_attach+0x36f
> device_probe_and_attach(c23d6b80,c755ec1c,,c2275800,0,...) at
> device_probe_and_attach+0x4e
> usb_probe_and_attach_sub(c2275800,0,c0bf354f,4c4,0,...) at
> usb_probe_and_attach_sub+0xde
> usb_probe_and_attach(c2275800,ff,c2399800,1,0,...) at
> usb_probe_and_attach+0x1b3
> uhub_explore(c2399800,0,c0bf1fec,cd,c229ed34,...) at uhub_explore+0x766
> usb_bus_explore(c229ed34,c229edac,c0bfb560,51,c0d5fec0,...) at
> usb_bus_explore+0xbb
> usb_process(c229ecd4,c755ed38,c0c079d2,334,c21a7d48,...) at usb_process+0xde
> fork_exit(c07a6de0,c229ecd4,c755ed38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc755ed70, ebp = 0 ---
>
>>  # ifconfig wlan0 create wlandev ndis0
>>  # ifconfig wlan0 ssid blah up
>
> lab# ifconfig wlan0 ssid blah up
> load: 0.06  cmd: ifconfig 1245 [-] 1.92r 0.02u 0.12s 0% 1568k
> load: 0.06  cmd: ifconfig 1245 [-] 2.25r 0.02u 0.12s 0% 1568k
>
> lab# ifconfig ndis0 up
> load: 0.06  cmd: ifconfig 1254 [KeWFS] 1.27r 0.00u 0.01s 0% 1568k
> load: 0.06  cmd: ifconfig 1254 [KeWFS] 1.66r 0.00u 0.01s 0% 1568k
>
>
> lab# ifconfig ndis0
> ndis0: flags=8803 metric 0 mtu 2290
>  ether 00:1b:2f:be:78:aa
>  media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
>  status: associated
> lab# ifconfig wlan0
> wlan0: flags=8843 metric 0 mtu 1500
>  ether 00:1b:2f:be:78:aa
>  media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>  status: no carrier
>  ssid blah channel 1 (2412 Mhz 11b)
>  country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60
>  bintval 0
> lab# ifconfig wlan0 scan
> lab# ifconfig wlan0 list scan
> lab#
>
> Any ideas?

Are you saying that nothing is displayed on console(dmesg) by kernel?


-- 
Paul
___
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: hostapd with 802.1X EAP-TLS/TTLS support

[Paul B. Mahol]

On 6/18/09, Vladimir Terziev  wrote:
> Hi,
>
> i try to setup wireless access point at home, based on FreeBSD
> 7.2R-i386, ral(4) wireless card and hostpad(8).
>
> I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. I
> issued a custom SSL certificate for the hostapd(8) and put the following
> directives in hostapd.conf:
>
> eap_server=0
> ca_cert=/usr/local/etc/myCA.crt.pem
> server_cert=/usr/local/etc/hostapd.server.crt.pem
> private_key=/usr/local/etc/hostapd.server.key.pem
> private_key_passwd=some_pass
>
> When i tried to start the hostapd(8) i got the following errors:
>
> Line 15: unknown configuration item 'eap_server'
> Line 16: unknown configuration item 'ca_cert'
> Line 17: unknown configuration item 'server_cert'
> Line 18: unknown configuration item 'private_key'
> Line 19: unknown configuration item 'private_key_passwd'
>
> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at all
> and if "not" why ?

802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8).

-- 
Paul
___
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: Unable to clone wlan device

[Paul B. Mahol]

On 6/9/09, Vladimir Terziev  wrote:
> The actual problem, i play with wlan cloning because of, is, i try to
> set up a FreeBSD based wireless access point either based on ral(4) or
> iwi(4) interface.
>
> The ral(4) (which is "Edimax EW-7128g") seems more suitable for that,
> since it has HOSTAP capability, but when i tried to run a hostapd(8) on
> it, i got an error about inability TKIP to be configured by hostpad(8).
> Since TKIP is not present as a capability of the wireless adapter, i
> decided to clone it and use the wlan_tkip(4) module to do the work.

That is not important.
You don't need to clone device to use TKIP.
If device or device driver doesn't support encryption in hardware, software
encryption will do the work via wlan_tkip(4).
There is only one exception to this and that are ndis(4) drivers. NDIS
do not allow such workaround.

-- 
Paul
___
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: Unable to clone wlan device

[Paul B. Mahol]

On 6/9/09, Vladimir Terziev  wrote:
> Thanks Paul,
>
> i have tried the same with ral(4) device and got a similar result.
>
> What about ral(4), does it support virtual interfaces ?

No it doesn't. The only chips capable of multi bssid I'm aware of
are atheros ones and only on >= 8.0.

> On Tue, 2009-06-09 at 11:34 +0300, Paul B. Mahol wrote:
>> wlan cloning is only available on 8.0, and iwi supports only one
>> virtual
>> interface at any time.

-- 
Paul
___
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: Unable to clone wlan device

[Paul B. Mahol]

wlan cloning is only available on 8.0, and iwi supports only one virtual
interface at any time.

-- 
Paul
___
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: Problem/freezes with if_bwi and firmware

[Paul B. Mahol]

On 5/11/09, Gustau Perez  wrote:
>
>   Hi,
>
>   I'm using a Broadcom BCM4312 with i386 FreeBSD-8.0 updated May 08
> 2009. Ports up to date. Using net/bwi-firmware-kmod. Loading
> first bwi_v3_ucode and then  if_bwi.
>
>   When starting the supplicant, it associates fine and it works for a
> period of time. From time to time I start to lose signal, I'm my log I
> can see the following message :
>
> May 11 08:42:51 gusiport kernel: bwi0: firmware rev 0x0127,
> patch level 0x000e
> May 11 08:42:51 gusiport kernel: bwi0: bwi_intr: intr PHY TX
> error
>
>   Many of those messages per second. This is the first problem with
> if_bwi.  It forces me to restart by hand the wlan1 device associated to
> bwi0. And here comes the freeze (the second problem I encountered). If I
> try restarting like this :
>
>  /etc/rc.d/netif stop wlan1 && /etc/rc.d/netif start wlan1
>
>it works (until the PHY TX error appears againg). If I try like :
>
> /etc/rc.d/netif restart
>
>or if I try  :
>
>/etc/rc.d/netif stop bwi0
>
>the machine freezes. If i try to kldunload the module while in use
> (if there's a wlan device created) the machine freezes too. It can be
> unloaded only if there is not any wlan associated to the bwi device.

Is this mini-pci card? (pciconf -lv)

-- 
Paul
___
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: kernel crashes with ndis & -CURRENT

[Paul B. Mahol]

On 5/26/09, Adam K Kirchhoff  wrote:
>
> In an attempt to get the native drivers working on a particular
> wireless network at work I updated to -CURRENT to see if I'd have any
> more luck ( http://www.freebsd.org/cgi/query-pr.cgi?pr=131153&cat= ).
>
> Unfortunately, that didn't work out so I was decided to revert to the
> ndis drivers.  I created a new module using the same sys and inf file
> that mostly worked on -STABLE (with frequent UP and DOWN messages, but
> better than nothing).  Unfortunately, now I get a complete kernel panic.
>
> Please let me know if this is a better question for freebsd-current.
> Here's the backtrace:

Please update your kernel after r192765, this issue have been already
fixed on CURRENT.

-- 
Paul
___
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: Signal sensitivity problem with if_rum

[Paul B. Mahol]

On 5/3/09, Gustau Perez  wrote:
>
>> That information is misleading, I remmember reading somewhere that linux
>> rt73
>> had similar problems like rum but it got fixed, and is not present in
>> new kernels.
>> I think that problem originated for linux from now obsolete drivers.
>>
>> On what linux version and what drivers version do you experience
>> similar problems
>> with signal sensitivity like with rum?
>>
>>
>Hi,
>
>I'm seeing this in ubuntu 9.04 (kernel 2.6.28). It shows more or less
> the same figures we have in FBSD.

Try older versions, 8.X perhaps.

Linux folks tends to break various things all the time ...

>In linux, Bbp17 can be changed from userpace making iwconfig ${dev}
> bbp 17=0. But it automatically restores its previous value. Autotuning
> seems to be enable and I don't know how to disable it (the post I sent a
> few days ago about this is wrong or doesn't apply).

I dont belive that things are so much simple that changing only one bbp
all the time will fix signal sensitivity.

-- 
Paul
___
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: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics

[Paul B. Mahol]

On 7/13/08, ga...@freebsd.org  wrote:
> Old Synopsis: [ndis] with wep enters kdb.enter.unknown, panics
> New Synopsis: [ndis] [patch] with wep enters kdb.enter.unknown, panics
>
> State-Changed-From-To: feedback->open
> State-Changed-By: gavin
> State-Changed-When: Sun Jul 13 17:06:03 UTC 2008
> State-Changed-Why:
> Over to maintainers for evaluation
>
>
> Responsible-Changed-From-To: gavin->freebsd-net
> Responsible-Changed-By: gavin
> Responsible-Changed-When: Sun Jul 13 17:06:03 UTC 2008
> Responsible-Changed-Why:
> Submitter reports my patch fixes things for him
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=125181
>

As of recent CURRENT(r191746), this issue have been fixed.

-- 
Paul
___
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: Signal sensitivity problem with if_rum

[Paul B. Mahol]

On 5/2/09, Gustau Perez  wrote:
>
>>>   Any idea if is there anything to change/tune ?
>>>
>>
>> There is not just bbp17 to tune there are probably others much more
>> important
>> registers.
>>
>> But as I already mentioned that code is completly missing.
>>
>>
>I was not talking about autotuning features, which are missing as you
> pointed. Was talking
> just about changing/tuning values of some registers to increase
> reception sensitivity.
>
>   The people  of linux, seem to have increased the sensitivity by
> modifing bbp17 and disabling
> autotuning. I tried with bbp17 and for the autotuning disabled, well, we
> already have it
> implemented :) (just joking) Anyway, giving that I didn't get an
> increase of sensitivity, I think we'll
> need the help of the developers.
>
>   Well, this morning will try to increase sensitivity of those usb rum
> with a linux system, just to check
> what they say here :

That information is misleading, I remmember reading somewhere that linux rt73
had similar problems like rum but it got fixed, and is not present in
new kernels.
I think that problem originated for linux from now obsolete drivers.

On what linux version and what drivers version do you experience
similar problems
with signal sensitivity like with rum?

-- 
Paul
___
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: Signal sensitivity problem with if_rum

[Paul B. Mahol]

On 5/1/09, Gustau Perez  wrote:
>
>> There is several places where bbp17 is changed.
>>
>>
>
>Editing the code looking for calls to the function rum_bbp_write,
> I've been able to find where bbp17 is changed at init. Changing
> rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or 0x14
> doesn't seem to affect its behaviour.
>
>Lowering it even more (0x01for example) sometimes shows more
> reacheable AP's in range; but signal quality still very bad.
>  Changing RT2573_NOISE_FLOOR doesn't make any change (in terms of signal
> quality, which remains the same).
>
>   Any idea if is there anything to change/tune ?

There is not just bbp17 to tune there are probably others much more important
registers.

But as I already mentioned that code is completly missing.

-- 
Paul
___
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: Signal sensitivity problem with if_rum

[Paul B. Mahol]

On 5/1/09, Gustau Perez  wrote:
>
>   Hi,
>
>   I think this is right place to post, if it is not, please let me know.
>
>I'm experiencing problems with two different devices using if_rum.
> One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC
>
>   The first one is about sensitivity, which is very low: for example,
> I'm detecting just two or three networks around me (with windows both
> usb devices detect around 14 or 15 networks) and the reported signal is
> very low.Placing the sensor very near to my wireless network AP (which
> is a FreeBSD machine with atheros card placing the txpower to 20)
> reports a signal quality of 50% or 60%.
>
>   Linux presents the same problem (my wife's laptop with ubuntu shows
> the same figures, more or
>
>   The other one is that having such a low sensitivity makes those
> dongles unusable when making large transfers, mostly when using scp/sftp
> or sshfs (samba seems to make it work better for longer transfer, but
> finally the problem appears). At some given point, the dongles seem to
> lose contact with the AP (making ifconfig shows that wlan0 is still
> associated), waiting for a period of time (usually one or two minutes)
> the transfer continues. Probably both problems are related.
>
>   In order to debug the problem I tried looking dmesg in both my AP and
> my laptop (no trace). Tried looking at the ssh logs (when making large
> transfers, no clue). In the only place I found something was in the
> samba logs, only saying that there was a problem with the transfer
> (broken pipe, the socket is closed).
>
>   So :
>
>   In the linux world, I found that the register which controls the
> sensitivity is bbp17 :
>
> http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a
>
>Tried looking in
> /usr/src/sys/dev/usb/wlan/if_rum.c, but I got lost. Tried with sysctl -a
> | grep rum or grep wlan0, but no MiB related to sensitivity appeared.
>
>   Is there anything I can try ? How can I force bbp 17 to get 0 value ?
> Tried with rum_def_bbp in if_rum.c, changing 17 to 0. No luck.

There is several places where bbp17 is changed.

Last time I was exploring
rum I found that it lacks bbp auto tuning.
[Failed to implement it, because in meantime I broke chip :)]

-- 
Paul
___
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: NDIS - True OR False

[Paul B. Mahol]

On 3/25/09, Chris Ruiz  wrote:
>
> True OR False
>
> 1) NDIS only works with XP drivers.
>
> 2) NDIS only works with 32-bit drivers and wont work on amd64.
>
> There is a lot of conflicting information on various lists, forums and
> websites regarding NDIS.

http://en.wikipedia.org/wiki/NDIS

-- 
Paul
___
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: kern/132889: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver

[Paul B. Mahol]

On 3/21/09, lini...@freebsd.org  wrote:
> Old Synopsis: NDIS kernel crash on load BCM4321 AGN driver
> New Synopsis: [ndis] [panic] NDIS kernel crash on load BCM4321 AGN driver
>
> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
> Responsible-Changed-By: linimon
> Responsible-Changed-When: Sat Mar 21 15:25:09 UTC 2009
> Responsible-Changed-Why:
> Over to maintainer(s).
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=132889
> ___
> 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"
>

Cause of this panic may already been fixed in
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118439

But it still unknown why attach failed, so OP could provide more info with
changing sysctl debug.ndis to 1.

-- 
Paul
___
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: kern/132342: commit references a PR

[Paul B. Mahol]

On 3/9/09, dfilter service  wrote:
> The following reply was made to PR kern/132342; it has been noted by GNATS.
>
> From: dfil...@freebsd.org (dfilter service)
> To: bug-follo...@freebsd.org
> Cc:
> Subject: Re: kern/132342: commit references a PR
> Date: Mon,  9 Mar 2009 02:38:02 + (UTC)
>
>  Author: sam
>  Date: Mon Mar  9 02:37:52 2009
>  New Revision: 189550
>  URL: http://svn.freebsd.org/changeset/base/189550
>
>  Log:
>Fix TXPMGT handling:
>o correct dBm<->mW conversion logic
>o set net80211 TXPMGT capability only if driver reports it is capable
>
>    PR:    kern/132342
>Submitted by:  "Paul B. Mahol" 
>
>  Modified:
>head/sys/dev/if_ndis/if_ndis.c
>
>  Modified: head/sys/dev/if_ndis/if_ndis.c
> ==
>  --- head/sys/dev/if_ndis/if_ndis.c   Mon Mar  9 02:34:02 2009
> (r189549)
>  +++ head/sys/dev/if_ndis/if_ndis.c   Mon Mar  9 02:37:52 2009
> (r189550)
>  @@ -102,7 +102,7 @@ SYSCTL_INT(_hw_ndisusb, OID_AUTO, halt,
>   "Halt NDIS USB driver when it's attached");
>
>   /* 0 - 30 dBm to mW conversion table */
>  -const uint16_t dBm2mW[] = {
>  +static const uint16_t dBm2mW[] = {
>   1, 1, 1, 1, 2, 2, 2, 2, 3, 3,
>   3, 4, 4, 4, 5, 6, 6, 7, 8, 9,
>   10, 11, 13, 14, 16, 18, 20, 22, 25, 28,
>  @@ -749,7 +749,7 @@ ndis_attach(dev)
>   ic->ic_ifp = ifp;
>   ic->ic_opmode = IEEE80211_M_STA;
>   ic->ic_phytype = IEEE80211_T_DS;
>  -ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS | 
> IEEE80211_C_TXPMGT;
>  +ic->ic_caps = IEEE80211_C_STA | IEEE80211_C_IBSS;
>   setbit(ic->ic_modecaps, IEEE80211_MODE_AUTO);
>   len = 0;
>   r = ndis_get_info(sc, OID_802_11_NETWORK_TYPES_SUPPORTED,
>  @@ -928,6 +928,11 @@ got_crypto:
>   r = ndis_get_info(sc, OID_802_11_POWER_MODE, &arg, &i);
>   if (r == 0)
>   ic->ic_caps |= IEEE80211_C_PMGT;
>  +
>  +r = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &i);
>  +if (r == 0)
>  +ic->ic_caps |= IEEE80211_C_TXPMGT;
>  +
>   bcopy(eaddr, &ic->ic_myaddr, sizeof(eaddr));
>   ieee80211_ifattach(ic);
>   ic->ic_raw_xmit = ndis_raw_xmit;
>  @@ -2325,9 +2330,10 @@ ndis_setstate_80211(sc)
>   ndis_set_info(sc, OID_802_11_POWER_MODE, &arg, &len);
>
>   /* Set TX power */
>  -if (ic->ic_txpowlimit < sizeof(dBm2mW)) {
>  -len = sizeof(arg);
>  +if ((ic->ic_caps & IEEE80211_C_TXPMGT) &&
>  +ic->ic_txpowlimit < (sizeof(dBm2mW) / sizeof(dBm2mW[0]))) {
>   arg = dBm2mW[ic->ic_txpowlimit];
>  +len = sizeof(arg);
>   ndis_set_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len);
>   }
>
>  @@ -2798,11 +2804,10 @@ ndis_getstate_80211(sc)
>   }
>
>   /* Get TX power */
>  -len = sizeof(arg);
>  -rval = ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len);
>  -
>  -if (!rval) {
>  -for (i = 0; i < sizeof(dBm2mW); i++)
>  +if (ic->ic_caps & IEEE80211_C_TXPMGT) {
>  +len = sizeof(arg);
>  +ndis_get_info(sc, OID_802_11_TX_POWER_LEVEL, &arg, &len);
>  +for (i = 0; i < (sizeof(dBm2mW) / sizeof(dBm2mW[0])); i++)
>   if (dBm2mW[i] >= arg)
>   break;
>   ic->ic_txpowlimit = i;
>  ___
>  svn-src-...@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/svn-src-all
>  To unsubscribe, send any mail to "svn-src-all-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"
>
Looks to be still open, should get closed.  I dont expect anybody is
going to MFC this and similar changes.

-- 
Paul
___
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: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device'

[Paul B. Mahol]

On 3/5/09, Erwin Hoffmann  wrote:
> Hi
>
> thanks for following my bug-report:
>
> --On Donnerstag, 5. Maerz 2009 01:43 + lini...@freebsd.org wrote:
>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130820
>
> From: "Paul B. Mahol" 
> To: lini...@freebsd.org
> Cc: freebsd-net@freebsd.org, freebsd-b...@freebsd.org
> Subject: Re: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on
> device'
>
> Yet another invalid bug report.
> OP should use -Dndis and not -Dbsd
>
> --
>
> I did not reply to the comment, because of it's obvious stupidness:
>
> If you go thru the code source for the wpasuplicant (what I did trying to
> fix the bug), you can see that (at least that's true for FreeBSD 6.3) the
> wpasupplicant *only* supports the BSD driver for wlan cards and no other.
>
> That is ok, if the documentation clearly would mention that.
>
> However, it is completely misleading (and shows the ignorance on that
> subject by Paul) even pretending FreeBSD's wpasuplicant can be used with
> the driver option.
>
> In fact, FreeBSD's wpasupplicant implementation is at best half baked.
> It turned out, that one has to consider at least two different ndis drivers:
>
> 1. The generic one, which works for unencrypted and WEP connections (using
> the chipset's internal de/encryption facilities).
> 2. A specific ndis driver different from (1.) used to talk to the wlan
> adapter while encryption and authentication is done by wpasupplicant.
>
> Since (2.) is missing, wpasupplicant tries to use the build-in BSD driver,
> which of course fails with the error message mentioned in my bug report.
>
> In order to follow up this subject, I would recommend to change the
> category of the bug into something like 'documentation bug' straighten up
> the docs and close it.
>
> I'm inclined to set up a wpa reference page with a detailed description of
> this issue and perhaps include some additional patches (wpasupplicant
> latest version for FreeBSD and others). However, currently I'm busy with
> other projects; so it is likely that this will we postponed after the
> summer term.
>
> Further, it would be great (and maybe I ask one of my students) to get the
> ndis driver working for FreeBSD. But again: This will not happen until the
> winter term.

Patches are always welcome but note that mayor development is going in
8.0 CURRENT
and there ndisulator + wpa_supplicant work for me.

wpa_supplicant on 6.3 RELEASE does support ndis driver interface, I come up
to that conclusion looking in cvs but I can not be sure because I never used
wpa_supplicant with 6.3 RELEASE

http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/wpa/wpa_supplicant/?only_with_tag=RELENG_6_3_0_RELEASE

-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

On 2/19/09, Adam K Kirchhoff  wrote:
> On Thu, 19 Feb 2009 05:50:35 -0500
> Adam K Kirchhoff  wrote:
>
>> On Wed, 18 Feb 2009 19:48:10 -0500
>> Adam K Kirchhoff  wrote:
>>
>> > On Thu, 19 Feb 2009 01:10:08 +0100
>> > "Paul B. Mahol"  wrote:
>> >
>> > > On 2/18/09, Adam K Kirchhoff  wrote:
>> > > > --- if_ndis.c  2009-01-31 00:22:11.0 -0500
>> > > > +++ if_ndis.c.orig 2009-02-18 14:03:30.0 -0500
>> > > > @@ -2459,6 +2459,11 @@
>> > > >bzero((char *)&config, len);
>> > > >config.nc_length = len;
>> > > >config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh);
>> > > > +
>> > > > +   device_printf(sc->ndis_dev, "couldn't change "
>> > > > +   "Testing config.nc_dsconfig: %u \n",
>> > > > +   config.nc_dsconfig);
>> > > > +  
>> > > >rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, 
>> > > > &len);
>> > >
>> > > printf should be bellow ndis_get_info() and above ndis_set_info().
>> >
>> > Alright, I've moved the printf down a few lines and recompiled.
>> >
>> > > Does same problem happens when not using WPA eg. wpa_supplicant?
>> >
>> > It's actually been running just fine since I got home.  I'm still using
>> > wpa_supplicant, but with WEP instead of WPA.  This has been about four
>> > hours.  Not much network traffic, but certainly more than what causes
>> > the problem at work.
>> >
>> > I'm going to let it continue to run through the night.  I have a cron
>> > job setup to transfer several 800 meg files to this laptop via scp, so
>> > it'll be interesting to see if that works over this driver.
>> >
>> > Tomorrow morning, when I get into work, I'll grab the debug output
>> > again, this time with the printf (hopefully) in the correct place.
>>
>> Looks like config.nc_dsconfig is 2462000
>>
>> The wireless connection stayed up all night, even while transferring
>> over 2 gigs of data via scp.  The problem appears to be specific to
>> this AP using WPA.  I can try WPA on my home network in about 10 hours
>> to see if the same happens there.
>
> When I switched my home network to use WPA I started to have the same
> problems as with the WPA network at work.  config.nc_dsconfig still
> reads 246200.

Enable wpa_supplicant debugging and try find something interesting.
I still cant understant why enabling debug.ndis hides problem.

-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

On 2/18/09, Adam K Kirchhoff  wrote:
> --- if_ndis.c 2009-01-31 00:22:11.0 -0500
> +++ if_ndis.c.orig2009-02-18 14:03:30.0 -0500
> @@ -2459,6 +2459,11 @@
>   bzero((char *)&config, len);
>   config.nc_length = len;
>   config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh);
> +
> +  device_printf(sc->ndis_dev, "couldn't change "
> +   "Testing config.nc_dsconfig: %u \n",
> +   config.nc_dsconfig);
> + 
>   rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len);

printf should be bellow ndis_get_info() and above ndis_set_info().

Does same problem happens when not using WPA eg. wpa_supplicant?

-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

On 2/18/09, Adam K Kirchhoff  wrote:
> On Wed, 18 Feb 2009 16:33:56 +0100
> "Paul B. Mahol"  wrote:
>
>> On 2/18/09, Adam K Kirchhoff  wrote:
>> > On Wed, 18 Feb 2009 12:06:21 +0100
>> > "Paul B. Mahol"  wrote:
>> >
>> >> On 2/17/09, Adam K Kirchhoff  wrote:
>> >> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote:
>> >> >> On 2/17/09, Adam K Kirchhoff  wrote:
>> >> >> > On Tue, 17 Feb 2009 19:22:22 +0100
>> >> >> >
>> >> >> > "Paul B. Mahol"  wrote:
>> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781
>> >> >> >>
>> >> >> >> This one should not happen, 108 rate should get recognized.
>> >> >> >> I will try to reproduce it on CURRENT.
>> >> >> >>
>> >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not
>> >> >> >> change anything but you never know.
>> >> >> >
>> >> >> > Sorry, I must have copied and pasted the uname output from the
>> >> >> > wrong
>> >> >> > machine.  This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16
>> >> >> > 16:37:18
>> >> >> > EST 2009 :-)
>> >> >>
>> >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in
>> >> >> ndis_setstate() for setting OID_802_11_CONFIGURATION.
>> >> >
>> >> > Sorry if I seem slow, but are you asking me to check something there,
>> >> > or
>> >> > just
>> >> > stating what you think the problem is? :-)
>> >>
>> >> You can add printf() before "ndis_set_info(sc,
>> >> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to
>> >> check what value for config.nc_dsconfig is by default.
>> >
>> > I'll try that shortly.
>> >
>> >> Also try changing "sysctl debug.ndis=1" and post console debug ouput
>> >> again.
>> >
>> > This was strange.  If I boot up and enable debugging before I try to
>> > run '/etc/rc.d/netif start ndis0' everything works just fine.  I get an
>> > IP address and stay connected (at least under a light load).  This is
>> > the output:
>> >
>> > ndis_newstate: INIT -> INIT
>> > ndis0: NDIS ERROR: c00013a7 (unknown error)
>> > ndis0: NDIS ERROR: c0001392 (unknown error)
>>
>> these two errors means:
>>
>> EVENT_NDIS_ADAPTER_CHECK_ERROR
>> EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER
>>
>> Looks like minport driver doesnt like your card.
>> Are you absolutly sure that you are using right miniport driver?
>
> Frankly, no.  This laptop came with a broadcom minipci card.  I
> replaced it with the intel one that I'm now using since intel network
> cards have native drivers under FreeBSD :-)  I've downloaded the latest
> drivers from the intel website
> (
> http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Inst=Yes&ProductID=1637&DwnldID=17228&strOSs=45&OSFullName=Windows*%20XP%20Home%20Edition&lang=eng
> )
> and used them to generate the driver with ndisgen.  Is there a
> recommended windows driver to use with ndis for this intel network card?
>
>> > Setting BSSID to ff:ff:ff:ff:ff:ff
>> > Setting ESSID to ""
>> > ndis0: no matching rate for: 108
>> > ndis_newstate: INIT -> RUN
>> > ndis0: link state changed to UP
>> > ndis_newstate: RUN -> INIT
>> > Setting channel to 2412000kHz
>> > ndis0: couldn't change DS config to 2412000kHz: 19
>> > Setting BSSID to ff:ff:ff:ff:ff:ff
>> > Setting ESSID to "Mckella280Front"
>> > ndis0: link state changed to DOWN
>> > ndis0: no matching rate for: 108
>> > ndis_newstate: INIT -> RUN
>> > ndis0: link state changed to UP
>> >
>> > If I then stop the network on that device, disable debug, and try to
>> > start it up again, I get the same problem as before:
>> >
>> > ndis0: couldn't change DS config to 2412000kHz: 19
>> > ndis0: link state changed to DOWN
>> > ndis0: no matching rate for: 108
>> > ndis0: link state changed to UP
>> > ndis0: couldn't change DS config to 2412000kHz: 19
>> > ndis0: link state changed to DOWN
>> > ndis0: no matching rate for: 108
>> > ndis0: link state changed to UP
>> > ndis0: link state changed to DOWN
>> >
>> > If I then stop the network, enable debugging, and start up the network,
>> > the problem persists.
>> >
>>
>> You are starting ndis0 in same way in both cases?
>
> Yes. I booted up with the ifconfig_ndis0 line commented out
> in /etc/rc.conf.  I then uncommented the line, enabled debugging, and
> started the network with '/etc/rc.d/netif start ndis0'.  I then brought
> the network down, disabled debugging, and started the network with the
> same command.  After stopping the interface, and re-enabling
> networking, I started the interface with the same command the third
> time.
>
> Adam
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

Did you copied whole ndis relevant debug output?
scan results are missing.
Are you using wpa_supplicant?

-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

On 2/18/09, Adam K Kirchhoff  wrote:
> On Wed, 18 Feb 2009 12:06:21 +0100
> "Paul B. Mahol"  wrote:
>
>> On 2/17/09, Adam K Kirchhoff  wrote:
>> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote:
>> >> On 2/17/09, Adam K Kirchhoff  wrote:
>> >> > On Tue, 17 Feb 2009 19:22:22 +0100
>> >> >
>> >> > "Paul B. Mahol"  wrote:
>> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781
>> >> >>
>> >> >> This one should not happen, 108 rate should get recognized.
>> >> >> I will try to reproduce it on CURRENT.
>> >> >>
>> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not
>> >> >> change anything but you never know.
>> >> >
>> >> > Sorry, I must have copied and pasted the uname output from the wrong
>> >> > machine.  This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18
>> >> > EST 2009 :-)
>> >>
>> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in
>> >> ndis_setstate() for setting OID_802_11_CONFIGURATION.
>> >
>> > Sorry if I seem slow, but are you asking me to check something there, or
>> > just
>> > stating what you think the problem is? :-)
>>
>> You can add printf() before "ndis_set_info(sc,
>> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to
>> check what value for config.nc_dsconfig is by default.
>
> I'll try that shortly.
>
>> Also try changing "sysctl debug.ndis=1" and post console debug ouput
>> again.
>
> This was strange.  If I boot up and enable debugging before I try to
> run '/etc/rc.d/netif start ndis0' everything works just fine.  I get an
> IP address and stay connected (at least under a light load).  This is
> the output:
>
> ndis_newstate: INIT -> INIT
> ndis0: NDIS ERROR: c00013a7 (unknown error)
> ndis0: NDIS ERROR: c0001392 (unknown error)

these two errors means:

EVENT_NDIS_ADAPTER_CHECK_ERROR
EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER

Looks like minport driver doesnt like your card.
Are you absolutly sure that you are using right miniport driver?

> Setting BSSID to ff:ff:ff:ff:ff:ff
> Setting ESSID to ""
> ndis0: no matching rate for: 108
> ndis_newstate: INIT -> RUN
> ndis0: link state changed to UP
> ndis_newstate: RUN -> INIT
> Setting channel to 2412000kHz
> ndis0: couldn't change DS config to 2412000kHz: 19
> Setting BSSID to ff:ff:ff:ff:ff:ff
> Setting ESSID to "Mckella280Front"
> ndis0: link state changed to DOWN
> ndis0: no matching rate for: 108
> ndis_newstate: INIT -> RUN
> ndis0: link state changed to UP
>
> If I then stop the network on that device, disable debug, and try to
> start it up again, I get the same problem as before:
>
> ndis0: couldn't change DS config to 2412000kHz: 19
> ndis0: link state changed to DOWN
> ndis0: no matching rate for: 108
> ndis0: link state changed to UP
> ndis0: couldn't change DS config to 2412000kHz: 19
> ndis0: link state changed to DOWN
> ndis0: no matching rate for: 108
> ndis0: link state changed to UP
> ndis0: link state changed to DOWN
>
> If I then stop the network, enable debugging, and start up the network,
> the problem persists.
>

You are starting ndis0 in same way in both cases?

-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

On 2/17/09, Adam K Kirchhoff  wrote:
> On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote:
>> On 2/17/09, Adam K Kirchhoff  wrote:
>> > On Tue, 17 Feb 2009 19:22:22 +0100
>> >
>> > "Paul B. Mahol"  wrote:
>> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781
>> >>
>> >> This one should not happen, 108 rate should get recognized.
>> >> I will try to reproduce it on CURRENT.
>> >>
>> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not
>> >> change anything but you never know.
>> >
>> > Sorry, I must have copied and pasted the uname output from the wrong
>> > machine.  This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18
>> > EST 2009 :-)
>>
>> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in
>> ndis_setstate() for setting OID_802_11_CONFIGURATION.
>
> Sorry if I seem slow, but are you asking me to check something there, or
> just
> stating what you think the problem is? :-)

You can add printf() before "ndis_set_info(sc,
OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to
check what value for config.nc_dsconfig is by default.

Also try changing "sysctl debug.ndis=1" and post console debug ouput again.

>
>> > Could the fact that the rate is 108 also be causing problems for the
>> > native iwi driver?
>>
>> Unlikely, bug is in ndisulator initialization code.
>
> Oh well :-)  I'll take what I can get at this point.
>
> Adam
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>


-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

On 2/17/09, Adam K Kirchhoff  wrote:
> On Tue, 17 Feb 2009 19:22:22 +0100
> "Paul B. Mahol"  wrote:
>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781
>>
>> This one should not happen, 108 rate should get recognized.
>> I will try to reproduce it on CURRENT.
>>
>> To OP, could you try 7 STABLE after 31 Jan? I guess it should not
>> change anything but you never know.
>
> Sorry, I must have copied and pasted the uname output from the wrong
> machine.  This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18
> EST 2009 :-)

miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in
ndis_setstate() for setting OID_802_11_CONFIGURATION.

> Could the fact that the rate is 108 also be causing problems for the
> native iwi driver?

Unlikely, bug is in ndisulator initialization code.

-- 
Paul
___
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: kern/131781: [ndis] ndis keeps dropping the link

[Paul B. Mahol]

http://www.freebsd.org/cgi/query-pr.cgi?pr=131781

This one should not happen, 108 rate should get recognized.
I will try to reproduce it on CURRENT.

To OP, could you try 7 STABLE after 31 Jan? I guess it should not
change anything but you never know.

-- 
Paul
___
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: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device'

[Paul B. Mahol]

On 2/5/09, Erwin Hoffmann  wrote:
> Hi Paul,
>
>
> --On 5. Februar 2009 18:56:06 +0100 "Paul B. Mahol" 
> wrote:
>
>> On 2/5/09, Erwin Hoffmann  wrote:
>>> Hi,
>>>
>>> I just saw Paul Mahol's comment:
>>>
>>>> Yet another invalid bug report.
>>>> OP should use -Dndis and not -Dbsd
>>>>
>>>> --
>>>> Paul
>>>
>>> Well. If things would be sooo easy.
>>> Trying to declare "-D ndis" in the wpa_supplicant call as additional
>>> argument yields:
>>>
>>> artemis# pwd
>>> /etc/rc.d
>>> artemis# ./wpa_supplicant start ndis0
>>> Starting wpa_supplicant.
>>> Unsupported driver 'ndis'.
>>>
>>> This is my kernel setup:
>>>
>>> artemis# kldstat -v | grep wlan
>>> 300 wlan_ccmp
>>> 301 wlan_tkip
>>> 302 wlan_wep
>>> 303 wlan
>>>
>>> artemis# kldstat -v | grep ndis
>>>  53 0xc0c73000 17734ndis.ko
>>>  3 ndisapi
>>>  62 0xc0c8b000 caa4 if_ndis.ko
>>>  4 cardbus/ndis
>>>  5 pci/ndis
>>>  6 pccard/ndis
>>>  7 uhub/ndis
>>>
>>> What am I missing ?
>>>
>>
>> wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it
>> should work too)
>>
>> Your is not configured with support for ndis. Please read carefully
>> wpa_supplicant configuration options.
>
> It would help me (and everybody) if you could shed a little light on that
> subject.
>
> Apart from patching wpa_supplicant 0.3.11 and the most current to work
> under FreeBSD, I'm probably missing an import piece of information. Neither
> the man pages nor the current FreeBSD docs indicate (at least for me) the
> necessary adjustments.


wpa_supplicant is contributed software located in
/usr/src/contrib/wpa_supplicant/

Makefiles to build wpa_supplicat for FreeBSD are in
/usr/src/usr.sbin/wpa/wpa_supplicant/

-- 
Paul
___
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: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device'

[Paul B. Mahol]

On 2/5/09, Erwin Hoffmann  wrote:
> Hi,
>
> I just saw Paul Mahol's comment:
>
>>Yet another invalid bug report.
>>OP should use -Dndis and not -Dbsd
>>
>>--
>>Paul
>
> Well. If things would be sooo easy.
> Trying to declare "-D ndis" in the wpa_supplicant call as additional
> argument yields:
>
> artemis# pwd
> /etc/rc.d
> artemis# ./wpa_supplicant start ndis0
> Starting wpa_supplicant.
> Unsupported driver 'ndis'.
>
> This is my kernel setup:
>
> artemis# kldstat -v | grep wlan
> 300 wlan_ccmp
> 301 wlan_tkip
> 302 wlan_wep
> 303 wlan
>
> artemis# kldstat -v | grep ndis
>  53 0xc0c73000 17734ndis.ko
>  3 ndisapi
>  62 0xc0c8b000 caa4 if_ndis.ko
>  4 cardbus/ndis
>  5 pci/ndis
>  6 pccard/ndis
>  7 uhub/ndis
>
> What am I missing ?
>
> regards.
> --eh.
>
>
>
> ---
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
>
> ___
> 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"
>

wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it
should work too)

Your is not configured with support for ndis. Please read carefully
wpa_supplicant configuration options.

-- 
Paul
___
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: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device'

[Paul B. Mahol]

On 1/21/09, lini...@freebsd.org  wrote:
> Old Synopsis: wpa_supplicant returns 'no space on device'
> New Synopsis: [ndis] wpa_supplicant(8) returns 'no space on device'
>
> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
> Responsible-Changed-By: linimon
> Responsible-Changed-When: Wed Jan 21 18:29:51 UTC 2009
> Responsible-Changed-Why:
> Over to maintainer(s).
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=130820
> ___
> 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"
>

Yet another invalid bug report.
OP should use -Dndis and not -Dbsd

-- 
Paul
___
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: VLAN interface management - unloading carrying driver hangs the machine

[Paul B. Mahol]

On 1/8/09, Jack Vogel  wrote:
> Fine with me, go do it and I'll take the driver code out :)
>
> Jack
>
>
> On Thu, Jan 8, 2009 at 12:18 AM, Yony Yossef
> wrote:
>
>> > Jack Vogel wrote:
>> > >
>> > >
>> > > On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler > > > > wrote:
>> > >
>> > > Yony Yossef wrote:
>> > >
>> > > Yony Yossef wrote:
>> > >
>> > >
>> > > /sbin/ifconfig vlan3653 create
>> > >
>> > > Problem is when I assign an IP to the vlan
>> > interface.
>> > > In that case, unloading the driver results
>> > in hanging
>> > > the host.
>> > >  Does it sound familiar to anybody?
>> > >
>> > >
>> > > Well, surely I'd expect problems by doing so.
>> > > The correct way is to
>> > >
>> > >/sbin/ifconfig vlan3653 destroy
>> > >
>> > > before unloading the driver.
>> > >
>> > > Angelo.
>> > >
>> > >
>> > >
>> > > Thanks, I didn't know freebsd does not allow it.
>> > >
>> > >
>> > >
>> > > This seems wrong. Someone should disallow the driver
>> > > detach/unload. Please file a PR about this so the issue
>> > is not lost.
>> > >
>> > > Sam
>> > >
>> > >
>> > > In many drivers, ahem, like mine, there is a test at detach and it
>> > > will not allow it if there is a non-NULL trunk.
>> > >
>> > > Sounds like a broken driver needs to be fixed is all...
>> > >
>> > I don't agree; drivers should not be required to deal with
>> > this.  If someone files a PR and assigns it to me I'll look at it.
>> >
>> > Sam
>> >
>>
>> I agree with Sam. There's no reason to leave this check to the driver.
>>
>> Yony
>>
>>
> ___
> 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"
>

What's the state of this issue?
It is fixed or not?

-- 
Paul
___
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: kern/91859: [ndis] if_ndis does not work with Asus WL-138

[Paul B. Mahol]

If I'm not mistaken this report is bogus.
Correct way to make ndis miniport module
is via ndisgen which is shell script for
ndiscvt.

Report is bogus because OP did not kldload
module which have been created with ndiscvt:

kldload ndis
kldload if_ndis
kldload ./created_module_sys.ko

-- 
Paul
___
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: crash in dummynet

[Paul B. Mahol]

On 12/12/08, Vyacheslav Bocharov  wrote:
> I have frequent panics in dummynet module:
>
> Dec 12 08:27:58 chip syslogd: restart
> Dec 12 08:27:58 chip syslogd: kernel boot file is /boot/kernel/kernel
> Dec 12 08:27:58 chip kernel:
> Dec 12 08:27:58 chip kernel:
> Dec 12 08:27:58 chip kernel: Fatal trap 12: page fault while in kernel mode
> Dec 12 08:27:58 chip kernel: cpuid = 1; apic id = 01
> Dec 12 08:27:58 chip kernel: fault virtual address  = 0x10
> Dec 12 08:27:58 chip kernel: fault code = supervisor read, page not
> present
> Dec 12 08:27:58 chip kernel: instruction pointer= 0x20:0xc06af1fd
> Dec 12 08:27:58 chip kernel: stack pointer  = 0x28:0xe8733bd4
> Dec 12 08:27:58 chip kernel: frame pointer  = 0x28:0xe8733c18
> Dec 12 08:27:58 chip kernel: code segment   = base 0x0, limit
> 0xf, type 0x1b
> Dec 12 08:27:58 chip kernel: = DPL 0, pres 1, def32 1, gran 1
> Dec 12 08:27:58 chip kernel: processor eflags   = interrupt enabled, resume,
> IOPL = 0
> Dec 12 08:27:58 chip kernel: current process= 48 (dummynet)
> Dec 12 08:27:58 chip kernel: trap number= 12
> Dec 12 08:27:58 chip kernel: panic: page fault
> Dec 12 08:27:58 chip kernel: cpuid = 1
> Dec 12 08:27:58 chip kernel: Uptime: 16h42m29s
> Dec 12 08:27:58 chip kernel: Physical memory: 3572 MB
> Dec 12 08:27:58 chip kernel: Dumping 227 MB:

backtrace?

-- 
Paul
___
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: driver support for Belkin F5D7050 v 5xxx ?

[Paul B. Mahol]

On 11/16/08, Kayven Riese <[EMAIL PROTECTED]> wrote:
> I just purchased a wireless connection device that connects to my ASUS
> M6800N laptop dual
> booting Vista and
>
> KV_BSD# uname -a
> FreeBSD KV_BSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC
> 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
> KV_BSD#
>
> via USB.
>
> While booting on Vista, connection was fine.  I investigated my man pages
> for Belkin modles in
> the interfaces:
> V_BSD# man an | grep Belkin
> KV_BSD# man awi | grep Belkin
> KV_BSD# man ipw | grep Belkin
> KV_BSD# set -o vi
> KV_BSD# man iwi | grep Belkin
> KV_BSD# man ral | grep Belkin
>  Belkin F5D7000 v3RT2560 PCI
>  Belkin F5D7010 v2RT2560 CardBus
> KV_BSD# man rum | grep Belkin
>  Belkin F5D7050 ver 3 USB
>  Belkin F5D9050 ver 3 USB
> KV_BSD# man ural | grep Belkin
>  Belkin F5D7050 v2000 USB
> KV_BSD# man wi | grep Belkin
>  Belkin F5D6000 (a rebadged WL11000P)
> KV_BSD# man zyd | grep Belkin
>Belkin F5D7050 v.4000
> KV_BSD#
>
> and found some websites that made me compare a serial number that I
> correlated to some
> information on the Belkin website and came to the conclusion that my device
> is a newer
> version than appears in the above list because of this information:
>
> K7SF5D7050E corresponds to version 5xxx
>
> That serial number is written on the device.
>
> There were no unfamiliar results of ifconfig:
>
>
>
> KV_BSD# ifconfig
> bge0: flags=8843 metric 0 mtu 1500
> options=9b
> ether 00:11:d8:22:c9:91
> inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255
> media: Ethernet autoselect (100baseTX )
> status: active
> fwe0: flags=8802 metric 0 mtu 1500
> options=8
> ether 02:e0:18:26:4c:e9
> ch 1 dma -1
> fwip0: flags=8802 metric 0 mtu 1500
> lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0
> plip0: flags=108810 metric 0 mtu
> 1500
> lo0: flags=8049 metric 0 mtu 16384
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff00
> KV_BSD#
>
> I attempted to use the ndisgen utility with the driver disk mounted on
> "/mnt/drive"
>

Currently ndis on freebsd doesnt support usb cards at all.
There is patch available for CURRENT that is considered experimental and
make possible to use ndis on FreeBSD with usb cards.

> KV_BSD# pwd
> /mnt/drive
> KV_BSD# ls
> AUTORUN.INFBelkin.icoInstaller.exeUserManual
> Acrobat ReaderInstallationFilesInstaller.ini
> KV_BSD# cd InstallationFiles
> KV_BSD# ls
> Belkin.bmpSetup.exeVistaX64WinXP2Kdata1.hdr
> layout.bin
> ISSetup.dllSetup.iniVistaX86_Setup.dlldata2.cab
> SETUP.ISSSetup.inxWinX64data1.cabikernel.ex_
> KV_BSD# ls WinXP2K
> BLKWGU.infBLKWGU.sysblkwgu.cat
>
> twice, once using the BLKWGU.inf and BLKWGU.sys files from the WinXP2K
> directory and again
> adding the blkwgu.cat file using the menu that ndisgen gives, and both times
> it terminated
> with success:
>
>==
> -- Windows(r) driver converter ---
> ==
>
> Kernel module generation
>
>
> The script will now try to generate the kernel driver module.
> This is the last step. Once this module is generated, you should
> be able to load it just like any other FreeBSD driver module.
>
> Press enter to compile the stub module and generate the driver
> module now:
>
> Generating Makefile... done.
> Building kernel module... done.
> Cleaning up... done.
>
> The file BLKWGU_sys.ko has been successfully generated.
> You can kldload this module to get started.
>
> Press return to exit.
>
> When I tried to use the kldload command in both cases, the system rebooted.
>
> I messed around with /boot/loader.conf, including many of the interfaces
> that were
> noted above "man if | grep Belkin," and right now this is what it looks
> like:
> KV_BSD# cat /boot/loader.conf
> hint.ichss.0.disabled="1"
> W32DRIVER_load="YES"
> wlan_load="YES"
> firmware_load="YES"
> if_zyd_load="YES"
> wlan_scan_ap_load="YES"
> wlan_scan_sta_load="YES"
> wlan_wep_load="YES"
> wlan_ccmp_load="YES"
> wlan_tkip_load="YES"
>
> I note that the device is showing up in dmesg
>
> KV_BSD# dmesg | grep Belkin
> ugen0:  2.00/2.00, addr 2> on uhub3
> ugen0:  2.00/2.00, addr 2> on uhub3
> ugen0:  2.00/2.00, addr 2> on uhub3
> ugen0:  2.00/2.00, addr 2> on uhub3
> KV_BSD#
>
>
> some other info..
>
>
> KV_BSD# pciconf -lv
> [EMAIL PROTECTED]:0:0:0:  class=0x06 card=0x186a1043 chip=0x33408086
> rev=0x21 hdr=0x00
> vendor = 'Intel Cor
>  .
>
> 

Re: Backporting iwn(4): WPA auth hangs... Help!

[Paul B. Mahol]

On 9/21/08, Gavin Atkinson <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I'm attempting to backport the iwn(4) driver for the Intel 4965 driver
> from -HEAD to RELENG_7 and am getting stuck with it at one particular
> point: WPA authentication times out.
>
> I've so far tried to both take the -HEAD driver and de-vapify etc. it, and
> also to take a pre-vap version of the driver and bring in required
> changes.  Both fail in exactly the same way, with authentication timing
> out.  I have verified that the laptop can successfully connect to the same
> network with -HEAD and the same wpa_supplicant.conf file.  I've attached
> the log file from wpa_supplicant.  Code can be found at
> http://people.freebsd.org/~gavin/iwn/ - I'm currently working with the
> updated-from-pre-vap version so that's the one that generated the log file
> and is probably the best to look at.
>
> Sadly I don't have the infrastructure at the moment to test if the
> driver works with WEP.
>
> Any help or pointers would be greatfully received,
>
> Thanks!
>
> Gavin

I can't understand why is IEEE80211_C_STA removed in both versions.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics

[Paul B. Mahol]

The following reply was made to PR kern/125181; it has been noted by GNATS.

From: "Paul B. Mahol" <[EMAIL PROTECTED]>
To: "Andrew Thompson" <[EMAIL PROTECTED]>
Cc: "Coleman Kane" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, 
panics
Date: Mon, 1 Sep 2008 09:57:42 +0200

 On 7/17/08, Andrew Thompson <[EMAIL PROTECTED]> wrote:
 > On Thu, Jul 17, 2008 at 12:09:52PM -0400, Coleman Kane wrote:
 >> Andrew,
 >>
 >> I got directed to this PR by [EMAIL PROTECTED] (Paul D. Mahol), who's
 >> been helping me track down some edge cases in the if_ndis locking
 >> rewrite. I am not 100% familiar with the locking semantics in play here
 >> (IEEE80211 and VAPs), so I wanted to run it by you before I determine
 >> that it seems to be working well for me.
 >
 > I dont think ndis should be reaching into the net80211 lock. Now that
 > ndis uses a regular mutex its a good chance to add mtx_asserts in the
 > right places and get the locking up to speed. I will try to post a patch
 > soon unless someone beats be to it.
 >
 > Andrew
 >
 
 I got hit by this bug again, my only option is to switch to UP kernel
 until patch for this bug is finally committed.
 
 
 Subject of bug report is no more relevant, becuase this bug has
 nothing directly related with WEP.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics

[Paul B. Mahol]

On 7/17/08, Andrew Thompson <[EMAIL PROTECTED]> wrote:
> The following reply was made to PR kern/125181; it has been noted by GNATS.
>
> From: Andrew Thompson <[EMAIL PROTECTED]>
> To: Coleman Kane <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown,
>   panics
> Date: Thu, 17 Jul 2008 09:43:42 -0700
>
>  On Thu, Jul 17, 2008 at 12:09:52PM -0400, Coleman Kane wrote:
>  > Andrew,
>  >
>  > I got directed to this PR by [EMAIL PROTECTED] (Paul D. Mahol), who's
>  > been helping me track down some edge cases in the if_ndis locking
>  > rewrite. I am not 100% familiar with the locking semantics in play here
>  > (IEEE80211 and VAPs), so I wanted to run it by you before I determine
>  > that it seems to be working well for me.
>
>  I dont think ndis should be reaching into the net80211 lock. Now that
>  ndis uses a regular mutex its a good chance to add mtx_asserts in the
>  right places and get the locking up to speed. I will try to post a patch
>  soon unless someone beats be to it.

Patch impact on performance is marginal if not completely irrelevant.
The only way to improve code in that file is rewritting offending functions.
And at end net80211 lock would be still there (called via some other function).
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"