Re: urtwn and hostap

2015-09-25 Thread Andriy Voskoboinyk

I tried to look for beacon frames using tcpdump on another urtwn adapter
but unfortunately it doesn't appear to be working. I see a "need
promiscuous mode update callback" printed out on the console every time
I try. I assume that's indicative of a problem. Is there something else
I should try besides running the second adapter in monitor mode and then
running tcpdump on the interface? I did see these when running tcpdump
on the wlan0 hostap adapter itself ...


I have tested this patch with RTL8188EU in hostap mode
(and with WUSB54GC in monitor mode) - and have not seen beacons from it  
too.




The station wasn't able to associate with both bits stripped. It did
work with the bssid data bit stripped, so the new patch reflects that.
I'm not sure what the most appropriate comment update should be there so
I left it as is.



Sorry for misunderstanding - I have mean BCN flag ('receive beacon  
frames'),

not DATA flag ('receive data frames').



Latest patch is attached.

-Matthew

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-23 Thread Matthew Grooms

On 9/21/2015 9:06 AM, Matthew Grooms wrote:

On 9/21/2015 7:19 AM, Andriy Voskoboinyk wrote:



This patch doesn't manually generate a beacon frame using
ieee80211_beacon_alloc so I assume that setting the MSR register using
the appropriate value instructs the chip to handle that in hardware. I
tested this on both my ESXi VM using USB passthru and my raspberry 
pi 2.
Both appear to work as expected but the connection seemed less 
stable on

the latter.


Can you check this with tcpdump(1) or dumpcap(1) on the sta side?
(I have seen configurations, where STA's were associated with an AP
without beaconing).



I'll give that a try and report back.



I tried to look for beacon frames using tcpdump on another urtwn adapter 
but unfortunately it doesn't appear to be working. I see a "need 
promiscuous mode update callback" printed out on the console every time 
I try. I assume that's indicative of a problem. Is there something else 
I should try besides running the second adapter in monitor mode and then 
running tcpdump on the interface? I did see these when running tcpdump 
on the wlan0 hostap adapter itself ...


21:32:57.340541 8c:3a:e3:43:9a:b8 > ff:ff:ff:ff:ff:ff, 802.3, length 20: 
LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x81f5: 
Supervisory, Receiver not Ready, rcv seq 64, Flags [Poll], length 6
21:32:57.340558 8c:3a:e3:43:9a:b8 > ff:ff:ff:ff:ff:ff, 802.3, length 20: 
LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x81f5: 
Supervisory, Receiver not Ready, rcv seq 64, Flags [Poll], length 6


... so I wonder if your right about it not sending beacon frames 
properly or maybe I'd see them there as well.



About patch:


+if (vap->iv_opmode ==IEEE80211_M_HOSTAP) {
...
+/* Allow Rx from any BSSID. */
+urtwn_write_4(sc, R92C_RCR,
+urtwn_read_4(sc, R92C_RCR) &
+~(R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN));


Is there any reason for that? (can be useful in ad-hoc mode,
but I'm not sure about hostap).



I'll try it without and report back. This came from the NetBSD patch.



The station wasn't able to associate with both bits stripped. It did 
work with the bssid data bit stripped, so the new patch reflects that. 
I'm not sure what the most appropriate comment update should be there so 
I left it as is.



+/* Set appropriate MSR bits */
+msr |= R92C_MSR_INFRA;


Probably, R92C_MSR_AP should be used here instead.



Definitely. I must have fat fingered something when I was cleaning up 
comments post testing. How embarrassing :/ I'll retest ( just to be 
sure ) and then post a new patch.




Latest patch is attached.

-Matthew
Index: sys/dev/usb/wlan/if_urtwn.c
===
--- sys/dev/usb/wlan/if_urtwn.c (revision 287980)
+++ sys/dev/usb/wlan/if_urtwn.c (working copy)
@@ -430,6 +430,7 @@
ic->ic_caps =
  IEEE80211_C_STA   /* station mode */
| IEEE80211_C_MONITOR   /* monitor mode */
+   | IEEE80211_C_HOSTAP/* HostAp mode supported */
| IEEE80211_C_SHPREAMBLE/* short preamble supported */
| IEEE80211_C_SHSLOT/* short slot time supported */
| IEEE80211_C_BGSCAN/* capable of bg scanning */
@@ -1466,6 +1467,7 @@
struct ieee80211_node *ni;
enum ieee80211_state ostate;
uint32_t reg;
+   u_int8_t msr;
 
ostate = vap->iv_state;
DPRINTF("%s -> %s\n", ieee80211_state_name[ostate],
@@ -1547,6 +1549,16 @@
/* Enable Rx of data frames. */
urtwn_write_2(sc, R92C_RXFLTMAP2, 0x);
 
+   /* Allow Rx from any BSSID. */
+   urtwn_write_4(sc, R92C_RCR,
+   urtwn_read_4(sc, R92C_RCR) &
+   ~(R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN));
+
+   /* Accept Rx data/control/management frames */
+   urtwn_write_4(sc, R92C_RCR,
+   urtwn_read_4(sc, R92C_RCR) |
+   R92C_RCR_ADF | R92C_RCR_ACF | R92C_RCR_AMF);
+
/* Turn link LED on. */
urtwn_set_led(sc, URTWN_LED_LINK, 1);
break;
@@ -1553,6 +1565,7 @@
}
 
ni = ieee80211_ref_node(vap->iv_bss);
+
/* Set media status to 'Associated'. */
reg = urtwn_read_4(sc, R92C_CR);
reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA);
@@ -1576,14 +1589,48 @@
/* Set beacon interval. */
urtwn_write_2(sc, R92C_BCN_INTERVAL, ni->ni_intval);
 
-   /* Allow Rx from our BSSID only. */
-   urtwn_write_4(sc, R92C_RCR,
-   urtwn_read_4(sc, R92C_RCR) |
-   

Re: urtwn and hostap

2015-09-21 Thread Matthew Grooms
Here is a new patch for the urtwn driver. I basically brought over the 
changes committed to NetBSD that enabled hostap mode by merging in what 
appeared to be the relevant differences. I also merged in two changes 
that looked like they would make monitor mode more useful. The only 
change I added was to revert the beacon config register back to it's 
original value when the adapter is switched back to station mode. There 
are no comments around that particular call in the NetBSD driver so I'm 
not sure if what I did was correct, it just seemed logical.


This patch doesn't manually generate a beacon frame using 
ieee80211_beacon_alloc so I assume that setting the MSR register using 
the appropriate value instructs the chip to handle that in hardware. I 
tested this on both my ESXi VM using USB passthru and my raspberry pi 2. 
Both appear to work as expected but the connection seemed less stable on 
the latter. Not sure if my wifi to wifi bridge setup had anything to do 
with that. Performance testing with the VM did produce much better 
results than the previous patch. From the perspective of the associated 
client, it was around 22Mbit down and 6Mbit up. That's pretty close to 
what I get when associating directly to my hardware AP. This patch is 
also not limited to enabling hostap support for only the ES variant. It 
appears to work equally well with my Edimax adapters that use the more 
popular CUS chip.


I'd be happy to deliver a compatible USB adapter to any FreeBSD 
developer who is willing to take a look at this. :)


Thanks again,

-Matthew

On 9/17/2015 12:11 PM, Adrian Chadd wrote:

hah, make no assumptions about correctness. :)

