Re: urtwn and hostap
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
Re: urtwn and hostap
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
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&r2=1.26&only_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
Re: urtwn and hostap
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&r2=1.26&only_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 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 0xfff
Re: urtwn and hostap
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 https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" ___ freebsd-wireless@freebsd.org mailing li
Re: urtwn and hostap
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"
Re: urtwn and hostap
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
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
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&m=143577648117514&w=2 So I ordered one of these which arrived from China a few weeks later ... http://www.amazon.com/gp/product/B00L28AN88?psc=1&redirect=true&ref_=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"
urtwn and hostap
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&m=143577648117514&w=2
So I ordered one of these which arrived from China a few weeks later ...
http://www.amazon.com/gp/product/B00L28AN88?psc=1&redirect=true&ref_=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
Thanks in advance,
-Matthew
Index: dev/usb/wlan/if_urtwn.c
===
--- dev/usb/wlan/if_urtwn.c (revision 287342)
+++ dev/usb/wlan/if_urtwn.c (working copy)
@@ -181,6 +181,8 @@
static struct mbuf * urtwn_rxeof(struct usb_xfer *, struct urtwn_data *,
int *, int8_t *);
static voidurtwn_txeof(struct usb_xfer *, struct urtwn_data *);
+inturtwn_txbcn(struct ieee80211vap *vap,
+ struct ieee80211_node *);
static int urtwn_alloc_list(struct urtwn_softc *,
struct urtwn_data[], int, int);
static int urtwn_alloc_rx_list(struct urtwn_softc *);
@@ -436,6 +438,10 @@
| IEEE80211_C_WPA /* 802.11i */
;
+ if (sc->chip & URTWN_CHIP_88E)
+ ic->ic_caps |=
+ IEEE80211_C_HOSTAP; /* HostAp mode supported */
+
bands = 0;
setbit(&bands, IEEE80211_MODE_11B);
setbit(&bands, IEEE80211_MODE_11G);
@@ -857,6 +863,36 @@
sc->sc_txtimer = 0;
}
+/*
+ * Push a beacon frame into the chip and check if it was accepted. Beacon will
+ * be repeated by the chip every R92C_BCN_INTERVAL.
+ */
+int
+urtwn_txbcn(struct ieee80211vap *vap, struct ieee80211_node *ni)
+{
+ struct ieee80211com *ic = ni->ni_ic;
+ struct urtwn_softc *sc = ic->ic_softc;
+ struct urtwn_data *bf;
+ struct mbuf *m;
+
+ m = ieee80211_beacon_alloc(ni, &URTWN_VAP(vap)->bo);
+
+ bf = urtwn_getbuf(sc);
+ if (bf == NULL) {
+ m_freem(m);
+ return (ENOBUFS);
+ }
+
+ if (urtwn_tx_start(sc, ni, m, bf) != 0) {
+ STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next);
+ return (EIO);
+ }
+
+ sc->sc_txtimer = 5;
+
+ return (0);
+}
+
static void
urtwn_bulk_tx_callback(struct usb_xfer *xfer, usb_error_t error)
{
@@ -1466,6 +1502,7 @@
struct ieee80211_node *ni;
enum ieee80211_state ostate;
uint32_t reg;
+ int error;
ostate = vap->iv_state;
DPRINTF("%s -> %s\n", ieee80211_state_name[ostate],
@@ -1553,23 +1590,68 @@
}
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);
- urtwn_write_4(sc, R92C_CR, reg);
- /* Set BSSID. */
- urtwn_write_4(sc, R92C_BSSID + 0, LE_READ_4(&ni->ni_bssid[0]));
- urtwn_write_4(sc, R92C_BSSID + 4, LE_READ_2(&ni->ni_bssid[4]));
+ if (ic->ic_opmode == IEEE80211_M_STA) {
+ /* Set BSSID. */
+ urtwn_write_4(sc, R92C_BSSID + 0,
+ LE_READ_4(&ni->ni_bssid[0]));
+ urtwn_write_4(sc, R92C_BSSID + 4,
+
