From owner-freebsd-wireless@freebsd.org Sun Sep 20 21:00:34 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88497A0564A for ; Sun, 20 Sep 2015 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79F771489 for ; Sun, 20 Sep 2015 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8KL0YBY050408 for ; Sun, 20 Sep 2015 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201509202100.t8KL0YBY050408@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-wireless@FreeBSD.org Subject: Problem reports for freebsd-wireless@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 20 Sep 2015 21:00:34 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 21:00:34 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 154598 | [ath] Atheros 5424/2424 can't connect to WPA netw Open | 163312 | [panic] [ath] kernel panic: page fault with ath0 Open | 166190 | [ath] TX hangs and frames stuck in TX queue Open | 166357 | [ath] 802.11n TX stall when the first frame in th Open | 169362 | [ath] AR5416: radar pulse PHY errors sometimes in 5 problems total for which you should take action. From owner-freebsd-wireless@freebsd.org Mon Sep 21 06:20:40 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0903A05E7A for ; Mon, 21 Sep 2015 06:20:40 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E018127D; Mon, 21 Sep 2015 06:20:40 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8L6IUXQ084234; Mon, 21 Sep 2015 01:18:31 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-179-24-154.austin.res.rr.com [72.179.24.154]) by mail.shrew.net (Postfix) with ESMTPSA id F195C18BA77; Mon, 21 Sep 2015 01:18:19 -0500 (CDT) Subject: Re: urtwn and hostap To: Adrian Chadd References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> <55FAEA82.3060602@shrew.net> Cc: Kevin Lo , "freebsd-wireless@freebsd.org" From: Matthew Grooms Message-ID: <55FFA1B9.8040005@shrew.net> Date: Mon, 21 Sep 2015 01:20:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------040409030903030408010304" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 21 Sep 2015 01:18:31 -0500 (CDT) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 06:20:41 -0000 This is a multi-part message in MIME format. --------------040409030903030408010304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 20000 >>>>> >>>>> 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:0xffffffff80a01105 >>>>>>>>>> stack pointer = 0x28:0xfffffe0092fe86f0 >>>>>>>>>> frame pointer = 0x28:0xfffffe0092fe8740 >>>>>>>>>> code segment = base 0x0, limit 0xfffff, 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 0xffffff800512814d0 >>>>>>>>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame >>>>>>>>>> 0xfffffe0092fe8740 >>>>>>>>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >>>>>>>>>> 0xfffffe0092fe8780 >>>>>>>>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >>>>>>>>>> 0xfffffe0092fe87a0 >>>>>>>>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >>>>>>>>>> 0xfffffe0092fe87d0 >>>>>>>>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame >>>>>>>>>> 0xfffffe0092fe87f0 >>>>>>>>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >>>>>>>>>> 0xfffffe0092fe8840 >>>>>>>>>> if_clone_destroy() at if_clone_destroy()0x8e/frame >>>>>>>>>> 0xfffffe0092fe8860 >>>>>>>>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >>>>>>>>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >>>>>>>>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >>>>>>>>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >>>>>>>>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >>>>>>>>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >>>>>>>>>> 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-unsubscribe@freebsd.org" >>>>>>>>> _______________________________________________ >>>>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>>>> To unsubscribe, send any mail to >>>>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>>>> _______________________________________________ >>>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>>> To unsubscribe, send any mail to >>>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>>> _______________________________________________ >>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>> To unsubscribe, send any mail to >>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>> Index: sys/dev/usb/wlan/if_urtwn.c >>>>> =================================================================== >>>>> --- sys/dev/usb/wlan/if_urtwn.c (revision 287342) >>>>> +++ sys/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 void urtwn_txeof(struct usb_xfer *, struct urtwn_data >>>>> *); >>>>> +int urtwn_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,39 @@ >>>>> 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; >>>>> + >>>>> + ieee80211_ref_node(ni); >>>>> + m = ieee80211_beacon_alloc(ni, &URTWN_VAP(vap)->bo); >>>>> + >>>>> + bf = urtwn_getbuf(sc); >>>>> + if (bf == NULL) { >>>>> + ieee80211_free_node(ni); >>>>> + m_freem(m); >>>>> + return (ENOBUFS); >>>>> + } >>>>> + >>>>> + if (urtwn_tx_start(sc, ni, m, bf) != 0) { >>>>> + ieee80211_free_node(ni); >>>>> + 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 +1505,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 +1593,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, >>>>> + LE_READ_2(&ni->ni_bssid[4])); >>>>> >>>>> - if (ic->ic_curmode == IEEE80211_MODE_11B) >>>>> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); >>>>> - else /* 802.11b/g */ >>>>> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); >>>>> + if (ic->ic_curmode == IEEE80211_MODE_11B) >>>>> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, >>>>> 0); >>>>> + else /* 802.11b/g */ >>>>> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, >>>>> 3); >>>>> >>>>> - /* Enable Rx of data frames. */ >>>>> - urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >>>>> + /* Enable Rx of data frames. */ >>>>> + urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >>>>> >>>>> + /* Allow Rx from our BSSID only. */ >>>>> + urtwn_write_4(sc, R92C_RCR, urtwn_read_4(sc, >>>>> R92C_RCR) | >>>>> + R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >>>>> + >>>>> + /* 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); >>>>> + } >>>>> + >>>>> + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { >>>>> + /* Set media status to 'AP'. */ >>>>> + reg = urtwn_read_4(sc, R92C_CR); >>>>> + reg = RW(reg, R92C_CR_NETTYPE, >>>>> R92C_CR_NETTYPE_AP); >>>>> + 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 3rd or 4th bits are set to zero chip will >>>>> stop >>>>> + * repeating beacon after first transmission for >>>>> port0 >>>>> + * and port1 respectively. This will cause STAs to >>>>> + * disconnect after short period of time. >>>>> + */ >>>>> + reg = urtwn_read_1(sc, R92C_MBID_NUM); >>>>> + reg |= 0x8; >>>>> + reg |= 0x10; >>>>> + urtwn_write_1(sc, R92C_MBID_NUM, reg); >>>>> + >>>>> + /* Invalidate cam entries */ >>>>> + urtwn_cam_init(sc); >>>>> + >>>>> + /* Set chan/bw */ >>>>> + urtwn_set_chan(sc, ic->ic_curchan, NULL); >>>>> + >>>>> + /* Push beacon frame into the chip */ >>>>> + error = urtwn_txbcn(vap, ni); >>>>> + if (error != 0) >>>>> + printf("%s: unable to push beacon into >>>>> the" >>>>> + " chip\n", >>>>> device_get_nameunit(sc->sc_dev)); >>>>> + } >>>>> + >>>>> /* Flush all AC queues. */ >>>>> urtwn_write_1(sc, R92C_TXPAUSE, 0); >>>>> >>>>> @@ -1576,11 +1661,6 @@ >>>>> /* 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) | >>>>> - R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >>>>> - >>>>> /* Enable TSF synchronization. */ >>>>> urtwn_tsf_sync_enable(sc); >>>>> >>>>> @@ -1754,7 +1834,7 @@ >>>>> struct ieee80211vap *vap = ni->ni_vap; >>>>> struct usb_xfer *xfer; >>>>> struct r92c_tx_desc *txd; >>>>> - uint8_t raid, type; >>>>> + uint8_t raid, type, subtype; >>>>> uint16_t sum; >>>>> int i, hasqos, xferlen; >>>>> struct usb_xfer *urtwn_pipes[4] = { >>>>> @@ -1771,6 +1851,7 @@ >>>>> */ >>>>> wh = mtod(m0, struct ieee80211_frame *); >>>>> type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; >>>>> + subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; >>>>> >>>>> if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) { >>>>> k = ieee80211_crypto_encap(ni, m0); >>>>> @@ -1819,7 +1900,7 @@ >>>>> if (sc->chip & URTWN_CHIP_88E) { >>>>> txd->txdw1 |= htole32( >>>>> SM(R88E_TXDW1_MACID, URTWN_MACID_BSS) | >>>>> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_BE) | >>>>> + SM(R92C_TXDW1_QSEL, R88E_TXDW1_QSEL_BE) | >>>>> SM(R92C_TXDW1_RAID, raid)); >>>>> txd->txdw2 |= htole32(R88E_TXDW2_AGGBK); >>>>> } else { >>>>> @@ -1843,9 +1924,20 @@ >>>>> /* Send data at OFDM54. */ >>>>> txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); >>>>> } else { >>>>> + /* >>>>> + * If beacon frame is pushed into wrong queue, the chip >>>>> won't >>>>> + * start repeating it. >>>>> + */ >>>>> + if (subtype == IEEE80211_FC0_SUBTYPE_BEACON && >>>>> + sc->chip & URTWN_CHIP_88E) >>>>> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >>>>> + R88E_TXDW1_QSEL_MGNT)); >>>>> + else >>>>> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >>>>> + R92C_TXDW1_QSEL_MGNT)); >>>>> + >>>>> txd->txdw1 |= htole32( >>>>> SM(R92C_TXDW1_MACID, 0) | >>>>> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_MGNT) | >>>>> SM(R92C_TXDW1_RAID, R92C_RAID_11B)); >>>>> >>>>> /* Force CCK1. */ >>>>> Index: sys/dev/usb/wlan/if_urtwnreg.h >>>>> =================================================================== >>>>> --- sys/dev/usb/wlan/if_urtwnreg.h (revision 287342) >>>>> +++ sys/dev/usb/wlan/if_urtwnreg.h (working copy) >>>>> @@ -1019,7 +1019,9 @@ >>>>> #define R92C_TXDW1_QSEL_M 0x00001f00 >>>>> #define R92C_TXDW1_QSEL_S 8 >>>>> #define R92C_TXDW1_QSEL_BE 0x00 >>>>> +#define R88E_TXDW1_QSEL_BE 0x03 >>>>> #define R92C_TXDW1_QSEL_MGNT 0x12 >>>>> +#define R88E_TXDW1_QSEL_MGNT 0x10 >>>>> #define R92C_TXDW1_RAID_M 0x000f0000 >>>>> #define R92C_TXDW1_RAID_S 16 >>>>> #define R92C_TXDW1_CIPHER_M 0x00c00000 >>>>> _______________________________________________ >>>>> freebsd-wireless@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>> To unsubscribe, send any mail to >>>>> "freebsd-wireless-unsubscribe@freebsd.org" >> --------------040409030903030408010304 Content-Type: text/plain; charset=UTF-8; name="urtwn-hostap.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="urtwn-hostap.diff" SW5kZXg6IHN5cy9kZXYvdXNiL3dsYW4vaWZfdXJ0d24uYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvZGV2L3VzYi93bGFuL2lmX3VydHduLmMJKHJldmlzaW9uIDI4NzM0MikKKysrIHN5cy9k ZXYvdXNiL3dsYW4vaWZfdXJ0d24uYwkod29ya2luZyBjb3B5KQpAQCAtNDMwLDYgKzQzMCw3 IEBACiAJaWMtPmljX2NhcHMgPQogCQkgIElFRUU4MDIxMV9DX1NUQQkJLyogc3RhdGlvbiBt b2RlICovCiAJCXwgSUVFRTgwMjExX0NfTU9OSVRPUgkJLyogbW9uaXRvciBtb2RlICovCisJ CXwgSUVFRTgwMjExX0NfSE9TVEFQCQkvKiBob3N0YXAgbW9kZSBzdXBwb3J0ZWQgKi8KIAkJ fCBJRUVFODAyMTFfQ19TSFBSRUFNQkxFCS8qIHNob3J0IHByZWFtYmxlIHN1cHBvcnRlZCAq LwogCQl8IElFRUU4MDIxMV9DX1NIU0xPVAkJLyogc2hvcnQgc2xvdCB0aW1lIHN1cHBvcnRl ZCAqLwogCQl8IElFRUU4MDIxMV9DX0JHU0NBTgkJLyogY2FwYWJsZSBvZiBiZyBzY2Fubmlu ZyAqLwpAQCAtMTQ2Niw2ICsxNDY3LDcgQEAKIAlzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5p OwogCWVudW0gaWVlZTgwMjExX3N0YXRlIG9zdGF0ZTsKIAl1aW50MzJfdCByZWc7CisJdV9p bnQ4X3QgbXNyOwogCiAJb3N0YXRlID0gdmFwLT5pdl9zdGF0ZTsKIAlEUFJJTlRGKCIlcyAt PiAlc1xuIiwgaWVlZTgwMjExX3N0YXRlX25hbWVbb3N0YXRlXSwKQEAgLTE1NDcsNiArMTU0 OSwxNiBAQAogCQkJLyogRW5hYmxlIFJ4IG9mIGRhdGEgZnJhbWVzLiAqLwogCQkJdXJ0d25f d3JpdGVfMihzYywgUjkyQ19SWEZMVE1BUDIsIDB4ZmZmZik7CiAKKwkJCS8qIEFsbG93IFJ4 IGZyb20gYW55IEJTU0lELiAqLworCQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19SQ1IsCisJ CQkgICAgdXJ0d25fcmVhZF80KHNjLCBSOTJDX1JDUikgJgorCQkJICAgIH4oUjkyQ19SQ1Jf Q0JTU0lEX0RBVEEgfCBSOTJDX1JDUl9DQlNTSURfQkNOKSk7CisKKwkJCS8qIEFjY2VwdCBS eCBkYXRhL2NvbnRyb2wvbWFuYWdlbWVudCBmcmFtZXMgKi8KKwkJCXVydHduX3dyaXRlXzQo c2MsIFI5MkNfUkNSLAorCQkJICAgIHVydHduX3JlYWRfNChzYywgUjkyQ19SQ1IpIHwKKwkJ CSAgICBSOTJDX1JDUl9BREYgfCBSOTJDX1JDUl9BQ0YgfCBSOTJDX1JDUl9BTUYpOworCiAJ CQkvKiBUdXJuIGxpbmsgTEVEIG9uLiAqLwogCQkJdXJ0d25fc2V0X2xlZChzYywgVVJUV05f TEVEX0xJTkssIDEpOwogCQkJYnJlYWs7CkBAIC0xNTUzLDYgKzE1NjUsNyBAQAogCQl9CiAK IAkJbmkgPSBpZWVlODAyMTFfcmVmX25vZGUodmFwLT5pdl9ic3MpOworCiAJCS8qIFNldCBt ZWRpYSBzdGF0dXMgdG8gJ0Fzc29jaWF0ZWQnLiAqLwogCQlyZWcgPSB1cnR3bl9yZWFkXzQo c2MsIFI5MkNfQ1IpOwogCQlyZWcgPSBSVyhyZWcsIFI5MkNfQ1JfTkVUVFlQRSwgUjkyQ19D Ul9ORVRUWVBFX0lORlJBKTsKQEAgLTE1NzYsMTQgKzE1ODksNDggQEAKIAkJLyogU2V0IGJl YWNvbiBpbnRlcnZhbC4gKi8KIAkJdXJ0d25fd3JpdGVfMihzYywgUjkyQ19CQ05fSU5URVJW QUwsIG5pLT5uaV9pbnR2YWwpOwogCi0JCS8qIEFsbG93IFJ4IGZyb20gb3VyIEJTU0lEIG9u bHkuICovCi0JCXVydHduX3dyaXRlXzQoc2MsIFI5MkNfUkNSLAotCQkgICAgdXJ0d25fcmVh ZF80KHNjLCBSOTJDX1JDUikgfAotCQkgICAgUjkyQ19SQ1JfQ0JTU0lEX0RBVEEgfCBSOTJD X1JDUl9DQlNTSURfQkNOKTsKKwkJLyogUmVhZCBjdXJyZW50IE1TUiB2YWx1ZSAqLworCQlt c3IgPSB1cnR3bl9yZWFkXzEoc2MsIFI5MkNfTVNSKTsKKwkJbXNyICY9IFI5MkNfTVNSX01B U0s7CiAKLQkJLyogRW5hYmxlIFRTRiBzeW5jaHJvbml6YXRpb24uICovCi0JCXVydHduX3Rz Zl9zeW5jX2VuYWJsZShzYyk7CisJCWlmICh2YXAtPml2X29wbW9kZSA9PSBJRUVFODAyMTFf TV9TVEEpIHsKKwkJCS8qIFNldCBzdGF0aW9uIG1vZGUgYmVhY29uIHBhcmFtZXRlciA/Pz8g Ki8KKwkJCXVydHduX3dyaXRlXzIoc2MsIFI5MkNfQkNOVENGRywgMHg2NjBmKTsKIAorCQkJ LyogQWxsb3cgUnggZnJvbSBvdXIgQlNTSUQgb25seS4gKi8KKwkJCXVydHduX3dyaXRlXzQo c2MsIFI5MkNfUkNSLAorCQkJICAgIHVydHduX3JlYWRfNChzYywgUjkyQ19SQ1IpIHwKKwkJ CSAgICAgIFI5MkNfUkNSX0NCU1NJRF9EQVRBIHwgUjkyQ19SQ1JfQ0JTU0lEX0JDTik7CisK KwkJCS8qIEVuYWJsZSBUU0Ygc3luY2hyb25pemF0aW9uLiAqLworCQkJdXJ0d25fdHNmX3N5 bmNfZW5hYmxlKHNjKTsKKworCQkJLyogU2V0IGFwcHJvcHJpYXRlIE1TUiBiaXRzICovCisJ CQltc3IgfD0gUjkyQ19NU1JfSU5GUkE7CisJCX0KKwkJaWYgKHZhcC0+aXZfb3Btb2RlID09 SUVFRTgwMjExX01fSE9TVEFQKSB7CisJCQkvKiBTZXQgQVAgbW9kZSBiZWFjb24gcGFyYW1l dGVyID8/PyAqLworCQkJdXJ0d25fd3JpdGVfMihzYywgUjkyQ19CQ05UQ0ZHLCAweDAwMGYp OworCisJCQkvKiBBbGxvdyBSeCBmcm9tIGFueSBCU1NJRC4gKi8KKwkJCXVydHduX3dyaXRl XzQoc2MsIFI5MkNfUkNSLAorCQkJICAgIHVydHduX3JlYWRfNChzYywgUjkyQ19SQ1IpICYK KwkJCSAgICB+KFI5MkNfUkNSX0NCU1NJRF9EQVRBIHwgUjkyQ19SQ1JfQ0JTU0lEX0JDTikp OworCisJCQkvKiBSZXNldCBUU0YgdGltZXIgdG8gemVyby4gKi8KKwkJCXJlZyA9IHVydHdu X3JlYWRfNChzYywgUjkyQ19UQ1IpOworCQkJcmVnICY9IH4weDAxOworCQkJdXJ0d25fd3Jp dGVfNChzYywgUjkyQ19UQ1IsIHJlZyk7CisJCQlyZWcgfD0gMHgwMTsKKwkJCXVydHduX3dy aXRlXzQoc2MsIFI5MkNfVENSLCByZWcpOworCisJCQkvKiBTZXQgYXBwcm9wcmlhdGUgTVNS IGJpdHMgKi8KKwkJCW1zciB8PSBSOTJDX01TUl9JTkZSQTsKKwkJfQorCisJCS8qIFdyaXRl IG1vZGlmaWVkIE1TUiB2YWx1ZSAqLworCQl1cnR3bl93cml0ZV8xKHNjLCBSOTJDX01TUiwg bXNyKTsKKwogCQl1cnR3bl93cml0ZV8xKHNjLCBSOTJDX1NJRlNfQ0NLICsgMSwgMTApOwog CQl1cnR3bl93cml0ZV8xKHNjLCBSOTJDX1NJRlNfT0ZETSArIDEsIDEwKTsKIAkJdXJ0d25f d3JpdGVfMShzYywgUjkyQ19TUEVDX1NJRlMgKyAxLCAxMCk7CkBAIC0xNTk3LDEzICsxNjQ0 LDE3IEBACiAJCQkgICAgbmktPm5pX3JhdGVzLnJzX3JhdGVzW25pLT5uaV9yYXRlcy5yc19u cmF0ZXMtMV07CiAJCWVsc2UKIAkJCXVydHduX3JhX2luaXQoc2MpOworCiAJCS8qIFR1cm4g bGluayBMRUQgb24uICovCiAJCXVydHduX3NldF9sZWQoc2MsIFVSVFdOX0xFRF9MSU5LLCAx KTsKIAotCQlzYy0+YXZnX3B3ZGIgPSAtMTsJLyogUmVzZXQgYXZlcmFnZSBSU1NJLiAqLwor CQkvKiBSZXNldCBhdmVyYWdlIFJTU0kuICovCisJCXNjLT5hdmdfcHdkYiA9IC0xOworCiAJ CS8qIFJlc2V0IHRlbXBlcmF0dXJlIGNhbGlicmF0aW9uIHN0YXRlIG1hY2hpbmUuICovCiAJ CXNjLT50aGNhbF9zdGF0ZSA9IDA7CiAJCXNjLT50aGNhbF9sY3RlbXAgPSAwOworCiAJCWll ZWU4MDIxMV9mcmVlX25vZGUobmkpOwogCQlicmVhazsKIAlkZWZhdWx0OgpJbmRleDogc3lz L2Rldi91c2Ivd2xhbi9pZl91cnR3bnJlZy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv dXNiL3dsYW4vaWZfdXJ0d25yZWcuaAkocmV2aXNpb24gMjg3MzQyKQorKysgc3lzL2Rldi91 c2Ivd2xhbi9pZl91cnR3bnJlZy5oCSh3b3JraW5nIGNvcHkpCkBAIC05Niw2ICs5Niw3IEBA CiAjZGVmaW5lIFI5MkNfU1lTX0NGRwkJCTB4MGYwCiAvKiBNQUMgR2VuZXJhbCBDb25maWd1 cmF0aW9uLiAqLwogI2RlZmluZSBSOTJDX0NSCQkJCTB4MTAwCisjZGVmaW5lIFI5MkNfTVNS CQkJMHgxMDIKICNkZWZpbmUgUjkyQ19QQlAJCQkweDEwNAogI2RlZmluZSBSOTJDX1RSWERN QV9DVFJMCQkweDEwYwogI2RlZmluZSBSOTJDX1RSWEZGX0JORFkJCQkweDExNApAQCAtMjAz LDYgKzIwNCw3IEBACiAvKiBXTUFDIENvbmZpZ3VyYXRpb24uICovCiAjZGVmaW5lIFI5MkNf QVBTRF9DVFJMCQkJMHg2MDAKICNkZWZpbmUgUjkyQ19CV09QTU9ERQkJCTB4NjAzCisjZGVm aW5lIFI5MkNfVENSCQkJMHg2MDQKICNkZWZpbmUgUjkyQ19SQ1IJCQkweDYwOAogI2RlZmlu ZSBSOTJDX1JYX0RSVklORk9fU1oJCTB4NjBmCiAjZGVmaW5lIFI5MkNfTUFDSUQJCQkweDYx MApAQCAtMzk0LDYgKzM5NiwxMyBAQAogI2RlZmluZSBSOTJDX0NSX05FVFRZUEVfSU5GUkEJ MgogI2RlZmluZSBSOTJDX0NSX05FVFRZUEVfQVAJMwogCisvKiBCaXRzIGZvciBSOTJDX01T Ui4gKi8KKyNkZWZpbmUgUjkyQ19NU1JfTk9MSU5LCQkweDAwCisjZGVmaW5lIFI5MkNfTVNS X0FESE9DCQkweDAxCisjZGVmaW5lIFI5MkNfTVNSX0lORlJBCQkweDAyCisjZGVmaW5lIFI5 MkNfTVNSX0FQCQkweDAzCisjZGVmaW5lIFI5MkNfTVNSX01BU0sJCSh+UjkyQ19NU1JfQVAp CisKIC8qIEJpdHMgZm9yIFI5MkNfUEJQLiAqLwogI2RlZmluZSBSOTJDX1BCUF9QU1JYX00J CTB4MGYKICNkZWZpbmUgUjkyQ19QQlBfUFNSWF9TCQkwCg== --------------040409030903030408010304-- From owner-freebsd-wireless@freebsd.org Mon Sep 21 12:19:31 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74FBBA06BE5 for ; Mon, 21 Sep 2015 12:19:31 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09E2C1E43; Mon, 21 Sep 2015 12:19:31 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by wicfx3 with SMTP id fx3so108381517wic.0; Mon, 21 Sep 2015 05:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=y5aLl8iJbI3E8UxoC0LimaoEjLDTakJ8pY1HAyfl7rI=; b=JoM+gTCZdTyPPiEALtTpRqt9SrwgLQ8/eW45d0vJJLvqZlM/LsDoEOJDoB5p4gkXoH 6nwZU4adfKx7JzgioSCm+tM3eJAe3708rQvQfjO1ww1ZGORbKmj5O+7ZcFhP8c8uqJGa kytgaX/aCCxtGH3ox5y2x6jafJcs5FU1Dh5t/oF3irpAaCn7tsmxJC7us7gJ5gJTYuR5 3CYugNmqAEx+yHuLLqtcR9HtUrRj0nzhT+BxxYY5btMsA9tanYLkMs34nBbSKyOy4kG5 VPeIJuG1lZi0GSianADa0ulezsSBoa/CZnIFL7oMXbHeTh1FT6NCMzZ3RkUWvPLBFrR2 oIVA== X-Received: by 10.194.176.6 with SMTP id ce6mr9440684wjc.101.1442837969336; Mon, 21 Sep 2015 05:19:29 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id kj5sm23836311wjb.19.2015.09.21.05.19.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Sep 2015 05:19:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Matthew Grooms" Subject: Re: urtwn and hostap References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> <55FAEA82.3060602@shrew.net> <55FFA1B9.8040005@shrew.net> Date: Mon, 21 Sep 2015 15:19:24 +0300 Cc: "Kevin Lo" , "Adrian Chadd" , freebsd-wireless@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <55FFA1B9.8040005@shrew.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 12:19:31 -0000 > 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). 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). > + /* Set appropriate MSR bits */ > + msr |= R92C_MSR_INFRA; Probably, R92C_MSR_AP should be used here instead. > Thanks again, > > -Matthew From owner-freebsd-wireless@freebsd.org Mon Sep 21 14:06:22 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEB8BA06E3E for ; Mon, 21 Sep 2015 14:06:22 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72FDA14EC; Mon, 21 Sep 2015 14:06:22 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8LE4IH2088064; Mon, 21 Sep 2015 09:04:18 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-179-24-154.austin.res.rr.com [72.179.24.154]) by mail.shrew.net (Postfix) with ESMTPSA id D2EEA18BEBA; Mon, 21 Sep 2015 09:04:07 -0500 (CDT) Subject: Re: urtwn and hostap To: Andriy Voskoboinyk References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> <55FAEA82.3060602@shrew.net> <55FFA1B9.8040005@shrew.net> Cc: Kevin Lo , Adrian Chadd , freebsd-wireless@freebsd.org From: Matthew Grooms Message-ID: <56000EE5.30209@shrew.net> Date: Mon, 21 Sep 2015 09:06:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 21 Sep 2015 09:04:18 -0500 (CDT) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 14:06:23 -0000 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 From owner-freebsd-wireless@freebsd.org Tue Sep 22 00:08:45 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52EFAA067B3 for ; Tue, 22 Sep 2015 00:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F87A120E for ; Tue, 22 Sep 2015 00:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8M08jvr063124 for ; Tue, 22 Sep 2015 00:08:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Tue, 22 Sep 2015 00:08:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 00:08:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 --- Comment #6 from Tony Narlock --- (In reply to Kevin Lo from comment #5) Sorry for the late response, I meant to get back to this during the weekend. I am reading FreeBSD Device Drivers, TDAIOTFOS, https://wiki.freebsd.org/WiFi, https://wiki.freebsd.org/WifiTxNotes, https://wiki.freebsd.org/WiFiDebugging and have an Thinkpad x230 with this card. I'm looking at if_urtwn.c. What other places do you think would be helpful to look at? I'm wondering if_urtwn.c may not be such a good example since it has USB everywhere. It may be too tall of an order to port something like this over by myself. > the harder part would be maintaining rtwn(4) stability and performance. What would that entail? Is it looking at coredumps if the kernel panics, running it on a machine until certain conditions popup, finding where in the code it's happening, trying to tweak it, recompiling, kldunload, kldload? Looking over tickets for behavior for the driver and trying to ask for more info to recreate it? Do we have an irc channel for freebsd-wireless? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Tue Sep 22 21:27:35 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38885A064EE for ; Tue, 22 Sep 2015 21:27:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 251251848 for ; Tue, 22 Sep 2015 21:27:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8MLRZDm029813 for ; Tue, 22 Sep 2015 21:27:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203271] Wi-Fi no longer driven on some hardware with 11.0-CURRENT Date: Tue, 22 Sep 2015 21:27:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: grahamperrin@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 21:27:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 Bug ID: 203271 Summary: Wi-Fi no longer driven on some hardware with 11.0-CURRENT Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: grahamperrin@gmail.com Originally reported as https://bugs.pcbsd.org/issues/11598 then I was advised that the problem is not specific to PC-BSD. Affected hardware includes Toshiba Satellite Pro C50-A-1E6 (part PSCG7E-02D042EN). https://forums.pcbsd.org/thread-20234-post-111879.html#pid111879 notes that a change of branch, down to 10.2-RELEASE, allowed all affected computers to recognise the Wi-Fi hardware. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Tue Sep 22 21:32:05 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85FE8A06734 for ; Tue, 22 Sep 2015 21:32:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C5691AF6 for ; Tue, 22 Sep 2015 21:32:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8MLW5UL040750 for ; Tue, 22 Sep 2015 21:32:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203271] Wi-Fi no longer driven on some hardware with 11.0-CURRENT Date: Tue, 22 Sep 2015 21:32:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 21:32:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #1 from Adrian Chadd --- Hi, I need more information than this. Can you post more of the kernel panic? Can you get a kernel corefile or the dumpfile in /var/crash/XXX.core.txt (the text file!) with all the relevant information? Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Wed Sep 23 00:46:35 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B42BA067A3 for ; Wed, 23 Sep 2015 00:46:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87B181DD7 for ; Wed, 23 Sep 2015 00:46:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8N0kZYx088862 for ; Wed, 23 Sep 2015 00:46:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203271] Wi-Fi no longer driven on some hardware with 11.0-CURRENT Date: Wed, 23 Sep 2015 00:46:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: grahamperrin@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 00:46:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 --- Comment #2 from Graham Perrin --- No kernel panic. The OS simply behaves as if there's no Wi-Fi hardware. It'll be a few hours before I can regain access to any of the affected Toshiba notebooks and then change branch up to 11.0-CURRENTSEPT2015. Will it be useful to get PC-BSD diagnostic files before and after the change of branch? Any other hints for before and after the change? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Wed Sep 23 23:41:52 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E60BA07058 for ; Wed, 23 Sep 2015 23:41:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A65812AD for ; Wed, 23 Sep 2015 23:41:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8NNfqan053101 for ; Wed, 23 Sep 2015 23:41:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203271] Wi-Fi no longer driven on some hardware with 11.0-CURRENT Date: Wed, 23 Sep 2015 23:41:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 23:41:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #3 from Andrey V. Elsukov --- Do you see your lost device in the output of sysctl net.wlan.devices? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Thu Sep 24 02:42:16 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6C6FA07D4A for ; Thu, 24 Sep 2015 02:42:15 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 960AC1DBC; Thu, 24 Sep 2015 02:42:15 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8O2e6F7010412; Wed, 23 Sep 2015 21:40:06 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-179-24-154.austin.res.rr.com [72.179.24.154]) by mail.shrew.net (Postfix) with ESMTPSA id 59C8418A6DA; Wed, 23 Sep 2015 21:39:55 -0500 (CDT) Subject: Re: urtwn and hostap To: freebsd-wireless@freebsd.org References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> <55FAEA82.3060602@shrew.net> <55FFA1B9.8040005@shrew.net> <56000EE5.30209@shrew.net> From: Matthew Grooms Cc: Kevin Lo , Adrian Chadd Message-ID: <5603630C.9020403@shrew.net> Date: Wed, 23 Sep 2015 21:42:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56000EE5.30209@shrew.net> Content-Type: multipart/mixed; boundary="------------070101090707040604050707" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 23 Sep 2015 21:40:06 -0500 (CDT) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 02:42:16 -0000 This is a multi-part message in MIME format. --------------070101090707040604050707 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 --------------070101090707040604050707 Content-Type: text/plain; charset=UTF-8; name="urtwn-hostap-v2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="urtwn-hostap-v2.diff" 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, 0xffff); + /* 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) | - R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); + /* Read current MSR value */ + msr = urtwn_read_1(sc, R92C_MSR); + msr &= R92C_MSR_MASK; - /* Enable TSF synchronization. */ - urtwn_tsf_sync_enable(sc); + if (vap->iv_opmode == IEEE80211_M_STA) { + /* Set station mode beacon parameter ??? */ + urtwn_write_2(sc, R92C_BCNTCFG, 0x660f); + /* Allow Rx from our BSSID only. */ + urtwn_write_4(sc, R92C_RCR, + urtwn_read_4(sc, R92C_RCR) | + R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); + + /* Enable TSF synchronization. */ + urtwn_tsf_sync_enable(sc); + + /* Set appropriate MSR bits */ + msr |= R92C_MSR_INFRA; + } + if (vap->iv_opmode ==IEEE80211_M_HOSTAP) { + /* Set AP mode beacon parameter ??? */ + urtwn_write_2(sc, R92C_BCNTCFG, 0x000f); + + /* Allow Rx from any BSSID. */ + urtwn_write_4(sc, R92C_RCR, + urtwn_read_4(sc, R92C_RCR) & + ~R92C_RCR_CBSSID_DATA); + + /* Reset TSF timer to zero. */ + reg = urtwn_read_4(sc, R92C_TCR); + reg &= ~0x01; + urtwn_write_4(sc, R92C_TCR, reg); + reg |= 0x01; + urtwn_write_4(sc, R92C_TCR, reg); + + /* Set appropriate MSR bits */ + msr |= R92C_MSR_AP; + } + + /* Write modified MSR value */ + urtwn_write_1(sc, R92C_MSR, msr); + urtwn_write_1(sc, R92C_SIFS_CCK + 1, 10); urtwn_write_1(sc, R92C_SIFS_OFDM + 1, 10); urtwn_write_1(sc, R92C_SPEC_SIFS + 1, 10); @@ -1597,13 +1644,17 @@ ni->ni_rates.rs_rates[ni->ni_rates.rs_nrates-1]; else urtwn_ra_init(sc); + /* Turn link LED on. */ urtwn_set_led(sc, URTWN_LED_LINK, 1); - sc->avg_pwdb = -1; /* Reset average RSSI. */ + /* Reset average RSSI. */ + sc->avg_pwdb = -1; + /* Reset temperature calibration state machine. */ sc->thcal_state = 0; sc->thcal_lctemp = 0; + ieee80211_free_node(ni); break; default: Index: sys/dev/usb/wlan/if_urtwnreg.h =================================================================== --- sys/dev/usb/wlan/if_urtwnreg.h (revision 287980) +++ sys/dev/usb/wlan/if_urtwnreg.h (working copy) @@ -96,6 +96,7 @@ #define R92C_SYS_CFG 0x0f0 /* MAC General Configuration. */ #define R92C_CR 0x100 +#define R92C_MSR 0x102 #define R92C_PBP 0x104 #define R92C_TRXDMA_CTRL 0x10c #define R92C_TRXFF_BNDY 0x114 @@ -203,6 +204,7 @@ /* WMAC Configuration. */ #define R92C_APSD_CTRL 0x600 #define R92C_BWOPMODE 0x603 +#define R92C_TCR 0x604 #define R92C_RCR 0x608 #define R92C_RX_DRVINFO_SZ 0x60f #define R92C_MACID 0x610 @@ -394,6 +396,13 @@ #define R92C_CR_NETTYPE_INFRA 2 #define R92C_CR_NETTYPE_AP 3 +/* Bits for R92C_MSR. */ +#define R92C_MSR_NOLINK 0x00 +#define R92C_MSR_ADHOC 0x01 +#define R92C_MSR_INFRA 0x02 +#define R92C_MSR_AP 0x03 +#define R92C_MSR_MASK (~R92C_MSR_AP) + /* Bits for R92C_PBP. */ #define R92C_PBP_PSRX_M 0x0f #define R92C_PBP_PSRX_S 0 --------------070101090707040604050707-- From owner-freebsd-wireless@freebsd.org Fri Sep 25 07:49:47 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12C1AA065F3 for ; Fri, 25 Sep 2015 07:49:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0B181BF6 for ; Fri, 25 Sep 2015 07:49:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbkq10 with SMTP id kq10so4641907igb.0 for ; Fri, 25 Sep 2015 00:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=GvacRj4+txePoaC3M1IvuTJtdrhUxRiEMfhVF9Ia0Ok=; b=jtVHy7JjOCbdnlRrqLtsTrvWUxAvPiI0qzs9uiJCVT1olEMEPd5iCr0tPUw7l58QB5 nnGtJty67qLxZLrUgMDIO+yj59Q+ljfHE4JgeFUfHa4xd1PUgTNcc/q09TLtyjKL4f0Z PC4zMcAqi12aGtBUGzrC62jD/8xEJv10BhfX5gAFt6mL1+DR51WmmTOnHUyIUcYklSp6 7znyPRm/S28kD50Hkv3f0StLuRtFhA90p5PHV/esPB0WSLaGGvMTrxe1fhTHJHDehEeZ dhIxD1zWBtBXSZvlaoU7TA7yj3H6IjFmFAUxnN9kmGP9tiuyH2ED+Ua/aYmzIhcvCp09 7JGA== MIME-Version: 1.0 X-Received: by 10.50.60.3 with SMTP id d3mr1183665igr.37.1443167386267; Fri, 25 Sep 2015 00:49:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Fri, 25 Sep 2015 00:49:46 -0700 (PDT) Date: Fri, 25 Sep 2015 00:49:46 -0700 X-Google-Sender-Auth: uaYQyYAjmIH_pfmVrXo2z7n70rw Message-ID: Subject: testing required: AR9170 support From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 07:49:47 -0000 hi! i finally finished (re-did!) the AR9170 support. It's a ported driver from OpenBSD. it's in https://github.com/erikarn/otus/ . The build installs both the newer carl9170 firmware for when I migrate to using that, and the firmware the openbsd driver supports (otus-init, otus-main.) It's .. very old firmware. I plan on migrating to more recent firmware once I get it to build and run. Meanwhile, 11bg seems quite stable. I don't have an 11a NIC so I can't test it and I won't be doing 11n support until I get updated firmware. It however is very much a draft 11n device, so it likely won't do all the shiny 11n things anyway. I'd appreciate some testing and feedback! Thanks! -adrian From owner-freebsd-wireless@freebsd.org Fri Sep 25 13:56:09 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E5DA08036 for ; Fri, 25 Sep 2015 13:56:09 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6C2D18E2; Fri, 25 Sep 2015 13:56:08 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by lacrr8 with SMTP id rr8so19966408lac.2; Fri, 25 Sep 2015 06:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=mar51ZWvm4iA3yfnFJVy7UT9hmfQWIN/8SJznGICL+0=; b=JCOk7Jzb1F9/Il8eIjO3KxAUlVcxVcMVauCLzOzfFc8XYC2UdoqHm53F3mu6eeEtTJ 9rKEOqLrzIOJzbSh4wqeLrYFajin3hPwHiM/1qK49S/4/JyChiv9Ofsn0rZurag2A3Rs ZK4hqLD5rKGx3KYRBPzQJeK79QyPx0esP4tET97V4AgGtW4AiypomBxZc6fVEHGHsiXd N5049Ywbl2/V9ViU38nbHFUqakRKX91Th3vsfpp5VoY8Tocyw2TZb85kro0D5yhjJGGB dUChsQyFpsUzdQrzLibC/A8Hrmd9Fs4uAXlUPklQAjHs/YZXf+GzGFBVkir85b3QRalQ w66g== X-Received: by 10.112.149.68 with SMTP id ty4mr1669318lbb.74.1443189366843; Fri, 25 Sep 2015 06:56:06 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id t129sm413628lfd.5.2015.09.25.06.56.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Sep 2015 06:56:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-wireless@freebsd.org Subject: Re: urtwn and hostap References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> <55FAEA82.3060602@shrew.net> <55FFA1B9.8040005@shrew.net> <56000EE5.30209@shrew.net> <5603630C.9020403@shrew.net> Date: Fri, 25 Sep 2015 16:56:03 +0300 Cc: "Matthew Grooms" , "Kevin Lo" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <5603630C.9020403@shrew.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 13:56:09 -0000 > 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 From owner-freebsd-wireless@freebsd.org Fri Sep 25 17:04:10 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE814A09386 for ; Fri, 25 Sep 2015 17:04:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAEFD1A9B for ; Fri, 25 Sep 2015 17:04:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8PH4AAe059221 for ; Fri, 25 Sep 2015 17:04:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203271] Wi-Fi no longer driven on some hardware with 11.0-CURRENT Date: Fri, 25 Sep 2015 17:04:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: grahamperrin@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:04:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 --- Comment #4 from Graham Perrin --- Thanks for the hint. I'm away from the Toshiba computers for a few days, out of town. Aiming to review this report in around a week. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Sat Sep 26 15:10:12 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4CA0A08A99 for ; Sat, 26 Sep 2015 15:10:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74F5993C for ; Sat, 26 Sep 2015 15:10:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioii196 with SMTP id i196so138072661ioi.3 for ; Sat, 26 Sep 2015 08:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=cwJ3uPRtJj0cVnmQy7RGISQ8o6K85RTftpmDA+eXjiE=; b=0rroh0WernfioZoBCkQZDfjHatif3PmbTVkyiQhAXc4DyG7Kw3ed2NVczvykpy/QB5 r0C+deIZsWBOhnYgjrSMF7amm9iK51hENWj+tYjxCwPVYq1gsRpJ0bKPvDSM7JZIUR1F OrEvA6fuA1E/6IpZrO3l3ctbbABBMvt2zIyP9x+0KEfpfSW2jt07PHfUuW4uJuFOfbim U1v1s1Km5pSNO0y/U6F109FuCUnDxcoLKaUPrSsU6jmwqpre9SJdgCIn8okiImoQYdGC Lf9B0K5WJ57CTKEjaqrSwj1rcJbU8bUXwFpiqMzzv+hUNR4eh87o0cjaSbnSay5C7wXg S4Kw== MIME-Version: 1.0 X-Received: by 10.107.35.78 with SMTP id j75mr10716852ioj.123.1443280211808; Sat, 26 Sep 2015 08:10:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Sat, 26 Sep 2015 08:10:11 -0700 (PDT) Date: Sat, 26 Sep 2015 08:10:11 -0700 X-Google-Sender-Auth: KiZCXrhOznj5zdtRy701AB4Od6k Message-ID: Subject: if_rsu now does 11n HT40 From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 15:10:12 -0000 Hi! Thanks to incessant nagging by Idwer on IRC, we dug into why HT40 wasn't working and figured it out. Please do update to -HEAD and try it out! -a From owner-freebsd-wireless@freebsd.org Sat Sep 26 17:30:47 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DE5AA0866E for ; Sat, 26 Sep 2015 17:30:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A844DB for ; Sat, 26 Sep 2015 17:30:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8QHUlPV033364 for ; Sat, 26 Sep 2015 17:30:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203271] Wi-Fi no longer driven on some hardware with 11.0-CURRENT Date: Sat, 26 Sep 2015 17:30:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 17:30:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203271 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Sat Sep 26 17:31:26 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AD53A08738 for ; Sat, 26 Sep 2015 17:31:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17CA226E for ; Sat, 26 Sep 2015 17:31:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8QHVPFO035193 for ; Sat, 26 Sep 2015 17:31:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203236] [patch] net80211: add unlisted information elements Date: Sat, 26 Sep 2015 17:31:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 17:31:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203236 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-wireless@FreeBSD.or | |g -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Sat Sep 26 22:26:04 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BF9AA0AFA3 for ; Sat, 26 Sep 2015 22:26:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC1C1356 for ; Sat, 26 Sep 2015 22:26:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh134 with SMTP id h134so142542808iof.0 for ; Sat, 26 Sep 2015 15:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=tV/jmATdM1O88OS+RlFaxUdVHSCNQSBzXIIqS0JzHYo=; b=SJJJ3SBqtJgImXtryUxEk1zmXhkcaCoaA3GFcrBa90S/AqoJF/4zapC+m3u5YCHxhH FmALgfDscxxNksjpSUe51QHd+ATH9Nu0eKv8IVS7CvasMIyAOpwFpPbPI47XZ9O1jcIf Isw3eGF1FI/Zy2CmJ+feApa/LotfEpZKlwfWluTIutQk39alzPpj8k02e+5dmE/SilCr 1yjKsPm95/nQ/v0V++l7J+rQs6gXUSbw9J/DirjQfmkoeNC/rxaB7kbhEXJdrpfqX380 nJgyUH23lIqfb/lKwUX28NNT9bME7gZABqzFMZZq4xu81Igd+/5O4S1hRKbsJ8eryvA/ S4HA== MIME-Version: 1.0 X-Received: by 10.107.46.228 with SMTP id u97mr11906823iou.165.1443306363776; Sat, 26 Sep 2015 15:26:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Sat, 26 Sep 2015 15:26:03 -0700 (PDT) Date: Sat, 26 Sep 2015 15:26:03 -0700 X-Google-Sender-Auth: wKI9rVHC5eDI2xhuVL2W8CxiI9w Message-ID: Subject: Heads-up: moving if_urtwn into sys/dev/urtwn/ From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 22:26:04 -0000 Hiya, Kevin and I have talked about what we'd like to do with urtwn. This includes new chipsets as well as PCIe attachment support. So I'm thinking of migrating the driver from sys/dev/usb/ into sys/dev/urtwn/ and having it contain multiple bus attachments. I'd also like to break the driver down into smaller HAL bite sizes to make it easier to add extra chipset support. I'd really like to add PCIe support as well as 5GHz NIC support. There are apparently also SDIO parts too that we may want to support. If people have a strong feeling either way then now's your time to voice your opinion/suggestion. Thanks! -adrian