Some of these NICs will do hostap mode themselves - you configure them
in hostap mode and they take care of managing beaconing, station
state, power save management, etc. This patch doesn't do that - it's
just treating the NIC as a mostly dumb device and expecting the stack
to do it.

It's fine as a starting point, as long as the NIC and its firmware is
happy with it. But yes, we do need to figure out how to get the beacon
updates to push new beacon frames into the NIC as required.



-adrian


On 17 September 2015 at 09:29, Matthew Grooms  wrote:

I just assumed that the card was doing the right thing with the beacon since
it was being loaded into a specific queue. Like I said, I'm fumbling around
here. Ok, I see the NetBSD commit now. It doesn't look anything like the
patch I was working with. It also doesn't look specific to RTL8188E ...

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_urtwn.c.diff?r1=1.25=1.26_with_tag=MAIN

I should have checked NetBSD before hand :/

-Matthew


On 9/17/2015 10:22 AM, Adrian Chadd wrote:

I think this patch is missing beacon updates - it just transmits the
same beacon over and oveR?


-a


On 17 September 2015 at 08:12, Kevin Lo  wrote:

On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote:

Seems to behave better now and hostap appears to be working ...

#ifconfig wlan0 create wlandev urtwn0 wlanmode hostap
#ifconfig wlan0 list caps

drivercaps=2181c401

#ifconfig wlan0 up ssid freebsdap mode 11g channel 1
#ifconfig bridge0 create up addm em0 addm wlan0

#ifconfig wlan0
wlan0: flags=8943 metric
0 mtu 1500
   ether 00:c3:e1:16:11:32
   nd6 options=29
   media: IEEE 802.11 Wireless Ethernet autoselect mode 11g

   status: running
   ssid freebsdap channel 1 (2412 MHz 11g) bssid
00:c3:e1:16:11:32
   country US authmode OPEN privacy OFF txpower 0 scanvalid 60
   protmode CTS dtimperiod 1 -dfs
   groups: wlan

#ifconfig bridge0
bridge0: flags=8843 metric 0 mtu
1500
   ether 02:df:20:d2:42:00
   nd6 options=1
   groups: bridge
   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
   maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
   member: wlan0 flags=143
   ifmaxaddr 0 port 3 priority 128 path cost 370370
   member: em0 flags=143
   ifmaxaddr 0 port 1 priority 128 path cost 2

The speed leaves a lot to be desired. Throughput for the associated host
is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative
of a problem. Occasionally I also see the this message on the console
when I'm bringing the adapter up ...

wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost

If I down and up the adapter again, it seems to correct itself. Not sure
what that's all about. I am passing the USB adapter through to a VM
inside of ESXi to test the patch, so maybe that has 

Re: urtwn and hostap

2015-09-21 Thread Matthew Grooms

On 9/21/2015 7:19 AM, Andriy Voskoboinyk wrote:

Here is a new patch for the urtwn driver. I basically brought over the
changes committed to NetBSD that enabled hostap mode by merging in what
appeared to be the relevant differences. I also merged in two changes
that looked like they would make monitor mode more useful.



The only
change I added was to revert the beacon config register back to it's
original value when the adapter is switched back to station mode. There
are no comments around that particular call in the NetBSD driver so I'm
not sure if what I did was correct, it just seemed logical.


I think too.


This patch doesn't manually generate a beacon frame using
ieee80211_beacon_alloc so I assume that setting the MSR register using
the appropriate value instructs the chip to handle that in hardware. I
tested this on both my ESXi VM using USB passthru and my raspberry pi 2.
Both appear to work as expected but the connection seemed less stable on
the latter.


