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

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

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

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

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

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

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

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 > >

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

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

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

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 >

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

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

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

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