Re: [PATCH] ndis: safe fpu on amd64
On 11/22/11, Kostik Belousov kostik...@gmail.com wrote: On Mon, Nov 21, 2011 at 03:49:16PM +, 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
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 machine/segments.h
#endif
+#ifdef __amd64__
+#include machine/fpu.h
+#endif
#include dev/usb/usb.h
@@ -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
On Wed, Jan 6, 2010 at 1:04 PM, ga...@freebsd.org 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
On Fri, Feb 18, 2011 at 11:26 PM, grarpamp grarp...@gmail.com 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
On Fri, Feb 18, 2011 at 9:54 PM, grarpamp grarp...@gmail.com 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
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
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
On 10/20/10, Bernhard Schmidt bschm...@freebsd.org wrote:
9, 2010 at 23:53, Paul B Mahol one...@gmail.com 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
Re: if_ndis: fix for panic with VIMAGE
On 10/13/10, Paul B Mahol one...@gmail.com wrote: On 10/12/10, Paul B Mahol one...@gmail.com wrote: On 10/11/10, Paul B Mahol one...@gmail.com 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
ndis: patch for review
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
On 10/12/10, Paul B Mahol one...@gmail.com wrote: On 10/11/10, Paul B Mahol one...@gmail.com 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
On 10/11/10, Paul B Mahol one...@gmail.com 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
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: Monitor mode not working for iwi(4) on 7.X
On 10/9/10, Alexey Dokuchaev da...@freebsd.org wrote: On Fri, Oct 08, 2010 at 06:07:31PM +, Paul B Mahol wrote: Just to clear this up, iwi(4) can not support injection (see iwi_raw_xmit()) unless you manage to hack firmware ... Can you perhaps comment on this thread: http://ubuntuforums.org/showthread.php?t=242556 At a glance it looks like guys use dummy interface for packet injection, and I don't see they patch firmware in any way. If it's not a hoax, I wonder if similar techniques can be used under FreeBSD. That patch allows only data injection so it is near to useless. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: VIMAGE + NDIS
On 10/9/10, Nikos Vassiliadis nvass9...@gmx.com wrote:
Paul B Mahol wrote:
On 9/27/10, Julian Elischer jul...@freebsd.org wrote:
anyone here have NDIS experience?
On 9/27/10 10:51 AM, Nikos Vassiliadis wrote:
Julian Elischer wrote:
#10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at
/usr/src/sys/net/rtsock.c:1374
1374if (V_loif)
(kgdb) list
1369}
1370*(unsigned short *)(tag + 1) = sa-sa_family;
1371m_tag_prepend(m, tag);
1372}
1373#ifdef VIMAGE
1374if (V_loif)
1375m-m_pkthdr.rcvif = V_loif;
1376else {
1377m_freem(m);
1378return;
(kgdb)
ok so probably there is a code-path to this point that does not first
set up the current-vnet pointer before doing this.
what you need to do is to produce a stack-trace so we can see how
it got here,
and then we can figure out where on that path we should set the
pointer.
Here it is:
(kgdb) #0 doadump () at pcpu.h:231
#1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808,
dummy4=0xeef1d720 ) at /usr/src/sys/ddb/db_command.c:548
#2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0,
dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#3 0xc04d4e0a in db_command_loop () at
/usr/src/sys/ddb/db_command.c:498
#4 0xc04d6d0d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948)
at /usr/src/sys/kern/subr_kdb.c:535
#6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24)
at /usr/src/sys/i386/i386/trap.c:929
#7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24)
at /usr/src/sys/i386/i386/trap.c:851
#8 0xc0c0bad5 in trap (frame=0xeef1d948) at
/usr/src/sys/i386/i386/trap.c:533
#9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0)
at /usr/src/sys/net/rtsock.c:1374
#11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at
/usr/src/sys/net/rtsock.c:1168
#12 0xc76704a1 in ?? ()
#13 0xc6c3d400 in ?? ()
#14 0xeef1daa8 in ?? ()
#15 0xeef1daf4 in ?? ()
#16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200)
at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105
#17 0xc766d8a1 in ?? ()
#18 0xc76b9200 in ?? ()
#19 0xc76c in ?? ()
#20 0xc76f1000 in ?? ()
#21 0xeef1dacc in ?? ()
#22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#23 0x006c in ?? ()
#24 0xeef1dbb4 in ?? ()
#25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#26 0xc76c in ?? ()
#27 0xc76c in ?? ()
#28 0xc7340800 in ?? ()
#29 0xc086adcc in hardclock_cpu (usermode=7077888)
at /usr/src/sys/kern/kern_clock.c:447
whoa!
hardclock interrupted itself?
#30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#31 0x006c in ?? ()
#32 0xeef1dbb4 in ?? ()
#33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start ()
from /boot/modules/bcmwl5_sys.ko
#34 0xc76c in ?? ()
#35 0xc76c in ?? ()
#36 0xc7340800 in ?? ()
hmmm maybe we need to get ndis to put in a wrapper at this point that
is called form hardclock and sets the value before going further
I'd have to look at the code to see what happens here..
*wonders who has their fingers in this code*..
#37 0xc086adcc in hardclock_cpu (usermode=-949223424)
at /usr/src/sys/kern/kern_clock.c:447
Previous frame inner to this frame (corrupt stack?)
(kgdb)
and the panic, in case it helps:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x18
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0978200
stack pointer = 0x28:0xeef1d988
frame pointer = 0x28:0xeef1d9a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1404 (Windows Workitem 3)
panic: from debugger
cpuid = 1
KDB: stack backtrace:
Physical memory: 2916 MB
Dumping 113 MB: 98 82 66 50 34 18 2
Thanks, Nikos
Please give more background information of this case.
Personally I never tested VIMAGE.
Sorry for the delayed response,
It is easily producible. Build a kernel with VIMAGE, associate
with an AP, run dhclient and then change the SSID to something
random.
If there is something I can do to help you debug this problem,
please don't hesitate to ask.
First remove rt_ifmsg() call from if_ndis.c rebuild load if_ndis
module and tell me if it still happens.
___
freebsd-net@freebsd.org mailing list
http
Re: Monitor mode not working for iwi(4) on 7.X
On 10/8/10, Alexey Dokuchaev da...@freebsd.org wrote: On Thu, Oct 07, 2010 at 12:44:20PM +, Paul B Mahol wrote: On 10/7/10, Adrian Chadd adr...@freebsd.org 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
On 10/8/10, Alexey Dokuchaev da...@freebsd.org wrote: On Fri, Oct 08, 2010 at 11:48:57AM +, Paul B Mahol wrote: On 10/8/10, Alexey Dokuchaev da...@freebsd.org 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=25818300IBSS,PMGT,SHPREAMBLE,MONITOR,WPA1,WPA2,WME,BGSCAN 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
On 10/8/10, Alexey Dokuchaev da...@freebsd.org 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
On 10/8/10, Alexey Dokuchaev da...@freebsd.org wrote: On Fri, Oct 08, 2010 at 03:20:08PM +, Paul B Mahol wrote: On 10/8/10, Alexey Dokuchaev da...@freebsd.org 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
On 10/7/10, Alexey Dokuchaev da...@freebsd.org wrote: On Wed, Oct 06, 2010 at 11:56:25AM -0500, Brandon Gooch wrote: 2010/10/6 Alexey Dokuchaev da...@freebsd.org: 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
On 10/7/10, Adrian Chadd adr...@freebsd.org 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
ndis: fix ugly code
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: ndis: fix ugly code
On 10/6/10, Julian Elischer jul...@freebsd.org wrote: On 10/5/10 5:27 PM, Paul B Mahol wrote: On 10/5/10, Julian Elischerjul...@freebsd.org 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: Re: VIMAGE + NDIS
On 9/27/10, Julian Elischer jul...@freebsd.org 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/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re: convert Windows NDIS drivers for use with FreeBSD
On 5/14/10, jiani1012 jiani1...@126.com 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
On 5/7/10, jiani1012 jiani1...@126.com 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
On 1/16/10, Paul B Mahol one...@gmail.com wrote: On 1/11/10, Paul B Mahol one...@gmail.com wrote: On 1/11/10, Bob Johnson fbsdli...@gmail.com wrote: On 1/9/10, Paul B Mahol one...@gmail.com wrote: On 12/16/09, Bob Johnson fbsdli...@gmail.com 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
The following reply was made to PR kern/142197; it has been noted by GNATS. From: Paul B Mahol one...@gmail.com To: Roman Bogorodskiy no...@freebsd.org 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 no...@freebsd.org 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
On 12/31/09, Paul B Mahol one...@gmail.com 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
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: 8.0R, AMD64 and wpi is giving me major grief
On 12/17/09, Kurt Buff kurt.b...@gmail.com 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 kurt.b...@gmail.com 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: Intel i965GM 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: ap_scan values
On 12/20/09, Steven Friedrich free...@insightbb.com 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
patch: ndisusb: show device description on attach
--- /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: kern/141376: [ndis] [patch] broken scan by passing ies and ies_len pointer to net80211
On 12/11/09, lini...@freebsd.org 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
Re: ndis: broken scan
On 12/7/09, Paul B Mahol one...@gmail.com 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
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: if_ndis patch
On 10/31/09, Coleman Kane cok...@freebsd.org 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
On 10/7/09, Boris Kochergin sp...@acm.poly.edu 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
On 9/28/09, Matthias Apitz g...@unixarea.de 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
On 7/15/09, Paul B. Mahol one...@gmail.com wrote:
On 7/4/09, Paul B. Mahol one...@gmail.com wrote:
On 6/18/09, Coleman Kane cok...@freebsd.org 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
On 7/4/09, Paul B. Mahol one...@gmail.com wrote:
On 6/18/09, Coleman Kane cok...@freebsd.org 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?
On 7/10/09, ** realliu...@gmail.com 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
On 6/27/09, Nikos Vassiliadis nvass9...@gmx.com 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: BayNETGEAR 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=8803UP,BROADCAST,SIMPLEX,MULTICAST 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST 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
On 6/18/09, Vladimir Terziev vladim...@partygaming.com 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
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
On 6/9/09, Vladimir Terziev vladim...@partygaming.com 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
On 6/9/09, Vladimir Terziev vladim...@partygaming.com 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: Problem/freezes with if_bwi and firmware
On 5/11/09, Gustau Perez gpe...@entel.upc.edu 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
On 5/26/09, Adam K Kirchhoff ad...@voicenet.com 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=131153cat= ). 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
On 5/3/09, Gustau Perez gpe...@entel.upc.edu 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: Signal sensitivity problem with if_rum
On 5/2/09, Gustau Perez gpe...@entel.upc.edu 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: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics
On 7/13/08, ga...@freebsd.org 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
On 5/1/09, Gustau Perez gpe...@entel.upc.edu 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+linuxcd=1hl=cact=clnkgl=esclient=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: Signal sensitivity problem with if_rum
On 5/1/09, Gustau Perez gpe...@entel.upc.edu 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: NDIS - True OR False
On 3/25/09, Chris Ruiz ch...@young-alumni.com 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
On 3/21/09, lini...@freebsd.org 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/130820: [ndis] wpa_supplicant(8) returns 'no space on device'
On 3/5/09, Erwin Hoffmann f...@fehcom.de 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 one...@gmail.com 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
On 2/19/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Thu, 19 Feb 2009 05:50:35 -0500 Adam K Kirchhoff ad...@voicenet.com wrote: On Wed, 18 Feb 2009 19:48:10 -0500 Adam K Kirchhoff ad...@voicenet.com wrote: On Thu, 19 Feb 2009 01:10:08 +0100 Paul B. Mahol one...@gmail.com wrote: On 2/18/09, Adam K Kirchhoff ad...@voicenet.com 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
On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tue, 17 Feb 2009 19:22:22 +0100 Paul B. Mahol one...@gmail.com 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
On 2/18/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Wed, 18 Feb 2009 12:06:21 +0100 Paul B. Mahol one...@gmail.com wrote: On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tue, 17 Feb 2009 19:22:22 +0100 Paul B. Mahol one...@gmail.com 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
On 2/18/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Wed, 18 Feb 2009 16:33:56 +0100 Paul B. Mahol one...@gmail.com wrote: On 2/18/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Wed, 18 Feb 2009 12:06:21 +0100 Paul B. Mahol one...@gmail.com wrote: On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tue, 17 Feb 2009 19:22:22 +0100 Paul B. Mahol one...@gmail.com 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=YInst=YesProductID=1637DwnldID=17228strOSs=45OSFullName=Windows*%20XP%20Home%20Editionlang=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
On 2/18/09, Adam K Kirchhoff ad...@voicenet.com 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
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/131781: [ndis] ndis keeps dropping the link
On 2/17/09, Adam K Kirchhoff ad...@voicenet.com wrote: On Tue, 17 Feb 2009 19:22:22 +0100 Paul B. Mahol one...@gmail.com 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/130820: [ndis] wpa_supplicant(8) returns 'no space on device'
On 2/5/09, Erwin Hoffmann f...@fehcom.de 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'
On 2/5/09, Erwin Hoffmann f...@fehcom.de wrote: Hi Paul, --On 5. Februar 2009 18:56:06 +0100 Paul B. Mahol one...@gmail.com wrote: On 2/5/09, Erwin Hoffmann f...@fehcom.de 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: VLAN interface management - unloading carrying driver hangs the machine
On 1/8/09, Jack Vogel jfvo...@gmail.com 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 yonyossef.li...@gmail.comwrote: Jack Vogel wrote: On Wed, Jan 7, 2009 at 9:54 AM, Sam Leffler s...@freebsd.org mailto:s...@freebsd.org 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/130820: [ndis] wpa_supplicant(8) returns 'no space on device'
On 1/21/09, lini...@freebsd.org 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: kern/91859: [ndis] if_ndis does not work with Asus WL-138
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: Backporting iwn(4): WPA auth hangs... Help!
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
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
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]