Can you check this with tcpdump(1) or dumpcap(1) on the sta side?
(I have seen configurations, where STA's were associated with an AP
without beaconing).



I'll give that a try and report back.


About patch:


+if (vap->iv_opmode ==IEEE80211_M_HOSTAP) {
...
+/* Allow Rx from any BSSID. */
+urtwn_write_4(sc, R92C_RCR,
+urtwn_read_4(sc, R92C_RCR) &
+~(R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN));


Is there any reason for that? (can be useful in ad-hoc mode,
but I'm not sure about hostap).



I'll try it without and report back. This came from the NetBSD patch.


+/* Set appropriate MSR bits */
+msr |= R92C_MSR_INFRA;


Probably, R92C_MSR_AP should be used here instead.



Definitely. I must have fat fingered something when I was cleaning up 
comments post testing. How embarrassing :/ I'll retest ( just to be sure 
) and then post a new patch.


Thanks!

-Matthew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-17 Thread Matthew Grooms

Seems to behave better now and hostap appears to be working ...

#ifconfig wlan0 create wlandev urtwn0 wlanmode hostap
#ifconfig wlan0 list caps
drivercaps=2181c401

#ifconfig wlan0 up ssid freebsdap mode 11g channel 1
#ifconfig bridge0 create up addm em0 addm wlan0

#ifconfig wlan0
wlan0: flags=8943 metric 
0 mtu 1500

ether 00:c3:e1:16:11:32
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
status: running
ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32
country US authmode OPEN privacy OFF txpower 0 scanvalid 60
protmode CTS dtimperiod 1 -dfs
groups: wlan

#ifconfig bridge0
bridge0: flags=8843 metric 0 mtu 
1500

ether 02:df:20:d2:42:00
nd6 options=1
groups: bridge
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: wlan0 flags=143
ifmaxaddr 0 port 3 priority 128 path cost 370370
member: em0 flags=143
ifmaxaddr 0 port 1 priority 128 path cost 2

The speed leaves a lot to be desired. Throughput for the associated host 
is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative 
of a problem. Occasionally I also see the this message on the console 
when I'm bringing the adapter up ...


wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost

If I down and up the adapter again, it seems to correct itself. Not sure 
what that's all about. I am passing the USB adapter through to a VM 
inside of ESXi to test the patch, so maybe that has something to do with 
these quirks. I'll try to run some tests with the adapter associated to 
a physical AP tomorrow to get a baseline.


Thanks,

-Matthew

On 9/16/2015 11:24 AM, Adrian Chadd wrote:

The only one to look at is ath(4). I've not fixed/hacked on any other
hostap chips. :)

if_ath_beacon.c has the logic - it gets a reference when creating a
beacon frame.



-adrian


On 16 September 2015 at 09:21, Matthew Grooms  wrote:

On 9/16/2015 10:58 AM, Adrian Chadd wrote:

I think the net80211 beacon create routine doesn't allocate a node
ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
calling becaon_create(), and deref it if the tx fails. The TX success
will free the node ref for you.


Got it. I'll take another look at one of the drivers that support hostap to
make sure I'm following the same pattern. Thanks again for the feedback!

-Matthew



-adrian


On 16 September 2015 at 04:27, Idwer Vollering  wrote:

2015-09-16 8:06 GMT+02:00 Matthew Grooms :


It looks like my screenshot got scrubbed. Here is my hopefully faithful
transcription ...

Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x80a01105
stack pointer   = 0x28:0xfe0092fe86f0
frame pointer = 0x28:0xfe0092fe8740
code segment = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran
1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 716 (ifconfig)
[thread pid 716 tid 100082 ]
Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
db> bt
Tracing pid 716 tid 100082 td 0xff800512814d0
__mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
ieee80211_free_node() at ieee80211_free_node()_0x38/frame
0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
0xfe0092fe87a0
ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
0xfe0092fe87d0
urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame
0xfe0092fe8840
if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
-- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =
0x7fffe2f8, rbp = 0x7fffe310 --
db>

Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have
entered 'dump' at the db> blinker :)

The trap details are found in /var/crash/, run kgdb: "kgdb
/boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at
its prompt.


-Matthew
___
freebsd-wireless@freebsd.org mailing list

Re: urtwn and hostap

2015-09-17 Thread Adrian Chadd
I think this patch is missing beacon updates - it just transmits the
same beacon over and oveR?


-a


On 17 September 2015 at 08:12, Kevin Lo  wrote:
> On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote:
>> Seems to behave better now and hostap appears to be working ...
>>
>> #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap
>> #ifconfig wlan0 list caps
>> drivercaps=2181c401
>>
>> #ifconfig wlan0 up ssid freebsdap mode 11g channel 1
>> #ifconfig bridge0 create up addm em0 addm wlan0
>>
>> #ifconfig wlan0
>> wlan0: flags=8943 metric
>> 0 mtu 1500
>>  ether 00:c3:e1:16:11:32
>>  nd6 options=29
>>  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
>>  status: running
>>  ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32
>>  country US authmode OPEN privacy OFF txpower 0 scanvalid 60
>>  protmode CTS dtimperiod 1 -dfs
>>  groups: wlan
>>
>> #ifconfig bridge0
>> bridge0: flags=8843 metric 0 mtu
>> 1500
>>  ether 02:df:20:d2:42:00
>>  nd6 options=1
>>  groups: bridge
>>  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>>  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>  member: wlan0 flags=143
>>  ifmaxaddr 0 port 3 priority 128 path cost 370370
>>  member: em0 flags=143
>>  ifmaxaddr 0 port 1 priority 128 path cost 2
>>
>> The speed leaves a lot to be desired. Throughput for the associated host
>> is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative
>> of a problem. Occasionally I also see the this message on the console
>> when I'm bringing the adapter up ...
>>
>> wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost
>>
>> If I down and up the adapter again, it seems to correct itself. Not sure
>> what that's all about. I am passing the USB adapter through to a VM
>> inside of ESXi to test the patch, so maybe that has something to do with
>> these quirks. I'll try to run some tests with the adapter associated to
>> a physical AP tomorrow to get a baseline.
>
> I knew OpenBSD had patches about hostap support for urtwn(4), but those
> don't look quite right.  I think that's why OpenBSD developers didn't
> commit them.  BTW, NetBSD adopted OpenBSD's patches, I tested it on NetBSD
> about four months ago, the connection was not stable...
>
>> Thanks,
>>
>> -Matthew
>
> Kevin
>
>> On 9/16/2015 11:24 AM, Adrian Chadd wrote:
>> > The only one to look at is ath(4). I've not fixed/hacked on any other
>> > hostap chips. :)
>> >
>> > if_ath_beacon.c has the logic - it gets a reference when creating a
>> > beacon frame.
>> >
>> >
>> >
>> > -adrian
>> >
>> >
>> > On 16 September 2015 at 09:21, Matthew Grooms  wrote:
>> >> On 9/16/2015 10:58 AM, Adrian Chadd wrote:
>> >>> I think the net80211 beacon create routine doesn't allocate a node
>> >>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
>> >>> calling becaon_create(), and deref it if the tx fails. The TX success
>> >>> will free the node ref for you.
>> >>>
>> >> Got it. I'll take another look at one of the drivers that support hostap 
>> >> to
>> >> make sure I'm following the same pattern. Thanks again for the feedback!
>> >>
>> >> -Matthew
>> >>
>> >>
>> >>> -adrian
>> >>>
>> >>>
>> >>> On 16 September 2015 at 04:27, Idwer Vollering  wrote:
>>  2015-09-16 8:06 GMT+02:00 Matthew Grooms :
>> 
>> > It looks like my screenshot got scrubbed. Here is my hopefully faithful
>> > transcription ...
>> >
>> > Fatal trap 9: general protection fault while in kernel mode
>> > cpuid = 3; apic id = 03
>> > instruction pointer = 0x20:0x80a01105
>> > stack pointer   = 0x28:0xfe0092fe86f0
>> > frame pointer = 0x28:0xfe0092fe8740
>> > code segment = base 0x0, limit 0xf, type 0x1b
>> >= DPL 0, pres 1, long 1, def32 0, 
>> > gran
>> > 1
>> > processor eflags = interrupt enabled, resume, IOPL = 0
>> > current process  = 716 (ifconfig)
>> > [thread pid 716 tid 100082 ]
>> > Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
>> > db> bt
>> > Tracing pid 716 tid 100082 td 0xff800512814d0
>> > __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
>> > ieee80211_free_node() at ieee80211_free_node()_0x38/frame
>> > 0xfe0092fe8780
>> > ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
>> > 

Re: urtwn and hostap

2015-09-17 Thread Matthew Grooms
I just assumed that the card was doing the right thing with the beacon 
since it was being loaded into a specific queue. Like I said, I'm 
fumbling around here. Ok, I see the NetBSD commit now. It doesn't look 
anything like the patch I was working with. It also doesn't look 
specific to RTL8188E ...


http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_urtwn.c.diff?r1=1.25=1.26_with_tag=MAIN

I should have checked NetBSD before hand :/

-Matthew

On 9/17/2015 10:22 AM, Adrian Chadd wrote:

I think this patch is missing beacon updates - it just transmits the
same beacon over and oveR?


-a


On 17 September 2015 at 08:12, Kevin Lo  wrote:

On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote:

Seems to behave better now and hostap appears to be working ...

#ifconfig wlan0 create wlandev urtwn0 wlanmode hostap
#ifconfig wlan0 list caps
drivercaps=2181c401

#ifconfig wlan0 up ssid freebsdap mode 11g channel 1
#ifconfig bridge0 create up addm em0 addm wlan0

#ifconfig wlan0
wlan0: flags=8943 metric
0 mtu 1500
  ether 00:c3:e1:16:11:32
  nd6 options=29
  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
  status: running
  ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32
  country US authmode OPEN privacy OFF txpower 0 scanvalid 60
  protmode CTS dtimperiod 1 -dfs
  groups: wlan

#ifconfig bridge0
bridge0: flags=8843 metric 0 mtu
1500
  ether 02:df:20:d2:42:00
  nd6 options=1
  groups: bridge
  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
  member: wlan0 flags=143
  ifmaxaddr 0 port 3 priority 128 path cost 370370
  member: em0 flags=143
  ifmaxaddr 0 port 1 priority 128 path cost 2

The speed leaves a lot to be desired. Throughput for the associated host
is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative
of a problem. Occasionally I also see the this message on the console
when I'm bringing the adapter up ...

wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost

If I down and up the adapter again, it seems to correct itself. Not sure
what that's all about. I am passing the USB adapter through to a VM
inside of ESXi to test the patch, so maybe that has something to do with
these quirks. I'll try to run some tests with the adapter associated to
a physical AP tomorrow to get a baseline.

I knew OpenBSD had patches about hostap support for urtwn(4), but those
don't look quite right.  I think that's why OpenBSD developers didn't
commit them.  BTW, NetBSD adopted OpenBSD's patches, I tested it on NetBSD
about four months ago, the connection was not stable...


Thanks,

-Matthew

 Kevin


On 9/16/2015 11:24 AM, Adrian Chadd wrote:

The only one to look at is ath(4). I've not fixed/hacked on any other
hostap chips. :)

if_ath_beacon.c has the logic - it gets a reference when creating a
beacon frame.



-adrian


On 16 September 2015 at 09:21, Matthew Grooms  wrote:

On 9/16/2015 10:58 AM, Adrian Chadd wrote:

I think the net80211 beacon create routine doesn't allocate a node
ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
calling becaon_create(), and deref it if the tx fails. The TX success
will free the node ref for you.


Got it. I'll take another look at one of the drivers that support hostap to
make sure I'm following the same pattern. Thanks again for the feedback!

-Matthew



-adrian


On 16 September 2015 at 04:27, Idwer Vollering  wrote:

2015-09-16 8:06 GMT+02:00 Matthew Grooms :


It looks like my screenshot got scrubbed. Here is my hopefully faithful
transcription ...

Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x80a01105
stack pointer   = 0x28:0xfe0092fe86f0
frame pointer = 0x28:0xfe0092fe8740
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran
1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 716 (ifconfig)
[thread pid 716 tid 100082 ]
Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
db> bt
Tracing pid 716 tid 100082 td 0xff800512814d0
__mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
ieee80211_free_node() at ieee80211_free_node()_0x38/frame
0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
0xfe0092fe87a0

Re: urtwn and hostap

2015-09-17 Thread Kevin Lo
On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote:
> Seems to behave better now and hostap appears to be working ...
> 
> #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap
> #ifconfig wlan0 list caps
> drivercaps=2181c401
> 
> #ifconfig wlan0 up ssid freebsdap mode 11g channel 1
> #ifconfig bridge0 create up addm em0 addm wlan0
> 
> #ifconfig wlan0
> wlan0: flags=8943 metric 
> 0 mtu 1500
>  ether 00:c3:e1:16:11:32
>  nd6 options=29
>  media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
>  status: running
>  ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32
>  country US authmode OPEN privacy OFF txpower 0 scanvalid 60
>  protmode CTS dtimperiod 1 -dfs
>  groups: wlan
> 
> #ifconfig bridge0
> bridge0: flags=8843 metric 0 mtu 
> 1500
>  ether 02:df:20:d2:42:00
>  nd6 options=1
>  groups: bridge
>  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>  member: wlan0 flags=143
>  ifmaxaddr 0 port 3 priority 128 path cost 370370
>  member: em0 flags=143
>  ifmaxaddr 0 port 1 priority 128 path cost 2
> 
> The speed leaves a lot to be desired. Throughput for the associated host 
> is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative 
> of a problem. Occasionally I also see the this message on the console 
> when I'm bringing the adapter up ...
> 
> wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost
> 
> If I down and up the adapter again, it seems to correct itself. Not sure 
> what that's all about. I am passing the USB adapter through to a VM 
> inside of ESXi to test the patch, so maybe that has something to do with 
> these quirks. I'll try to run some tests with the adapter associated to 
> a physical AP tomorrow to get a baseline.

I knew OpenBSD had patches about hostap support for urtwn(4), but those
don't look quite right.  I think that's why OpenBSD developers didn't 
commit them.  BTW, NetBSD adopted OpenBSD's patches, I tested it on NetBSD
about four months ago, the connection was not stable...

> Thanks,
> 
> -Matthew

Kevin

> On 9/16/2015 11:24 AM, Adrian Chadd wrote:
> > The only one to look at is ath(4). I've not fixed/hacked on any other
> > hostap chips. :)
> >
> > if_ath_beacon.c has the logic - it gets a reference when creating a
> > beacon frame.
> >
> >
> >
> > -adrian
> >
> >
> > On 16 September 2015 at 09:21, Matthew Grooms  wrote:
> >> On 9/16/2015 10:58 AM, Adrian Chadd wrote:
> >>> I think the net80211 beacon create routine doesn't allocate a node
> >>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
> >>> calling becaon_create(), and deref it if the tx fails. The TX success
> >>> will free the node ref for you.
> >>>
> >> Got it. I'll take another look at one of the drivers that support hostap to
> >> make sure I'm following the same pattern. Thanks again for the feedback!
> >>
> >> -Matthew
> >>
> >>
> >>> -adrian
> >>>
> >>>
> >>> On 16 September 2015 at 04:27, Idwer Vollering  wrote:
>  2015-09-16 8:06 GMT+02:00 Matthew Grooms :
> 
> > It looks like my screenshot got scrubbed. Here is my hopefully faithful
> > transcription ...
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 3; apic id = 03
> > instruction pointer = 0x20:0x80a01105
> > stack pointer   = 0x28:0xfe0092fe86f0
> > frame pointer = 0x28:0xfe0092fe8740
> > code segment = base 0x0, limit 0xf, type 0x1b
> >= DPL 0, pres 1, long 1, def32 0, 
> > gran
> > 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process  = 716 (ifconfig)
> > [thread pid 716 tid 100082 ]
> > Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
> > db> bt
> > Tracing pid 716 tid 100082 td 0xff800512814d0
> > __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
> > ieee80211_free_node() at ieee80211_free_node()_0x38/frame
> > 0xfe0092fe8780
> > ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
> > 0xfe0092fe87a0
> > ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
> > 0xfe0092fe87d0
> > urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
> > if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame
> > 0xfe0092fe8840
> 

Re: urtwn and hostap

2015-09-17 Thread Adrian Chadd
hah, make no assumptions about correctness. :)

Some of these NICs will do hostap mode themselves - you configure them
in hostap mode and they take care of managing beaconing, station
state, power save management, etc. This patch doesn't do that - it's
just treating the NIC as a mostly dumb device and expecting the stack
to do it.

It's fine as a starting point, as long as the NIC and its firmware is
happy with it. But yes, we do need to figure out how to get the beacon
updates to push new beacon frames into the NIC as required.



-adrian


On 17 September 2015 at 09:29, Matthew Grooms  wrote:
> I just assumed that the card was doing the right thing with the beacon since
> it was being loaded into a specific queue. Like I said, I'm fumbling around
> here. Ok, I see the NetBSD commit now. It doesn't look anything like the
> patch I was working with. It also doesn't look specific to RTL8188E ...
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_urtwn.c.diff?r1=1.25=1.26_with_tag=MAIN
>
> I should have checked NetBSD before hand :/
>
> -Matthew
>
>
> On 9/17/2015 10:22 AM, Adrian Chadd wrote:
>>
>> I think this patch is missing beacon updates - it just transmits the
>> same beacon over and oveR?
>>
>>
>> -a
>>
>>
>> On 17 September 2015 at 08:12, Kevin Lo  wrote:
>>>
>>> On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote:

 Seems to behave better now and hostap appears to be working ...

 #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap
 #ifconfig wlan0 list caps

 drivercaps=2181c401

 #ifconfig wlan0 up ssid freebsdap mode 11g channel 1
 #ifconfig bridge0 create up addm em0 addm wlan0

 #ifconfig wlan0
 wlan0: flags=8943 metric
 0 mtu 1500
   ether 00:c3:e1:16:11:32
   nd6 options=29
   media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
 
   status: running
   ssid freebsdap channel 1 (2412 MHz 11g) bssid
 00:c3:e1:16:11:32
   country US authmode OPEN privacy OFF txpower 0 scanvalid 60
   protmode CTS dtimperiod 1 -dfs
   groups: wlan

 #ifconfig bridge0
 bridge0: flags=8843 metric 0 mtu
 1500
   ether 02:df:20:d2:42:00
   nd6 options=1
   groups: bridge
   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
   maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
   member: wlan0 flags=143
   ifmaxaddr 0 port 3 priority 128 path cost 370370
   member: em0 flags=143
   ifmaxaddr 0 port 1 priority 128 path cost 2

 The speed leaves a lot to be desired. Throughput for the associated host
 is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative
 of a problem. Occasionally I also see the this message on the console
 when I'm bringing the adapter up ...

 wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost

 If I down and up the adapter again, it seems to correct itself. Not sure
 what that's all about. I am passing the USB adapter through to a VM
 inside of ESXi to test the patch, so maybe that has something to do with
 these quirks. I'll try to run some tests with the adapter associated to
 a physical AP tomorrow to get a baseline.
>>>
>>> I knew OpenBSD had patches about hostap support for urtwn(4), but those
>>> don't look quite right.  I think that's why OpenBSD developers didn't
>>> commit them.  BTW, NetBSD adopted OpenBSD's patches, I tested it on
>>> NetBSD
>>> about four months ago, the connection was not stable...
>>>
 Thanks,

 -Matthew
>>>
>>>  Kevin
>>>
 On 9/16/2015 11:24 AM, Adrian Chadd wrote:
>
> The only one to look at is ath(4). I've not fixed/hacked on any other
> hostap chips. :)
>
> if_ath_beacon.c has the logic - it gets a reference when creating a
> beacon frame.
>
>
>
> -adrian
>
>
> On 16 September 2015 at 09:21, Matthew Grooms 
> wrote:
>>
>> On 9/16/2015 10:58 AM, Adrian Chadd wrote:
>>>
>>> I think the net80211 beacon create routine doesn't allocate a node
>>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
>>> calling becaon_create(), and deref it if the tx fails. The TX success
>>> will free the node ref for you.
>>>
>> Got it. I'll take another look at one of the drivers that support
>> hostap to
>> make sure I'm following the same 

Re: urtwn and hostap

2015-09-16 Thread Matthew Grooms

On 9/16/2015 12:43 AM, Matthew Grooms wrote:

Hey wireless folks,

I wanted to setup a Raspberry Pi as a FreeBSD AP and purchased a 
picked up a few Edimax 802.11 adapters to play with. Unfortunately 
these aren't supported in hostap mode. As it turns out these Edimax 
adapters use the RTL8188CUS chipset so I poked around the net and 
noticed that Linux does support the host AP feature with it's 
RTL8188CUS driver. I was also able to find a patch for OpenBSD that 
added support for the RTL8188EU chipset to the urtwn driver ...


http://marc.info/?l=openbsd-tech=143577648117514=2

So I ordered one of these which arrived from China a few weeks later ...

http://www.amazon.com/gp/product/B00L28AN88?psc=1=true_=oh_aui_detailpage_o05_s00 



Next I took a stab at porting the patch to FreeBSD. With the attached 
patch applied, I was able to setup a wlan0 device with the hostap 
feature. After bridging it with the LAN I could associate with my 
android phone, obtain an IP address via DHCP, browse a few web pages 
and watch all the packets pass through the bridge. Sadly, when I 
attempted to destroy the wlan0 device I got a kernel panic. The 
screenshot for that is also attached and I'm not sure if I'm going to 
be able to figure this one out without some help. I'm pretty out of my 
element here. I assume it's happening in ieee80211_free_node() when 
IEEE80211_NODE_LOCK() is called. To be clear, the crash only occurs 
when the adapter is configured in hostap mode with the patch applied. 
Anyone have any suggestions as to what I should be looking at to 
prevent this crash?


If I can get this working for the RTL8188EU, I'll also take a stab at 
getting the RTL8188CUS chipset working in hostap mode. That is, 
assuming I can glean enough info from drivers that support this 
feature on other open source platforms. It appears to be extremely 
popular with the Raspberry PI crowd ...


http://www.amazon.com/Edimax-EW-7811Un-150Mbps-Raspberry-Supports/dp/B003MTTJOY 





It looks like my screenshot got scrubbed. Here is my hopefully faithful 
transcription ...


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x80a01105
stack pointer   = 0x28:0xfe0092fe86f0
frame pointer = 0x28:0xfe0092fe8740
code segment = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 716 (ifconfig)
[thread pid 716 tid 100082 ]
Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
db> bt
Tracing pid 716 tid 100082 td 0xff800512814d0
__mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame 
0xfe0092fe87a0
ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame 
0xfe0092fe87d0

urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfe0092fe8840
if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
-- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = 
0x7fffe2f8, rbp = 0x7fffe310 --

db>

-Matthew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Andriy Voskoboinyk
ieee80211_free_node() at ieee80211_free_node()_0x38/frame  
0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame  
0xfe0092fe87a0
ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame  
0xfe0092fe87d0

urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame  
0xfe0092fe8840

if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
-- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =  
0x7fffe2f8, rbp = 0x7fffe310 --

db>

-Matthew


I'm suspecting that ieee80211_tx_complete() eats one extra reference to the
vap->iv_bss - try to add ieee80211_node_incref(vap->iv_bss);
before urtwn_tx_start() (this is not a proper solution, but should work
for now).
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Idwer Vollering
2015-09-16 8:06 GMT+02:00 Matthew Grooms :

>
> It looks like my screenshot got scrubbed. Here is my hopefully faithful
> transcription ...
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 3; apic id = 03
> instruction pointer = 0x20:0x80a01105
> stack pointer   = 0x28:0xfe0092fe86f0
> frame pointer = 0x28:0xfe0092fe8740
> code segment = base 0x0, limit 0xf, type 0x1b
>  = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process  = 716 (ifconfig)
> [thread pid 716 tid 100082 ]
> Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
> db> bt
> Tracing pid 716 tid 100082 td 0xff800512814d0
> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
> ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfe0092fe8780
> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
> 0xfe0092fe87a0
> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
> 0xfe0092fe87d0
> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfe0092fe8840
> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
> kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
> sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
> amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =
> 0x7fffe2f8, rbp = 0x7fffe310 --
> db>

Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have
entered 'dump' at the db> blinker :)

The trap details are found in /var/crash/, run kgdb: "kgdb
/boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at
its prompt.

>
> -Matthew
> ___
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Adrian Chadd
I think the net80211 beacon create routine doesn't allocate a node
ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
calling becaon_create(), and deref it if the tx fails. The TX success
will free the node ref for you.



-adrian


On 16 September 2015 at 04:27, Idwer Vollering  wrote:
> 2015-09-16 8:06 GMT+02:00 Matthew Grooms :
>
>>
>> It looks like my screenshot got scrubbed. Here is my hopefully faithful
>> transcription ...
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 3; apic id = 03
>> instruction pointer = 0x20:0x80a01105
>> stack pointer   = 0x28:0xfe0092fe86f0
>> frame pointer = 0x28:0xfe0092fe8740
>> code segment = base 0x0, limit 0xf, type 0x1b
>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process  = 716 (ifconfig)
>> [thread pid 716 tid 100082 ]
>> Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
>> db> bt
>> Tracing pid 716 tid 100082 td 0xff800512814d0
>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfe0092fe8780
>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
>> 0xfe0092fe87a0
>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
>> 0xfe0092fe87d0
>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfe0092fe8840
>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =
>> 0x7fffe2f8, rbp = 0x7fffe310 --
>> db>
>
> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have
> entered 'dump' at the db> blinker :)
>
> The trap details are found in /var/crash/, run kgdb: "kgdb
> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at
> its prompt.
>
>>
>> -Matthew
>> ___
>> freebsd-wireless@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
> ___
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Matthew Grooms

On 9/16/2015 6:27 AM, Idwer Vollering wrote:

2015-09-16 8:06 GMT+02:00 Matthew Grooms :


It looks like my screenshot got scrubbed. Here is my hopefully faithful
transcription ...

Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x80a01105
stack pointer   = 0x28:0xfe0092fe86f0
frame pointer = 0x28:0xfe0092fe8740
code segment = base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 716 (ifconfig)
[thread pid 716 tid 100082 ]
Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
db> bt
Tracing pid 716 tid 100082 td 0xff800512814d0
__mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
0xfe0092fe87a0
ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
0xfe0092fe87d0
urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfe0092fe8840
if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
-- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =
0x7fffe2f8, rbp = 0x7fffe310 --
db>

Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have
entered 'dump' at the db> blinker :)

The trap details are found in /var/crash/, run kgdb: "kgdb
/boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at
its prompt.


That sounds super useful. I felt like I was fumbling around in the dark 
at the db prompt :)


Thanks again,

-Matthew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Adrian Chadd
The only one to look at is ath(4). I've not fixed/hacked on any other
hostap chips. :)

if_ath_beacon.c has the logic - it gets a reference when creating a
beacon frame.



-adrian


On 16 September 2015 at 09:21, Matthew Grooms  wrote:
> On 9/16/2015 10:58 AM, Adrian Chadd wrote:
>>
>> I think the net80211 beacon create routine doesn't allocate a node
>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
>> calling becaon_create(), and deref it if the tx fails. The TX success
>> will free the node ref for you.
>>
>
> Got it. I'll take another look at one of the drivers that support hostap to
> make sure I'm following the same pattern. Thanks again for the feedback!
>
> -Matthew
>
>
>>
>> -adrian
>>
>>
>> On 16 September 2015 at 04:27, Idwer Vollering  wrote:
>>>
>>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms :
>>>
 It looks like my screenshot got scrubbed. Here is my hopefully faithful
 transcription ...

 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 3; apic id = 03
 instruction pointer = 0x20:0x80a01105
 stack pointer   = 0x28:0xfe0092fe86f0
 frame pointer = 0x28:0xfe0092fe8740
 code segment = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran
 1
 processor eflags = interrupt enabled, resume, IOPL = 0
 current process  = 716 (ifconfig)
 [thread pid 716 tid 100082 ]
 Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
 db> bt
 Tracing pid 716 tid 100082 td 0xff800512814d0
 __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
 ieee80211_free_node() at ieee80211_free_node()_0x38/frame
 0xfe0092fe8780
 ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
 0xfe0092fe87a0
 ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
 0xfe0092fe87d0
 urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
 if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame
 0xfe0092fe8840
 if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
 kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
 sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
 amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
 Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
 -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =
 0x7fffe2f8, rbp = 0x7fffe310 --
 db>
>>>
>>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have
>>> entered 'dump' at the db> blinker :)
>>>
>>> The trap details are found in /var/crash/, run kgdb: "kgdb
>>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at
>>> its prompt.
>>>
 -Matthew
 ___
 freebsd-wireless@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
 To unsubscribe, send any mail to
 "freebsd-wireless-unsubscr...@freebsd.org"
>>>
>>> ___
>>> freebsd-wireless@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>> To unsubscribe, send any mail to
>>> "freebsd-wireless-unsubscr...@freebsd.org"
>>
>> ___
>> freebsd-wireless@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>> To unsubscribe, send any mail to
>> "freebsd-wireless-unsubscr...@freebsd.org"
>
>
> ___
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Matthew Grooms

On 9/16/2015 1:54 AM, Andriy Voskoboinyk wrote:
ieee80211_free_node() at ieee80211_free_node()_0x38/frame 
0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame 
0xfe0092fe87a0
ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame 
0xfe0092fe87d0

urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 
0xfe0092fe8840

if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
-- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = 
0x7fffe2f8, rbp = 0x7fffe310 --

db>

-Matthew


I'm suspecting that ieee80211_tx_complete() eats one extra reference 
to the

vap->iv_bss - try to add ieee80211_node_incref(vap->iv_bss);
before urtwn_tx_start() (this is not a proper solution, but should work
for now).


Ahh, that makes sense. I'll look at that tonight. Thanks for the suggestion!

-Matthew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


Re: urtwn and hostap

2015-09-16 Thread Matthew Grooms

On 9/16/2015 10:58 AM, Adrian Chadd wrote:

I think the net80211 beacon create routine doesn't allocate a node
ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after
calling becaon_create(), and deref it if the tx fails. The TX success
will free the node ref for you.



Got it. I'll take another look at one of the drivers that support hostap 
to make sure I'm following the same pattern. Thanks again for the feedback!


-Matthew



-adrian


On 16 September 2015 at 04:27, Idwer Vollering  wrote:

2015-09-16 8:06 GMT+02:00 Matthew Grooms :


It looks like my screenshot got scrubbed. Here is my hopefully faithful
transcription ...

Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x80a01105
stack pointer   = 0x28:0xfe0092fe86f0
frame pointer = 0x28:0xfe0092fe8740
code segment = base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 716 (ifconfig)
[thread pid 716 tid 100082 ]
Stopped at  __mtx_lock_flags+0x55:  movq(%r13),%rax
db> bt
Tracing pid 716 tid 100082 td 0xff800512814d0
__mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfe0092fe8740
ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfe0092fe8780
ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame
0xfe0092fe87a0
ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame
0xfe0092fe87d0
urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfe0092fe87f0
if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfe0092fe8840
if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfe0092fe8860
kern_ioctl() at kern_ioctl()+0x230/frame 0xfe0092fe88c0
sys_ioctl() at sys_ioctl()+0x153/frame 0xfe0092fe89a0
amd64_syscall() at amd64_syscall()+0x282/frame 0xfe0092fe8ab0
Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfe0092fe8ab0
-- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp =
0x7fffe2f8, rbp = 0x7fffe310 --
db>

Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have
entered 'dump' at the db> blinker :)

The trap details are found in /var/crash/, run kgdb: "kgdb
/boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at
its prompt.


-Matthew
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"


___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"