Re: Wifi throughput test issue (FreeBSD 8.2)
On Wed, Nov 30, 2011 at 13:37, Viet-Ha Pham wrote: > Hello, > > > I am doing some throughput measurement for Wifi network. I am using > jperf/iperf to generate traffic (at the transmitter) and measure the > throughput (at the receiver). The transmitter and receiver are running > FreeBSD 8.2, using CM9-GP as the Wifi NIC. We are testing AWGN channel. So, > the transmitter and receiver are connected by cables, txpower on both sides > is set lower than the max (ranging from 0 to 10), AWGN noise is injected in > the middle of the cable. > > We measure the maximum throughput at each transmission rate. Transmitter is a > STA, receiver is an AP. We fix the unicast rate at the transmitter to 54 Mbps > (using "ifconfig ... ucastrate" command). The packet size is set to 400 > Bytes, UDP protocol is used and the transmit bandwidth is set to 30 Mbps in > order to flood the transmission channel (to push it to its limit). At first, > at the receiver (AP) the measured throughput is about 12 Mbps. Then I fix the > unicast rate at the receiver (using ifconfig again) to 54 Mbps. The measured > throughput increases to 20 Mbps. I set the unicast rate at the receiver to > autoselect again, the throughput is still 20 Mbps. > > When I switch the rate at the receiver, there are multiple message displayed > on the screen of the transmitter: "wlan0: ieee80211_new_state_locked: pending > RUN -> AUTH transition lost". This message is repeated for many times (at > least 20). > > I repeated the test with all transmission rates, change the packet size and > still observe the same thing: a throughput improvement of about 30% is > observed when I switch the unicast rate at the receiver and the improvement > is still there when I switch the unicast rate back to autoselect. The same > thing is observed in modes a and g. The same thing is observed if the unicast > rate at the receiver is set different from the unicast rate at the > transmitter. > > > > I spent time to look at the kernel source codes but I did not find a solid > answer for this. Please help me to identify the problem and the answer. > > > My question is: > > 1. Why do I have that throughput improvement when I switch the rate like that? > 2. Is it a bug in the driver? I think so, the driver might ignore/do some fancy stuff with a fixed ucastrate. @Adrian, do you know if ath_rate_sample has some debug options in that regard? > 3. What does the error/infor message on the transmitter mean? It might mean a lot of things, you should probably enable additional debug options to get a clue about what's going on. Btw, do you also see that behavior on HEAD (or at least the latest 9.x release/rc)? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [urtw] Wifi link dying randomly. reboot required to reconnect.
On Mon, Dec 5, 2011 at 14:44, Chuck Burns wrote: > freebeast dumped core - see /var/crash/vmcore.0 > Sun Dec 4 14:58:49 CST 2011 > FreeBSD freebeast 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r228221: Sat > Dec 3 09:10:37 CST 2011 > toor@freebeast:/usr/obj/usr/src/sys/GENERIC amd64 > panic: > .. > #9 0x8092f692 in node_free (ni=0xff8003565000) > at ieee80211_ratectl.h:84 > #10 0x8071634b in urtw_free_data_list (sc=Variable "sc" is not > available. > ) > at /usr/src/sys/dev/usb/wlan/if_urtw.c:989 > #11 0x8071bf75 in urtw_detach (dev=0xfe0005b22a00) > at /usr/src/sys/dev/usb/wlan/if_urtw.c:957 > #12 0x80868d54 in device_detach (dev=0xfe0005b22a00) > at device_if.h:214 > #13 0x806df6a8 in usb_detach_device (udev=0xfe0005b19000, > iface_index=32 ' ', flag=Variable "flag" is not available. > ) at /usr/src/sys/dev/usb/usb_device.c:1062 > #14 0x806dffc4 in usb_unconfigure (udev=0xfe0005b19000, > flag=Variable "flag" is not available. ni/vap does no longer exist at that point because it has been free'd before. How about attached patch? -- Bernhard Index: sys/dev/usb/wlan/if_urtw.c === --- sys/dev/usb/wlan/if_urtw.c (revision 228275) +++ sys/dev/usb/wlan/if_urtw.c (working copy) @@ -939,11 +939,11 @@ urtw_detach(device_t dev) usbd_transfer_unsetup(sc->sc_xfer, (sc->sc_flags & URTW_RTL8187B) ? URTW_8187B_N_XFERS : URTW_8187L_N_XFERS); - ieee80211_ifdetach(ic); urtw_free_tx_data_list(sc); urtw_free_rx_data_list(sc); + ieee80211_ifdetach(ic); if_free(ifp); mtx_destroy(&sc->sc_mtx); ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [urtw] Random wireless crash / kernel panic
On Monday 20 February 2012 18:03:45 Adam Twardowski wrote: > I do still have the kernel and the crash dump. I'll try that fix tonight > to see how it goes. Unfortunately, the kernel doesn't usually crash, more > likely the wifi stops working and I am forced to reboot the machine to get > it working again. Building urtw(4) as module here helps a lot, kldunload/kldload is just so much faster than a reboot. :) I have a bunch of asorted fixes [1] for urtw(4) which needs some further testing, though I still wasn't able to fix the issue which made me look into this in the first place.. As a test case I force a disconnection from the AP side a few times, which will eventually result in a device timeout and the requirement to reload the module. I believe that one of those might actually address the panic you're seeing, though, it doesn't fix the device timeout. [1] http://techwires.net/~bschmidt/urtw/ -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig meshforward command bug
On Thursday 22 March 2012 16:59:44 Monthadar Al Jaberi wrote:
> Hi,
>
> I think this is a bug in ifconfig, sending val to kernel always
> results in zero. There are a couple of these, just want to hear from
> you guys if you think this is a bug too.
>
> --- a/sbin/ifconfig/ifieee80211.c
> +++ b/sbin/ifconfig/ifieee80211.c
> @@ -1879,13 +1879,19 @@ DECL_CMD_FUNC(set80211meshttl, val, d)
> static
> DECL_CMD_FUNC(set80211meshforward, val, d)
> {
> - set80211(s, IEEE80211_IOC_MESH_FWRD, atoi(val), 0, NULL);
> + set80211(s, IEEE80211_IOC_MESH_FWRD, d, 0, NULL);
Seems about right, those declared with DEF_CMD() should use d.
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig meshforward command bug
On Thursday 22 March 2012 19:56:21 Adrian Chadd wrote: > On 22 March 2012 11:28, Bernhard Schmidt wrote: > > > Seems about right, those declared with DEF_CMD() should use d. > > Shall I commit this? There are more of those which use d, someone should go over all of em. But otherwise, yes, that should be fixed. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig meshforward command bug
On Thursday 22 March 2012 19:56:57 Adrian Chadd wrote: > On 22 March 2012 11:56, Adrian Chadd wrote: > > On 22 March 2012 11:28, Bernhard Schmidt wrote: > > > >> Seems about right, those declared with DEF_CMD() should use d. > > > > Shall I commit this? > > .. a lot of these mesh functions use DECL_CMD_FUNC(), should they all > be using d? Take a look at the top of the file, just the once with DEF_CMD() where the parameter is included, those should use d. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig meshforward command bug
On Friday 23 March 2012 10:11:07 Monthadar Al Jaberi wrote:
> On Thu, Mar 22, 2012 at 10:23 PM, Adrian Chadd wrote:
> > I've fixed the one that Monthadar has submitted.
> >
> > Monthadar, would you mind reviewing the rest of the mesh commands and
> > see which others need fixing?
>
> from what I can see the bug is for flags that we can either turn on or
> off. Another one I found,
>
> static
> DECL_CMD_FUNC(set80211meshpeering, val, d)
> {
> - set80211(s, IEEE80211_IOC_MESH_AP, atoi(val), 0, NULL);
> + set80211(s, IEEE80211_IOC_MESH_AP, d, 0, NULL);
>
> I took a quick look and think this is last one
Correct, and committed, thanks!
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: > On Thu, 3 May 2012 18:53:52 +0200 > Bernhard Schmidt wrote: > > > Hi folks, > > > > As some of you might know there has been some work going on porting > > support for new Ralink chipsets from OpenBSD. Several different > > drivers where floating around but nothing seemed to be decent enough > > to be committed. ray@ and I had been working on cleaning up one of > > those to get it into a good enough shape, but abandoned this approach > > as it resulted in more work than starting from scratch. > > > > So, attached diff [1] is a from-scratch effort to port over support > > for the new chipsets. It doesn't contain fancy stuff like 802.11n > > support as of yet (this will be worked one once the legacy stuff is > > in HEAD), nonetheless it showed pretty decent performance during the > > basic sta/adhoc/hostap tests I've done. > > > > I'd appreciate testing and feedback ;) > > > at 1st I would say 'Thank You' for all people who working on this :) > > patch, make, make install, kldload: > http://tiger.ipfw.ru/files/rt2860_3090.txt > > this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 > from time to time on messages: > May 5 10:32:47 laptop kernel: ral0: device timeout > May 5 10:37:49 laptop kernel: ral0: device timeout > May 5 10:42:50 laptop kernel: ral0: device timeout That interval is fishy.. can you try do disable bgscan? ifconfig wlan0 -bgscan > LED... is just glowing, rarely blinks. With patch from Alexander (ray@) > it doesn't work > > [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . > FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% > 271MB 1.9MB/s 18:19 ETA > ^C > Killed by signal 2. > where 'tiger' is my desktop > > > > The diff requires HEAD due to the firmware being available only there, > > though, if there are enough requests, I might consider looking into > > getting it merged to 9. (Simply pulling sys/modules/ralfw/ and > > sys/contrib/dev/ral/ from HEAD might be enough I guess.) > > > > [1] http://techwires.net/~bschmidt/rt2860.diff > > > > > > -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote:
> On Thu, 3 May 2012 18:53:52 +0200
> Bernhard Schmidt wrote:
>
> > Hi folks,
> >
> > As some of you might know there has been some work going on porting
> > support for new Ralink chipsets from OpenBSD. Several different
> > drivers where floating around but nothing seemed to be decent enough
> > to be committed. ray@ and I had been working on cleaning up one of
> > those to get it into a good enough shape, but abandoned this approach
> > as it resulted in more work than starting from scratch.
> >
> > So, attached diff [1] is a from-scratch effort to port over support
> > for the new chipsets. It doesn't contain fancy stuff like 802.11n
> > support as of yet (this will be worked one once the legacy stuff is
> > in HEAD), nonetheless it showed pretty decent performance during the
> > basic sta/adhoc/hostap tests I've done.
> >
> > I'd appreciate testing and feedback ;)
> >
> at 1st I would say 'Thank You' for all people who working on this :)
>
> patch, make, make install, kldload:
> http://tiger.ipfw.ru/files/rt2860_3090.txt
>
> this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012
> from time to time on messages:
> May 5 10:32:47 laptop kernel: ral0: device timeout
> May 5 10:37:49 laptop kernel: ral0: device timeout
> May 5 10:42:50 laptop kernel: ral0: device timeout
>
> LED... is just glowing, rarely blinks. With patch from Alexander (ray@)
> it doesn't work
>
> [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso .
> FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11%
> 271MB 1.9MB/s 18:19 ETA
> ^C
> Killed by signal 2.
> where 'tiger' is my desktop
Please apply attached patch (also here [1]) on top of the first one,
it fixes channel switching for >= 3070 (called the wrong function,
doh..) as well as a bgscan issue.
[1] http://techwires.net/~bschmidt/rt2860_1.diff
--
Bernhard
Index: sys/dev/ral/rt2860.c
===
--- sys/dev/ral/rt2860.c (revision 234847)
+++ sys/dev/ral/rt2860.c (working copy)
@@ -1605,10 +1605,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
ieee80211_radiotap_tx(vap, m);
}
- if (hdrlen & 3)
- pad = 4 - (hdrlen & 3);
- else
- pad = 0;
+ pad = (hdrlen + 3) & ~3;
/* copy and trim 802.11 header */
memcpy(txwi + 1, wh, hdrlen);
@@ -1667,7 +1664,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
/* first segment is TXWI + 802.11 header */
txd = &ring->txd[ring->cur];
txd->sdp0 = htole32(data->paddr);
- txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen + pad);
+ txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + pad);
txd->flags = qsel;
/* setup payload segments */
@@ -1776,7 +1773,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
u_int hdrlen;
uint16_t dur;
uint8_t type, qsel, mcs, pid, tid, qid;
- int i, nsegs, ntxds, rate, ridx, error;
+ int i, nsegs, ntxds, pad, rate, ridx, error;
/* the data pool contains at least one element, pick the first */
data = SLIST_FIRST(&sc->data_pool);
@@ -1860,6 +1857,8 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
ieee80211_radiotap_tx(vap, m);
}
+ pad = (hdrlen + 3) & ~3;
+
/* copy and trim 802.11 header */
memcpy(txwi + 1, wh, hdrlen);
m_adj(m, hdrlen);
@@ -1917,7 +1916,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m,
/* first segment is TXWI + 802.11 header */
txd = &ring->txd[ring->cur];
txd->sdp0 = htole32(data->paddr);
- txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen);
+ txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + pad);
txd->flags = qsel;
/* setup payload segments */
@@ -2336,7 +2335,6 @@ rt2860_scan_start(struct ieee80211com *ic)
tmp & ~(RT2860_BCN_TX_EN | RT2860_TSF_TIMER_EN |
RT2860_TBTT_TIMER_EN));
rt2860_set_gp_timer(sc, 0);
- rt2860_set_bssid(sc, ifp->if_broadcastaddr);
}
static void
@@ -2346,10 +2344,10 @@ rt2860_scan_end(struct ieee80211com *ic)
struct rt2860_softc *sc = ifp->if_softc;
struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps);
- rt2860_enable_tsf_sync(sc);
- /* XXX keep local copy */
- rt2860_set_bssid(sc, vap->iv_bss->ni_bssid);
- rt2860_set_gp_timer(sc, 500);
+ if (vap->iv_state == IEEE80211_S_RUN) {
+ rt2860_enable_tsf_sync(sc);
+ rt2860_set_gp_timer(sc, 500);
+ }
}
static void
@@ -2359,7 +2357,7 @@ rt2860_set_channel(struct ieee80211com *ic)
struct rt2860_softc *sc = ifp->if_softc;
RAL_LOCK(sc);
- rt2860_set_chan(sc, ieee80211_chan2ieee(ic, ic->ic_curchan));
+ rt2860_switch_chan(sc, ic->ic_curchan);
RAL_UNLOCK(sc);
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 5, 2012 at 2:27 PM, Sergey V. Dyatko wrote: > On Sat, 5 May 2012 12:51:10 +0200 > Bernhard Schmidt wrote: >> Please apply attached patch (also here [1]) on top of the first one, >> it fixes channel switching for >= 3070 (called the wrong function, >> doh..) as well as a bgscan issue. >> >> [1] http://techwires.net/~bschmidt/rt2860_1.diff >> > > * patch applied without errors > * build/install - ok > > kldload and after ~5 minutes: > > May 5 15:01:20 laptop kernel: ral0: device timeout > May 5 15:06:12 laptop kernel: ral0: device timeout > > without bgscan I didn't see such messages ~30-40 min Ok great, so except bgscan you haven't seen any other issue yet? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support
On Sat, May 5, 2012 at 12:51 PM, Bernhard Schmidt wrote: > Please apply attached patch (also here [1]) on top of the first one, > it fixes channel switching for >= 3070 (called the wrong function, > doh..) as well as a bgscan issue. > > [1] http://techwires.net/~bschmidt/rt2860_1.diff And another update [1] on top of the other 2 patches. * fix TX DMA, a wrong dmat has been used * add some more PCI IDs * disable debugging output by default * disable bgscan until it's sorted out * a printf is now hidden behind bootverbose So far it looks quite good, no open issues at the moment, keep on testing! ;) If nothing new comes up within the next few days I intend to commit this by the end of the week or something. [1] http://techwires.net/~bschmidt/rt2860_2.diff -- Bernhard rt2860_2.diff Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Plea for bwn maintenance.
On Tue, May 8, 2012 at 7:30 PM, Adam Vande More wrote: > .. > > If someone would like to tackle this, I can provide access to the hardware > or I will donate the card to the person. Whatever works. I'll get into bwn(4)/bwi(4) and probably also the newer cards, which require yet another driver/bus, once the ral(4) stuff is sorted out. >From my currently limited knowledge about the Broadcom mess, bwi(4) should also use siba(4), for the supported cores that is. That at least would fix the issue that cards which are better of with bwn(4) get attached to bwi(4). From a quick glance at the Linux driver, this seems to be the way to go. There seem to the following core revisions available 2 and 4 which are for bwi(4) and 5, 6, 7, 9-13, 15 and 16 for bwn(4). Does anyone know if there is a map for the revision/PCI ID/device name relation available? The name bcm4318 itself is a bit misleading imho. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: iwn adhoc mode
On Fri, Jul 27, 2012 at 11:25 AM, Andreas Nilsson wrote: > and when I try to setup the connection manually with ifconfig I get > ifconfig: SIOCIFCREATE2: Operation not supported > and from reading older postings it seems that iwn has a problem with ad-hoc > mode. Indeed, adding Adhoc/IBSS support to iwn(4) is *still* on my TODO list. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: iwn adhoc mode
On Wed, Aug 1, 2012 at 10:17 AM, Andreas Nilsson wrote: > > > On Wed, Aug 1, 2012 at 10:12 AM, Bernhard Schmidt > wrote: >> >> On Fri, Jul 27, 2012 at 11:25 AM, Andreas Nilsson >> wrote: >> > and when I try to setup the connection manually with ifconfig I get >> > ifconfig: SIOCIFCREATE2: Operation not supported >> > and from reading older postings it seems that iwn has a problem with >> > ad-hoc >> > mode. >> >> Indeed, adding Adhoc/IBSS support to iwn(4) is *still* on my TODO list. >> >> -- >> Bernhard > > > Thanks for clarifying. Do you have an ETA for it as well? ;) Not really.. not soon I guess. > In the meantime maybe the IWN(4) should not claim support for adhoc, or is > it supported on some cards and not on others? There was some basic, half-working, support before I've touched the code, back when only 4965 was supported. I guess the manpage needs indeed some updating. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: wpa_supplicant wpa peap gtc connection - gtc failing?
On Fri, Aug 17, 2012 at 3:40 AM, Da Rock wrote: > I'm trying to access a uni network using wpa-peap with GTC authentication, > and no matter what I've tried it fails. > > I've come across the same error in most of my logs: "phase2 request: NAK > type 6". I haven't tried GTC myself, though, I know that wpa_supplicant by default is built *without* support for that. You didn't mention it, so I assume that might be a valid pointer. Just adding WPA_SUPPLICANT_CFLAGS=-DEAP_GTC to /etc/make.conf and rebuilding/reinstalling /usr/src/usr.sbin/wpa should get you going. HTH -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: wpa_supplicant wpa peap gtc connection - gtc failing?
On Saturday 18 August 2012 13:47:29 Da Rock wrote: > On 08/18/12 13:32, Adrian Chadd wrote: > > Is there any reason we don't build with that option? > You know, I was wondering that myself but I wasn't exactly sure whether > to ask or not :) Historical reasons I guess, our config matches the default wpa_supplicant config. I don't see any technical reason not to enable that and bunch of other exotic stuff. Though, as you've already noticed, one can count the number of user who benefit from such a change on one hand.. ;) Not sure it's worth the effort, though, if someone wants to do the work, fine with me. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: wpa_supplicant wpa peap gtc connection - gtc failing?
On Mon, Aug 20, 2012 at 10:27 AM, Da Rock wrote: > On 08/19/12 03:23, Bernhard Schmidt wrote: >> >> On Saturday 18 August 2012 13:47:29 Da Rock wrote: >>> >>> On 08/18/12 13:32, Adrian Chadd wrote: >>>> >>>> Is there any reason we don't build with that option? >>> >>> You know, I was wondering that myself but I wasn't exactly sure whether >>> to ask or not :) >> >> Historical reasons I guess, our config matches the default >> wpa_supplicant config. I don't see any technical reason not to >> enable that and bunch of other exotic stuff. >> >> Though, as you've already noticed, one can count the number of >> user who benefit from such a change on one hand.. ;) >> Not sure it's worth the effort, though, if someone wants to do >> the work, fine with me. >> > True on that one :) > > But then again, there are not many as tenacious as I am, and it is not clear > that it has not been enabled anywhere. If the build is not worth it, perhaps > some documentation to point a user to what can be added to the build? At > least that way if someone is intent enough to find the info they can do > something about it? Such as myself; if I had of known it needed the option > it might have saved me several weeks of messing around. > > Just a note in the man pages might do, as well as a wiki, or the handbook. Updating the man page is on my TODO list. It already mentions options which are enabled/disabled by default and also refers to make.conf, but some information is clearly outdated and/or no longer valid. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Oops! (was: Support for Intel 5100 WiFi ?)
On Sunday 07 October 2012 07:08:58 Ronald F. Guilmette wrote: > > Regarding my immediately prior mesage... NEVERMIND! > > I did: > > kldload if_iwn > > (based on a suggestion I found on the next) and now, of course, the thing > is properly showing up as iwn0. > > I do still have a couple of questions though... > > After the kldload, I got message showing me the various data rates > available for 801.11a, 802.11b, and 802.11g... up to 54Mbps on that > last one, of course. > > However as I understand it, the Intel 5100 chip is also capable of > 802.11n, and furthermore and additionally, it is allegedly dual-band, > having the capability to operate in either the 2.4GHz range or in the > 5Ghz range. > > So I'd just like to know if the driver for this chip, either in 8.2-RELEASE > or in anything later, supports either 802.11n and/or the 5GHz band. > > Of course, I'd also like to know if there is support for 40MHz channels, > and how one would go about making use of any or all of these enhanced > features, if in fact they are supported by the (recent or current) > driver. > > Thanks in advance for any info. iwn(4) does support 11n, 5GHz and 40MHz channels. Though, it might be better to switch to 9.x as it has received many many enhancements. Using those features is rather easy, it does so by default ;) -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Oops! (was: Support for Intel 5100 WiFi ?)
On Sunday 07 October 2012 23:28:23 Ronald F. Guilmette wrote: > > In message <201210071040.01104.bschm...@techwires.net>, > Bernhard Schmidt wrote: > > >iwn(4) does support 11n, 5GHz and 40MHz channels. Though, it might > >be better to switch to 9.x as it has received many many enhancements. > > OK. I suspected that might be the case. I'm glad that I asked! > > Is the iwn(4) driver in 9.0 pretty good. Or are there some things in > 9.1-RC1 (relating to iwn) that I might possibly want/need? (I prefer > to stick with official releases, if possible.) There is at least one 11n related bug fix 9.1 which isn't available in 9.0. You should be fine with 9.0 if you are not running into this issue (which is pretty hard to trigger I guess). > >Using those features is rather easy, it does so by default ;) > > OK. I want to make sure that I understand what you just said. > > (Please note that I was almost entirely ignorant about the standards and > the current state of technology with respect to ALL of this wireless stuff > up until about three weeks ago, but I have tried my best to learn since > then, so bear with me here.) > > If I have understood you correctly, then you are saying that, with respect > to the decision of whether to use or, alternatively, to not use 11n > (falling back to 11g if necessary), *and* with respect to the decision to > use or not use 5GHz (falling back to 2.4Ghz if necessary), *and* with > respect to the decision of whether to use or not use 40GHz channels > (falling back to 20MHz if necessary), the client does not get to make > any of its own decisions about any of these things, and it must instead > just follow the lead of whatever AP it is trying to connect to. > > Is that correct? Have I understood you correctly? > > (Forgive me. I'me really just still feeling my way through all of this > stuff.) What I was trying to say is, if an AP supports 11n, 11g, 20 and 40MHz channels, by default the setup which does give the best performance is used; which would be 11n+40MHz in this case. If an AP supports just 20MHz channels, iwn(4) is fine with that; same for 11g vs. 11n. Choosing 2GHz over 5GHz is something entirely different. If there is an AP which provides access to the same SSID via either 2GHz or 5GHz, iwn(4) might choose randomly (it's not entirely random, usually it's the first network detected, but close anyway). If you want to have influence on that process, you are able to by setting the appropriate options via ifconfig(8). Either something like *-ht* to disable 11n, or *channel* to restrict the device to a certain channel. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: What driver should I use for 'intel centrino wireless-N 2200 BGN'?
On Wednesday 10 October 2012 15:51:24 Denise H. G. wrote:
> > none3@pci0:3:0:0: class=0x028000 card=0x42228086 chip=0x08918086
> > rev=0xc4 hdr=0x00
> >
> > Is there a driver for that under FreeBSD 9.1-PRERELEASE?
No, not yet. I'm having a hard figuring out the new firmware API for
those new devices. Working on it..
> >> I tried to add some device ids into the source code of the drivers, but
> >> with no luck. Maybe I am doing it the wrong way.
> >
> > The card ID in the code is 4220 and yours has is 4222. Edit
> > /sys/dev/iwi/if_iwi.c and add:
> > { 0x8086, 0x4222, "Intel(R) PRO/Wireless 2200BG" },
> > after line 123.
Note the tiny difference in here ;)
Intel(R) PRO/Wireless 2200BG
vs.
Intel Centrino Wireless-N 2200 BGN
There are like 10 years in between. :)
Just to clarify, the 0x4222 is for iwn(4), adding the IDs there is the
first step, followed by a new firmware module and some glue code.
I already thought about adding just the firmware but not the IDs yet,
for others to tinker with. Issue is that this would generate
regressions with already working cards, eg. 6230. So, eventually..
just not yet.
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Oops! (was: Support for Intel 5100 WiFi ?)
On Friday 12 October 2012 01:11:21 Ronald F. Guilmette wrote: > > In message > > , you wrote: > > >What's the output of 'ifconfig wlanX list sta'? > > % ifconfig wlan0 list sta > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > c0:c1:c0:8b:4b:f31 11 36M 11.50 85 37120 EP AQEHTRS RSN > HTCAP WPS WME This is the expected result. iwn(4) still (ab)uses the legacy rate control algo for 11n. This means that you get the real 11n throughput because the legacy rates are translated to MCS rates, but, the reported rates are still legacy. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Monitor mode not working for iwi(4) on 7.X
Alexey Dokuchaev : > On Sun, Oct 10, 2010 at 07:27:30AM +, Alexey Dokuchaev wrote: >> On Sat, Oct 09, 2010 at 08:46:41PM +0200, Bernhard Schmidt wrote: >> > On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: >> > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, >> > > which means it can utilize monitor mode. "ifconfig iwi0 scan" however >> > > does not work after that (and "list scan" returns no results) even if I >> > > put adapter back to normal (from promisc and monitor modes) with >> > > ifconfig(8). kldunloading and loading module again fixes the issue. >> > >> > Due to enqueueing the scan command in an infinite loop (yeah.. scanning >> > returns every frame, that's monitor mode for that device.. *sigh*) we >> > might increment a queue index but never actually dequeueing the command. >> > On 'down' we clear the command queue but not the indices resulting in >> > the cur index not pointing to a filled entry. Attached patch should fix >> > that. >> >> It does, thanks! "list scan" gets populated after I -mediaopt monitor >> after scan; module reload is not required anymore. > > Not sure if this is a driver or ifconfig(8) problem, but after I -mediaopt > monitor, ifconfig(8) still reports it in media line: > > media: IEEE 802.11 Wireless Ethernet autoselect > > However, as I said, scan list gets populated, which suggests ifconfig(8) > is getting something wrong. Doing -mediaopt monitor the second time > "knocks" ifconfig(8) though. I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOWN' state. Can you post the exact command sequence you've used? The output differs though.. # ifconfig iwi0 mediaopt monitor # ifconfig iwi0 up # ifconfig iwi0 | grep media media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) # ifconfig iwi0 -mediaopt monitor # ifconfig iwi0 | grep media media: IEEE 802.11 Wireless Ethernet autoselect # -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_ndis: fix for panic with VIMAGE
9, 2010 at 20:57, Paul B Mahol wrote: > On 10/13/10, Paul B Mahol wrote: >> On 10/12/10, Paul B Mahol wrote: >>> On 10/11/10, Paul B Mahol wrote: Hi, There is no single valid reason to call rt_ifmsg() in ndis_linksts_done() Patch attached. >>> Ping. >> Pong. > Ping. Committed, thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Monitor mode not working for iwi(4) on 7.X
2010/10/20 Alexey Dokuchaev : > On Tue, Oct 19, 2010 Bernhard Schmidt wrote: >> Alexey Dokuchaev wrote: >> > Not sure if this is a driver or ifconfig(8) problem, but after I -mediaopt >> > monitor, ifconfig(8) still reports it in media line: >> > >> > media: IEEE 802.11 Wireless Ethernet autoselect >> > >> > However, as I said, scan list gets populated, which suggests ifconfig(8) >> > is getting something wrong. Doing -mediaopt monitor the second time >> > "knocks" ifconfig(8) though. >> >> I can't reproduce that on my stable/7 setup, neither in 'UP' nor in 'DOWN' >> state. Can you post the exact command sequence you've used? The output >> differs though.. >> >> # ifconfig iwi0 mediaopt monitor >> # ifconfig iwi0 up >> # ifconfig iwi0 | grep media >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) >> # ifconfig iwi0 -mediaopt monitor >> # ifconfig iwi0 | grep media >> media: IEEE 802.11 Wireless Ethernet autoselect > > This scenario works. But try it out after aircrack-ng tools, which set > (P)PROMISC mode on the card (and do not clear it after exit, but in my > understanding this should not affect monitor mode and its indication, no?). Correct. # kldload if_iwi # aireplay-ng -9 iwi0 # ifconfig iwi0 iwi0: flags=28943 metric 0 mtu 1500 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) # ifconfig iwi0 -mediaopt monitor # ifconfig iwi0 iwi0: flags=28943 metric 0 mtu 1500 media: IEEE 802.11 Wireless Ethernet autoselect # hmm.. looks correct to me, am I doing something wrong? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ndis: patch for review
9, 2010 at 23:53, Paul B Mahol wrote:
> Hi,
>
> First: we should pin curthread on CPU before we check on which CPU is
> curthread.
>
> Second: instead of sti & cli use critical sections when saving %fs register.
>
> Third: I do not know what happens if we get preempted while windows
> code were running,
> so leave critical section only _after_ executing windows code.
Do you have a test case for that? If so, can you post it?
> diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
> index f231863..ba29fd2 100644
> --- a/sys/compat/ndis/kern_windrv.c
> +++ b/sys/compat/ndis/kern_windrv.c
> @@ -613,8 +613,6 @@ struct gdt {
> extern uint16_t x86_getfs(void);
> extern void x86_setfs(uint16_t);
> extern void *x86_gettid(void);
> -extern void x86_critical_enter(void);
> -extern void x86_critical_exit(void);
> extern void x86_getldt(struct gdt *, uint16_t *);
> extern void x86_setldt(struct gdt *, uint16_t);
>
> @@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t);
> void
> ctxsw_utow(void)
> {
> - struct tid *t;
> + struct tid *t;
>
> + sched_pin();
> + critical_enter();
> t = &my_tids[curthread->td_oncpu];
>
> /*
> @@ -685,12 +685,9 @@ ctxsw_utow(void)
> if (t->tid_self != t)
> x86_newldt(NULL);
>
> - x86_critical_enter();
> t->tid_oldfs = x86_getfs();
> t->tid_cpu = curthread->td_oncpu;
> - sched_pin();
> x86_setfs(SEL_TO_FS(t->tid_selector));
> - x86_critical_exit();
>
> /* Now entering Windows land, population: you. */
> }
> @@ -706,11 +703,10 @@ ctxsw_wtou(void)
> {
> struct tid *t;
>
> - x86_critical_enter();
> t = x86_gettid();
> x86_setfs(t->tid_oldfs);
> + critical_exit();
> sched_unpin();
> - x86_critical_exit();
>
> /* Welcome back to UNIX land, we missed you. */
>
> diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S
> index c051504..fa4aa87 100644
> --- a/sys/compat/ndis/winx32_wrap.S
> +++ b/sys/compat/ndis/winx32_wrap.S
> @@ -375,11 +375,3 @@ ENTRY(x86_setfs)
> ENTRY(x86_gettid)
> mov %fs:12,%eax
> ret
> -
> -ENTRY(x86_critical_enter)
> - cli
> - ret
> -
> -ENTRY(x86_critical_exit)
> - sti
> - ret
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up
On Sunday, October 24, 2010 07:25:59 Matthias Apitz wrote:
> Hello,
>
> I have a new laptop Acer Aspire One D250 and I want to install a
> 8-CURRENT as of CVS from May 2009 (as I use this on all my laptops).
> The laptop comes with as Wifi chip:
>
> no...@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4
> rev=0x01 hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'BCM4310 USB Controller'
> class = network
>
> I learned after searching around that it should be supported by bwi(4)
> and one should install the firmware kmod from the ports. I have in
> loader.conf:
> [..]
Please try attached patch, I'm not sure if it is that simple.. worth a try
though.
--
Bernhard
--- a/sys/dev/bwi/if_bwi_pci.c
+++ b/sys/dev/bwi/if_bwi_pci.c
@@ -85,6 +85,7 @@ static const struct bwi_dev {
{ PCI_VENDOR_BROADCOM, 0x4311,"Broadcom BCM4311 802.11b/g Wireless Lan" },
{ PCI_VENDOR_BROADCOM, 0x4312,"Broadcom BCM4312 802.11a/b/g Wireless Lan" },
{ PCI_VENDOR_BROADCOM, 0x4313,"Broadcom BCM4312 802.11a Wireless Lan" },
+ { PCI_VENDOR_BROADCOM, 0x4315,"Broadcom BCM4312 802.11b/g Wireless Lan"},
{ PCI_VENDOR_BROADCOM, 0x4320,"Broadcom BCM4306 802.11b/g Wireless Lan"},
{ PCI_VENDOR_BROADCOM, 0x4321,"Broadcom BCM4306 802.11a Wireless Lan"},
{ PCI_VENDOR_BROADCOM, 0x4325,"Broadcom BCM4306 802.11b/g Wireless Lan"},
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ndis: properly allocate memory
On Wed, Nov 10, 2010 at 15:56, Paul B Mahol wrote: > Hi, > > Attached patch resolves buggy allocation of memory in NDISulator. > Correct behavior is to not ignore parameters specified by miniport driver. The important point to mention here is that those restrictions are to be applied to physical memory according to specs for MmAllocateContiguousMemorySpecifyCache(), therefore the call to contigmalloc(). I'll take care of the commit. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ndis: fix panic on i386
On Mon, Nov 15, 2010 at 14:14, Paul B Mahol wrote: > Hi, > > Following patch fix panic on i386 for drivers using such functions. > [..] Committed, thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/152716: hostapd(8) fails to authenticate after 2010-11-03 update
On Monday 06 December 2010 04:48:03 lini...@freebsd.org wrote: > Old Synopsis: hostapd fails ti authenticate after 2010-11-03 update > New Synopsis: hostapd(8) fails to authenticate after 2010-11-03 update > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Dec 6 03:43:30 UTC 2010 > Responsible-Changed-Why: > Although this was an rpaulo MFC, he is not currently working on this > code; so, assign it to -net. Can you try that with a recent version of head (post-216541) again? I've committed a bunch of changes which should address this issue. Thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/152716: hostapd(8) fails to authenticate after 2010-11-03 update
The following reply was made to PR bin/152716; it has been noted by GNATS. From: Bernhard Schmidt To: David Cornejo Cc: freebsd-net@freebsd.org, bug-follo...@freebsd.org Subject: Re: bin/152716: hostapd(8) fails to authenticate after 2010-11-03 update Date: Sat, 18 Dec 2010 21:34:34 +0100 On Monday 06 December 2010 04:48:03 lini...@freebsd.org wrote: > Old Synopsis: hostapd fails ti authenticate after 2010-11-03 update > New Synopsis: hostapd(8) fails to authenticate after 2010-11-03 update > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Dec 6 03:43:30 UTC 2010 > Responsible-Changed-Why: > Although this was an rpaulo MFC, he is not currently working on this > code; so, assign it to -net. Can you try that with a recent version of head (post-216541) again? I've committed a bunch of changes which should address this issue. Thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource
The following reply was made to PR kern/143874; it has been noted by GNATS. From: Bernhard Schmidt To: oliver.sola...@gmail.com Cc: bug-follo...@freebsd.org Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource Date: Sun, 19 Dec 2010 11:49:27 +0100 On Sunday 12 September 2010 05:30:10 oliver.sola...@gmail.com wrote: > I have the same issue with a Toshiba Satellite P105: > > Sep 11 21:46:13 kernel: wpi0: irq 17 > at device 0.0 on pci3 > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 failed > (0, 0xf fff). > Sep 11 21:46:13 kernel: wpi0: could not allocate memory resource > Sep 11 21:46:13 kernel: device_attach: wpi0 attach returned 6 > > Please let me know if I can help out to track this issue down. Is this still an issue on a recent stable/8 or 8.2-BETA1? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource
On Monday 20 December 2010 12:06:24 Patrick Ale wrote: > Hi, > > Not sure if this is useful information for you but here goes: > I have exactly the same problem on my Acer Aspire laptop with the same > network card but then under Solaris 10 and Opensolaris, both 64 bit. > > The only way for me to get rid of this error and get the card working > is to reduce my memory from 4GB to <= 3GB. > I got told it has to do with the PCI to PCI-X bridge masquarading some > memory addresses.. > > I am not a kernel/driver/code guru but I thought one of you might get > some pointers out of this.. There have been a few changes to PCI bridge code lately which might well fix that issue. If anyone could give a recent stable/8 or 8.2-BETA a shot, I'd really appreciate that. > On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert wrote: > > The following reply was made to PR kern/143874; it has been noted by > > GNATS. > > > > From: Oliver Ebert > > To: Bernhard Schmidt > > Cc: bug-follo...@freebsd.org > > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not > > allocate memory resource > > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > > > On Sun, 19 Dec 2010 11:49:27 +0100 > > Bernhard Schmidt wrote: > > > > > On Sunday 12 September 2010 05:30:10 oliver.sola...@gmail.com wrote: > > > > I have the same issue with a Toshiba Satellite P105: > > > > > > > > Sep 11 21:46:13 kernel: wpi0: irq > > > > 17 at device 0.0 on pci3 > > > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res 3 failed > > > > (0, 0xf fff). > > > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory resource > > > > Sep 11 21:46:13 kernel: device_attach: wpi0 attach returned 6 > > > > > > > > Please let me know if I can help out to track this issue down. > > > > > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > > > > > > > With 8.1 it is but I didn't had a chance to check with 8.2 beta. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic
The following reply was made to PR kern/144987; it has been noted by GNATS. From: Bernhard Schmidt To: bug-follo...@freebsd.org, gabrielquad...@hotmail.com Cc: Subject: Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic Date: Mon, 20 Dec 2010 15:10:02 +0100 Hi, The issue here is that you've tried to use wlaninject with a VAP in sta mode. As soon as wlaninject tries to set up the interface, net80211 will start to do a scan which means constant channel switches until it finds something to associate. wlaninject itself is not aware of that and happily injects frames no matter what the current channel state is, as the above trace shows, you hit a point where no channel is set between 2 scan interations. wlaninject is supposed to be used with VAPs in ahdemo mode and wpi(4) does not support that mode. Therefore I tend to close this PR. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic
The following reply was made to PR kern/144987; it has been noted by GNATS. From: Bernhard Schmidt To: bug-follo...@freebsd.org, gabrielquad...@hotmail.com Cc: Julian Elischer Subject: Re: kern/144987: [wpi] [panic] injecting packets with wlaninject using Intel 3945ABG wireless card gives kernel panic Date: Wed, 22 Dec 2010 09:58:34 +0100 On Monday 20 December 2010 15:10:02 Bernhard Schmidt wrote: > Hi, > > The issue here is that you've tried to use wlaninject with a VAP in sta > mode. As soon as wlaninject tries to set up the interface, net80211 will > start to do a scan which means constant channel switches until it finds > something to associate. wlaninject itself is not aware of that and happily > injects frames no matter what the current channel state is, as the above > trace shows, you hit a point where no channel is set between 2 scan > interations. > > wlaninject is supposed to be used with VAPs in ahdemo mode and wpi(4) does > not support that mode. Therefore I tend to close this PR. Looking closer I might have been a bit wrong. There are several issue here.. One being that ni_chan is used in the TX path which should and can actually be replaced by ic_curchan. This will fix the panic reported above, though, this does no longer obscure other issues. For examples, we are allowed to pass in frames of arbitrary length, extremely short frames will be discarded early due to an overflow checking the length (the message to long error). But, if the length is just long enough to reach the driver it might still be shorter then the header for a 802.11 frame. This will result in another panic() in m_copydata() as we try to copy over the header to firmware.. I'll try to find a useful solution for that. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource
On Thursday 23 December 2010 02:23:04 Oliver Ebert wrote: > On Mon, 20 Dec 2010 12:53:30 +0100 > > Bernhard Schmidt wrote: > > On Monday 20 December 2010 12:06:24 Patrick Ale wrote: > > > Hi, > > > > > > Not sure if this is useful information for you but here goes: > > > I have exactly the same problem on my Acer Aspire laptop with the > > > same network card but then under Solaris 10 and Opensolaris, both > > > 64 bit. > > > > > > The only way for me to get rid of this error and get the card > > > working is to reduce my memory from 4GB to <= 3GB. > > > I got told it has to do with the PCI to PCI-X bridge masquarading > > > some memory addresses.. > > > > > > I am not a kernel/driver/code guru but I thought one of you might > > > get some pointers out of this.. > > > > There have been a few changes to PCI bridge code lately which might > > well fix that issue. If anyone could give a recent stable/8 or > > 8.2-BETA a shot, I'd really appreciate that. > > > > > On Sun, Dec 19, 2010 at 6:10 PM, Oliver Ebert > > > > > > > wrote: > > > > The following reply was made to PR kern/143874; it has been noted > > > > by GNATS. > > > > > > > > From: Oliver Ebert > > > > To: Bernhard Schmidt > > > > Cc: bug-follo...@freebsd.org > > > > Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 > > > > could not allocate memory resource > > > > Date: Sun, 19 Dec 2010 10:39:47 -0600 > > > > > > > > On Sun, 19 Dec 2010 11:49:27 +0100 > > > > > > > > Bernhard Schmidt wrote: > > > > > On Sunday 12 September 2010 05:30:10 oliver.sola...@gmail.com > > > > > > > > > > wrote: > > > > > > I have the same issue with a Toshiba Satellite P105: > > > > > > > > > > > > Sep 11 21:46:13 kernel: wpi0: > > > > > 3945ABG> irq 17 at device 0.0 on pci3 > > > > > > Sep 11 21:46:13 kernel: wpi0: Driver Revision 20071127 > > > > > > Sep 11 21:46:13 kernel: wpi0: 0x1000 bytes of rid 0x10 res > > > > > > 3 failed (0, 0xf fff). > > > > > > Sep 11 21:46:13 kernel: wpi0: could not allocate memory > > > > > > resource Sep 11 21:46:13 kernel: device_attach: wpi0 attach > > > > > > returned 6 > > > > > > > > > > > > Please let me know if I can help out to track this issue > > > > > > down. > > > > > > > > > > Is this still an issue on a recent stable/8 or 8.2-BETA1? > > > > > > > > 8.2-PRERELEASE > > > > > > > > With 8.1 it is but I didn't had a chance to check with 8.2 beta. > > I just upgraded to 8.2-PRERELEASE and it seems that the issue is still > persistent: Now wlan0 device shows up. > > The device is available when booting with ACPI disabled. Still same error message? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
CFT/CFR, possible fix for ifconfig scan hang
Hi, I recently received some complains about the infamous 'ifconfig scan hang' issue again. Finally looking into that I noticed a bunch of inconsistences, the most obvious one is that ifconfig(8) is talking about doing a background scan by default, which is simply not true according to the implementation. Anyways.. the generic use-case which triggers the 'hang' is, if 'ifconfig scan' is called while a scan is already in progress, net80211 will not start a new one which means that no scan flags are updated, though, ifconfig will loop until it receives a notification about the scan being done. This does always happen after an 'ifconfig up', because net80211 will move the VAP into scan state by default, with the scan flags set in such a way that a scan is done until there is something to connect to. This also means that no notifications about the scan being done are sent to upper layers, because the scan is not finished.. If we successfully moved from scan to run state, how so ever, and now want to call 'ifconfig scan' we're faced with another issue. Doing a scan while being associated means we have to move off our current channel, to do this without loosing any imported frames/information, we make use of the power save feature. Now if we want to send any traffic while doing the scan, the scan is temporary suspended, frames are sent, then the scan is restarted after receiving a beacon and there is no frame to send. For this to work though, we need to actually request a background scan so appropriate flags are set and the scan is actually restarted. Without this, we hang until the bgscan timer fires of at that next bgscanintval. I have a patch available which addresses both of the issues. It requests a background scan by default and also honors the return value of start_scan_locked(): - for head http://techwires.net/~bschmidt/scan_hang_head.diff - for 8-stable/8.2-*: http://techwires.net/~bschmidt/scan_hang_stable.diff Please test and let me know if it works, or not. Thanks -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CFT/CFR, possible fix for ifconfig scan hang
On Tuesday 28 December 2010 01:41:39 Attilio Rao wrote: > 2010/12/27 Bernhard Schmidt : > > Hi, > > > > I recently received some complains about the infamous 'ifconfig scan > > hang' issue again. Finally looking into that I noticed a bunch of > > inconsistences, the most obvious one is that ifconfig(8) is talking > > about doing a background scan by default, which is simply not true > > according to the implementation. > > > > Anyways.. the generic use-case which triggers the 'hang' is, if 'ifconfig > > scan' is called while a scan is already in progress, net80211 will not > > start a new one which means that no scan flags are updated, though, > > ifconfig will loop until it receives a notification about the scan being > > done. This does always happen after an 'ifconfig up', because net80211 > > will move the VAP into scan state by default, with the scan flags set in > > such a way that a scan is done until there is something to connect to. > > This also means that no notifications about the scan being done are sent > > to upper layers, because the scan is not finished.. > > > > If we successfully moved from scan to run state, how so ever, and now > > want to call 'ifconfig scan' we're faced with another issue. Doing a > > scan while being associated means we have to move off our current > > channel, to do this without loosing any imported frames/information, we > > make use of the power save feature. Now if we want to send any traffic > > while doing the scan, the scan is temporary suspended, frames are sent, > > then the scan is restarted after receiving a beacon and there is no > > frame to send. For this to work though, we need to actually request a > > background scan so appropriate flags are set and the scan is actually > > restarted. Without this, we hang until the bgscan timer fires of at that > > next bgscanintval. > > > > I have a patch available which addresses both of the issues. It requests > > a background scan by default and also honors the return value of > > start_scan_locked(): > > - for head > > http://techwires.net/~bschmidt/scan_hang_head.diff > > - for 8-stable/8.2-*: > > http://techwires.net/~bschmidt/scan_hang_stable.diff > > > > Please test and let me know if it works, or not. > > Bernard, > thanks a lot for working on this. > > There is any receipt for easilly reproduce this type of bug, or I > should just go with 'ifconfig scan' repeteadly? > I recall I could trigger it, but not 100% of times, so if you have > more hints about how this problem could be reproduced, I'd be glad to > hear. With an wpi(4) device I was able to trigger it 100% reliably with no open AP available: ifconfig wlan0 create wlandev wpi0 ifconfig wlan0 up sleep 1 ifconfig wlan0 scan # this will hang For background scans, wpi(4) isn't the best hardware to test with because it lags support for currectly (you'll only get a fireware error). So use something else, ath(4) works. Scan would hang if there is some light traffic going with enough time between frames, usally ping works. .. wpa_supplicant -Dbsd -iwlan0 ... # wait for device to get associated, assign ip, .. ping somethings & ifconfig wlan0 scan # this will hang -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CFT/CFR, possible fix for ifconfig scan hang
On Tuesday 28 December 2010 01:17:42 Brandon Gooch wrote: > On Mon, Dec 27, 2010 at 1:24 PM, Bernhard Schmidt wrote: > > Hi, > > > > I recently received some complains about the infamous 'ifconfig scan > > hang' issue again. Finally looking into that I noticed a bunch of > > inconsistences, the most obvious one is that ifconfig(8) is talking > > about doing a background scan by default, which is simply not true > > according to the implementation. > > > > Anyways.. the generic use-case which triggers the 'hang' is, if 'ifconfig > > scan' is called while a scan is already in progress, net80211 will not > > start a new one which means that no scan flags are updated, though, > > ifconfig will loop until it receives a notification about the scan being > > done. This does always happen after an 'ifconfig up', because net80211 > > will move the VAP into scan state by default, with the scan flags set in > > such a way that a scan is done until there is something to connect to. > > This also means that no notifications about the scan being done are sent > > to upper layers, because the scan is not finished.. > > > > If we successfully moved from scan to run state, how so ever, and now > > want to call 'ifconfig scan' we're faced with another issue. Doing a > > scan while being associated means we have to move off our current > > channel, to do this without loosing any imported frames/information, we > > make use of the power save feature. Now if we want to send any traffic > > while doing the scan, the scan is temporary suspended, frames are sent, > > then the scan is restarted after receiving a beacon and there is no > > frame to send. For this to work though, we need to actually request a > > background scan so appropriate flags are set and the scan is actually > > restarted. Without this, we hang until the bgscan timer fires of at that > > next bgscanintval. > > > > I have a patch available which addresses both of the issues. It requests > > a background scan by default and also honors the return value of > > start_scan_locked(): > > - for head > > http://techwires.net/~bschmidt/scan_hang_head.diff > > - for 8-stable/8.2-*: > > http://techwires.net/~bschmidt/scan_hang_stable.diff > > > > Please test and let me know if it works, or not. > > Works here, on 8.2-PRERELEASE #1 r216690 and 9.0-CURRENT #1 r216702. > > I mucked around for about an hour on both systems with varying > configurations (iwn(4) and wpi(4)), and all seemed normal and > consistently well-behaved. > > Thanks Bernhard! Thanks! -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate memory resource
The following reply was made to PR kern/143874; it has been noted by GNATS.
From: Bernhard Schmidt
To: Oliver Ebert
Cc: bug-follo...@freebsd.org
Subject: Re: kern/143874: [wpi] Wireless 3945ABG error. wpi0 could not allocate
memory resource
Date: Thu, 30 Dec 2010 12:12:43 +0100
On Sunday 19 December 2010 18:10:11 Oliver Ebert wrote:
> Bernhard Schmidt wrote:
> > Is this still an issue on a recent stable/8 or 8.2-BETA1?
>
> With 8.1 it is but I didn't had a chance to check with 8.2 beta.
According to John Baldwin this is long standing issue within our
{ACPI,PCI}-Bridge code, not directly related to the device driver itself. Way
above my clue level.. sorry for the noise.
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/153594: [iwn] Network keeps disconnecting when /etc/rc.d/netif restart is run
On Tuesday, January 04, 2011 09:08:24 Eugene Grosbein wrote: > > There is race in devd and our rc-subsystem if wpa_supplicant is involved > > effectivly resulting in starting wpa_supplicant twice. Both instances try > > to take over the wlan device which results in what you are seeing. > > I have no idea how to fix this right now, so this has to wait until I'm > > able to think of proper fix. > > Perhaps, wrapping wpa_supplicant invocation into "lockf -t0" would help > to eliminate race? Possibly, but I don't think this is the way to go. Currently wpa_supplicant has this code: /* * Mark the interface as down to ensure wpa_supplicant has exclusive * access to the net80211 state machine, do this before opening the * route socket to avoid a false event that the interface disappeared. */ if (getifflags(drv, &flags) == 0) (void) setifflags(drv, flags &~ IFF_UP); This code works such that it will send an event to already running wpa_supplicant instances which will then terminate. This does indeed work if there's enough delay between invocations, though, if there is just a small delay (~100ms or something), that event doesn't get passed probably. I think we should start looking into possible solution at that point, trying to figure out why the the event doesn't get passed (probably because the interface is not yet up at that point) will get us closer to proper solution. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/153594: [iwn] Network keeps disconnecting when /etc/rc.d/netif restart is run
On Tuesday, January 04, 2011 10:09:15 Eugene Grosbein wrote: > On 04.01.2011 15:06, Bernhard Schmidt wrote: > >> Perhaps, wrapping wpa_supplicant invocation into "lockf -t0" would help > >> to eliminate race? > > > > Possibly, but I don't think this is the way to go. > > > > Currently wpa_supplicant has this code: > > /* > > > > * Mark the interface as down to ensure wpa_supplicant has > > exclusive * access to the net80211 state machine, do this > > before opening the * route socket to avoid a false event that > > the interface disappeared. */ > > > > if (getifflags(drv, &flags) == 0) > > > > (void) setifflags(drv, flags &~ IFF_UP); > > > > This code works such that it will send an event to already running > > wpa_supplicant instances which will then terminate. This does indeed work > > if there's enough delay between invocations, though, if there is just a > > small delay (~100ms or something), that event doesn't get passed > > probably. I think we should start looking into possible solution at that > > point, trying to figure out why the the event doesn't get passed > > (probably because the interface is not yet up at that point) will get us > > closer to proper solution. > > Proper fine-grained locking was always good solution for race problem :-) > How about using flock(2) in wpa_supplicant source code? I don't see any flock'able resource shared between instances, do you? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
devd and 802.11
Hi,
While working on the 'netif restart' issue (kern/153594) I noticed that there
are to entries in devd.conf with shady usefulness.
detach 0 {
media-type "802.11";
action "/etc/pccard_ether $device-name stop";
};
attach 0 {
media-type "802.11";
action "/etc/pccard_ether $device-name start";
};
I assume that the general use-case for devd is to automatically configure
wireless devices as soon as those are plugged in (PCMCIA, ..). Those are
already handled by
notify 0 {
match "system" "IFNET";
match "type""ATTACH";
action "/etc/pccard_ether $subsystem start";
};
this will invoke netif which then will create and configure the wlan0 device.
While wlan0 is created, devd is poked again and this time the other rule kicks
in and starts netif again. This effectively results in 2 'netif start wlan0'
calls. Due to the racy nature of this all tries to ensure wpa_supplicant has
exclusive access to the wlan device fail, wpa_supplicant gets started twice
and each instance is fighting for ownership.
That devd entries a quite old (pre-VAP), the media-type might have changed and
this was just overlooked, so, I did some tests to figure out if those are
really necessary. After removing the 2 entries, I tried 3 things:
- plug in PCMCIA card while system is up
- remove PCMCIA device while system is up
- kldunload if_drv; kldload if_drv
in both cases, the wireless device was configure according to the settings in
rc.conf. Also, cleaning up after kldunload or removal of the device worked as
expected.
If I'm not missing an use-case here (pointers?) and there are no complains,
the attached diff is worth being committed.
--
Bernhard
Index: etc/devd.conf
===
--- etc/devd.conf (revision 217018)
+++ etc/devd.conf (working copy)
@@ -60,14 +60,6 @@ notify 0 {
# they have a different media type. We may want
# to exploit this later.
#
-detach 0 {
- media-type "802.11";
- action "/etc/pccard_ether $device-name stop";
-};
-attach 0 {
- media-type "802.11";
- action "/etc/pccard_ether $device-name start";
-};
notify 0 {
match "system" "IFNET";
match "type" "LINK_UP";
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: What is recommended wireless LAN card for FreeBSD TDMA?
On Thursday, January 13, 2011 04:44:03 Kyungsoo Lee wrote: > Hello guys, > > I have used Proxim 8470 LAN cards. But I realized that this card is too old > to use TDMA on FreeBSD. I need new wireless LAN cards which are supported > by TDMA on FreeBSD and with an external port to connect directional > antenna. Do you recommend any cards? Actually, it is hard to find wireless > LAN cards with the conditions. Afaik TDMA was implemented on and for ath(4) only. You might want to try to obtain either a Ubiquiti SR2 or a Wistron CM9, those should do. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Looking for hints re 802.1X wired (fwd)
On Friday 14 January 2011 15:40:18 Dennis Glatting wrote: > I forgot to mention an important data point. I see via WireShark the > EAPOL from the supplicant to the server and the server requesting > identity but the supplicant doesn't appear to see the request. Which FreeBSD version are you running? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CFT/CFR, possible fix for ifconfig scan hang
Hi, no objections so far. If non arise till this weekend, I going to commit this. On Monday 27 December 2010 20:24:36 Bernhard Schmidt wrote: > Hi, > > I recently received some complains about the infamous 'ifconfig scan hang' > issue again. Finally looking into that I noticed a bunch of inconsistences, > the most obvious one is that ifconfig(8) is talking about doing a > background scan by default, which is simply not true according to the > implementation. > > Anyways.. the generic use-case which triggers the 'hang' is, if 'ifconfig > scan' is called while a scan is already in progress, net80211 will not > start a new one which means that no scan flags are updated, though, > ifconfig will loop until it receives a notification about the scan being > done. This does always happen after an 'ifconfig up', because net80211 > will move the VAP into scan state by default, with the scan flags set in > such a way that a scan is done until there is something to connect to. > This also means that no notifications about the scan being done are sent > to upper layers, because the scan is not finished.. > > If we successfully moved from scan to run state, how so ever, and now want > to call 'ifconfig scan' we're faced with another issue. Doing a scan while > being associated means we have to move off our current channel, to do this > without loosing any imported frames/information, we make use of the power > save feature. Now if we want to send any traffic while doing the scan, the > scan is temporary suspended, frames are sent, then the scan is restarted > after receiving a beacon and there is no frame to send. For this to work > though, we need to actually request a background scan so appropriate flags > are set and the scan is actually restarted. Without this, we hang until > the bgscan timer fires of at that next bgscanintval. > > I have a patch available which addresses both of the issues. It requests a > background scan by default and also honors the return value of > start_scan_locked(): > - for head > http://techwires.net/~bschmidt/scan_hang_head.diff > - for 8-stable/8.2-*: > http://techwires.net/~bschmidt/scan_hang_stable.diff > > Please test and let me know if it works, or not. > > Thanks > -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: devd and 802.11
Hi,
no objections so far. If non arise till this weekend, I going to commit it.
On Wednesday 05 January 2011 21:51:46 you wrote:
> Hi,
>
> While working on the 'netif restart' issue (kern/153594) I noticed that
> there are to entries in devd.conf with shady usefulness.
>
> detach 0 {
> media-type "802.11";
> action "/etc/pccard_ether $device-name stop";
> };
> attach 0 {
> media-type "802.11";
> action "/etc/pccard_ether $device-name start";
> };
>
> I assume that the general use-case for devd is to automatically configure
> wireless devices as soon as those are plugged in (PCMCIA, ..). Those are
> already handled by
>
> notify 0 {
> match "system" "IFNET";
> match "type""ATTACH";
> action "/etc/pccard_ether $subsystem start";
> };
>
> this will invoke netif which then will create and configure the wlan0
> device. While wlan0 is created, devd is poked again and this time the
> other rule kicks in and starts netif again. This effectively results in 2
> 'netif start wlan0' calls. Due to the racy nature of this all tries to
> ensure wpa_supplicant has exclusive access to the wlan device fail,
> wpa_supplicant gets started twice and each instance is fighting for
> ownership.
>
> That devd entries a quite old (pre-VAP), the media-type might have changed
> and this was just overlooked, so, I did some tests to figure out if those
> are really necessary. After removing the 2 entries, I tried 3 things:
> - plug in PCMCIA card while system is up
> - remove PCMCIA device while system is up
> - kldunload if_drv; kldload if_drv
> in both cases, the wireless device was configure according to the settings
> in rc.conf. Also, cleaning up after kldunload or removal of the device
> worked as expected.
>
> If I'm not missing an use-case here (pointers?) and there are no complains,
> the attached diff is worth being committed.
>
> --
> Bernhard
>
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Tuesday, January 18, 2011 11:26:58 Alexander Zagrebin wrote: > Hi! > > I'm trying to use the RT2872-based USB adapter in the hostap mode > on the latest RELENG_8 (8.2-PRERELEASE) for amd64. > [..] Pull that http://svn.freebsd.org/viewvc/base?view=revision&revision=217511 and let me know if that fixes the issue. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bug in ieee80211_mesh.c code?
On Monday, January 17, 2011 19:06:39 Monthadar Al Jaberi wrote: > Hi, > > This line 1466 in ieee80211_mesh.c: > frm += frm[2] + 2; > > When I look at the other modes it should be > frm += frm[1] + 2; Seems indeed to be incorrect, after frm += frm[2] + 2, frm will point anywhere but definitely not to the next element. I'll have a look at that. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Wednesday, January 19, 2011 06:35:51 Alexander Zagrebin wrote: > Hi! > > On 18.01.2011 12:31:20 +0100, Bernhard Schmidt wrote: > > > I'm trying to use the RT2872-based USB adapter in the hostap mode > > > on the latest RELENG_8 (8.2-PRERELEASE) for amd64. > > > [..] > > > > Pull that > > http://svn.freebsd.org/viewvc/base?view=revision&revision=217511 > > and let me know if that fixes the issue. > > I've retrieved the ieee80211_node.c and if_run.c and recompiled > wlan.ko and if_run.ko. > > Here results: > > Case 1: both if_run.ko and wlan_amrr.ko are loaded via loader.conf > > stable/8: panic > rev217511: panic > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > creation of the wlan interface > > stable/8: panic on rate control > rev217511: no panic, but rate control doesn't work; tx rate is > fixed on 1 Mbit/s > > Case 3: wlan_amrr.ko loaded _before_ if_run.ko > > stable/8: panic on rate control > rev217511: no panic, rate control works as expected > > So rev217511 partially fixes the issue. That sounds rather weird to me, I can't imagine how the module loading order should make any difference. Well, at least, before creating the VAP, because that is the point where that stuff gets initialized/used. Do you have anything configured in rc.conf maybe? That would create the VAP right after loading if_run.ko even before you are able to load wlan_amrr.ko. I'll have look at that again.. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Wednesday, January 19, 2011 12:23:30 Alexander Zagrebin wrote: > Hi! > > On 19.01.2011 09:37:12 +0100, Bernhard Schmidt wrote: > > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > > > creation of the wlan interface > > > > > > stable/8: panic on rate control > > > rev217511: no panic, but rate control doesn't work; tx rate is > > > > > > fixed on 1 Mbit/s > > > > That sounds rather weird to me, I can't imagine how the module > > loading order should make any difference. Well, at least, before > > creating the VAP, because that is the point where that stuff gets > > initialized/used. > > It seems you're right. I couldn't reproduce it again. > May be I have missed anything. Sorry... Ok, thanks. > > Do you have anything configured in rc.conf maybe? That would create > > the VAP right after loading if_run.ko even before you are able to > > load wlan_amrr.ko. > > Yes, I have wlans_run0="wlan0" and create_args_wlan0=... in the > rc.conf, but while testing I've used `ifconfig wlan0 destroy` after > `kldload if_run`. May be it was mistyping... > Also I've noticed that messages like > "ieee80211_load_module: load the wlan_amrr module by hand for now." > has disappeared from the log. Is it normal? That message only appears if wlan_amrr.ko isn't loaded while creating a VAP. If you do see the message if wlan_amrr.ko is loaded, that'd be a bug, also the other way around. > So there is the one issue only: the panic if runfw.ko and > wlan_amrr.ko both loaded via loader.conf. > Have you any ideas? No yet, I'll dig around there later today. > Will be rev. 217511 MFC'd on the 20 january? Yes, probably in the evening (CET). -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Wednesday 19 January 2011 12:40:15 Bernhard Schmidt wrote: > On Wednesday, January 19, 2011 12:23:30 Alexander Zagrebin wrote: > > Hi! > > > > On 19.01.2011 09:37:12 +0100, Bernhard Schmidt wrote: > > > > Case 2: wlan_amrr.ko loaded manually _after_ if_run.ko but before > > > > creation of the wlan interface > > > > > > > > stable/8: panic on rate control > > > > rev217511: no panic, but rate control doesn't work; tx rate is > > > > > > > > fixed on 1 Mbit/s > > > > > > That sounds rather weird to me, I can't imagine how the module > > > loading order should make any difference. Well, at least, before > > > creating the VAP, because that is the point where that stuff gets > > > initialized/used. > > > > It seems you're right. I couldn't reproduce it again. > > May be I have missed anything. Sorry... > > Ok, thanks. > > > > Do you have anything configured in rc.conf maybe? That would create > > > the VAP right after loading if_run.ko even before you are able to > > > load wlan_amrr.ko. > > > > Yes, I have wlans_run0="wlan0" and create_args_wlan0=... in the > > rc.conf, but while testing I've used `ifconfig wlan0 destroy` after > > `kldload if_run`. May be it was mistyping... > > Also I've noticed that messages like > > "ieee80211_load_module: load the wlan_amrr module by hand for now." > > has disappeared from the log. Is it normal? > > That message only appears if wlan_amrr.ko isn't loaded while creating a > VAP. If you do see the message if wlan_amrr.ko is loaded, that'd be a > bug, also the other way around. > > > So there is the one issue only: the panic if runfw.ko and > > wlan_amrr.ko both loaded via loader.conf. > > Have you any ideas? > > No yet, I'll dig around there later today. Hmm, I'm not able to reproduce this, works as expected. Is this still the same backtrace as the previous error? > > Will be rev. 217511 MFC'd on the 20 january? > > Yes, probably in the evening (CET). > -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bug in ieee80211_mesh.c code?
On Monday 17 January 2011 19:06:39 Monthadar Al Jaberi wrote: > Hi, > > This line 1466 in ieee80211_mesh.c: > frm += frm[2] + 2; > > When I look at the other modes it should be > frm += frm[1] + 2; > > ?? Committed, thanks! -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run and wlan_amrr: kernel panics on 8.2-PRERELEASE amd64
On Thursday, January 20, 2011 12:46:02 Alexander Zagrebin wrote:
> Hi!
>
> On 19.01.2011 17:57:00 +0100, Bernhard Schmidt wrote:
> > > > So there is the one issue only: the panic if runfw.ko and
> > > > wlan_amrr.ko both loaded via loader.conf.
> > > > Have you any ideas?
> > >
> > > No yet, I'll dig around there later today.
> >
> > Hmm, I'm not able to reproduce this, works as expected. Is this
> > still the same backtrace as the previous error?
>
> It seems that no. I've recompiled a kernel with the KDB support and
> got this:
Indeed, thanks!
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x308
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x8030161a
> stack pointer = 0x28:0x80b7ec30
> frame pointer = 0x28:0x80b7ec60
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= resume, IOPL = 0
> current process = 0 (swapper)
> trap number = 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> #0 0x8033408e at kdb_backtrace+0x5e
> #1 0x80303037 at panic+0x187
> #2 0x804cbbd0 at trap_fatal+0x290
> #3 0x804cbfaf at trap_pfault+0x28f
> #4 0x804cc48f at trap+0x3df
> #5 0x804b4594 at calltrap+0x8
> #6 0x8041a4e0 at LibAliasAttachHandlers+0x160
> #7 0x80b71024 at mod_handler+0x14
> #8 0x802f2318 at module_register_init+0xb8
> #9 0x802bdc77 at mi_startup+0x77
> #10 0x80162b3c at btext+0x2c
> Uptime: 1s
> Automatic reboot in 15 seconds - press a key on the console to abort
> --> Press a key on the console to reboot,
> --> or switch off the system now.
>
> I have an 'alias_pptp_load="YES"' in the loader.conf, so I've
> disabled alias_pptp.ko instead of if_run.ko, runfw.ko or
> wlan_amrr.ko, and the system was successfully booted.
> It's very strange...
>
> # kgdb kernel.debug
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details. This GDB was configured as "amd64-marcel-freebsd"...
> (kgdb) list *LibAliasAttachHandlers+0x160
> 0x8041a4e0 is in LibAliasAttachHandlers
> (../../../netinet/libalias/alias_mod.c:84). 79 }
> 80
> 81 static __inline void
> 82 LIBALIAS_WLOCK(void)
> 83 {
> 84 rw_wlock(&handler_rw);
> 85 }
> 86
> 87 static __inline void
> 88 LIBALIAS_WUNLOCK(void)
> (kgdb)
>
> I understand, that it isn't wlan problem now, but may be you have any
> thoughts?
Honestly, no clue, smells like handler_rw isn't initialized. Does
loading libalias.ko before alias_pptp.ko make any difference?
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bwn(4) support for BCM4322 (MacBook WiFi)
On Monday, January 31, 2011 14:14:01 Fraser Tweedale wrote: > I might be fighting a losing battle, but any advice on getting the > Broadcom BCM4322 802.11a/b/g/n working? This chip is found in > Apple's MacBook and probably elsewhere. > > I'm currently running amd64 8.2-RC2. As best as I can see, HEAD has > nothing that RELENG_8_2 doesn't have, as far as bwn(4) is concerned. > > As per the bwn(4) man page, I installed the net/bwn-firmware-kmod > port. The firmware failed to load, giving a "firmware table full" > error. Seems that others had this issue. Bumping the firmware > table size FIRMWARE_MAX in sys/kern/subr_firmware.c was the > suggested workaround; both modules provided by the port - > bwn_v4_lp_ucode.ko and bwn_v4_ucode.ko - now load without error. > > Loading if_bwn.ko yeilds the following on console: > > siba_bwn0: mem 0x9310-0x93103fff irq 18 at device 0.0 > on pci3 siba_bwn0: warn: multiple PCI(E) cores > siba_bwn0: unsupported coreid (USB 2.0 Device) > siba_bwn0: unsupported coreid (unknown) > siba_bwn0: unsupported coreid (Internal Memory) > siba_bwn0: unknown chipid 0x4322 for PLL & PMU init > bwn0 on siba_bwn0 > bwn0: unsupported PHY type (4) > device_attach: bwn0 attach returned 6 > > siba_bwn0 appears in devinfo(8) output but bwn(4) is nowhere to be > found. > > Any suggestions on how to get the card working? I guess you're out of luck here. Neither bwn(4) nor bwi(4) support the bcm4322 variant afaik (Please correct me if I'm wrong..). The only option left is ndis(4). -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote:
> I'm using an Ralink RT2870 based adapter (run(4) driver) in the
> hostap mode. and I've noticed that if_run doesn't support stations
> working in the power save mode (PSM). The reason is in lack of the
> TIM in beacons. The attached patch adds this functionality and
> completely fixes this issue. Despite the fact that patch is working,
> it seems that it needs an additional work. For example, now the
> result of ieee80211_beacon_update is ignored with a corresponding
> message, but may be necessary to process it...
>
> Can somebody review it?
That looks about right, good catch!
Handling ieee80211_beacon_update()'s return value doesn't seem to be
necessary, the mbuf's length is handled in the next few lines of code
anyways, doesn't matter if it changed or not.
Though, I have a some doubts about just restoring bo_flags is enough
(Can't prove that with some obvious code, still..). It feels saner to me
if we just reuse the whole mbuf, similar to what ath(4) does. Can you
look at attached patch? Completely untested, so I'm not sure what does
happen on e.g. changing the SSID.
--
Bernhard
Index: sys/dev/usb/wlan/if_runvar.h
===
--- sys/dev/usb/wlan/if_runvar.h (revision 218083)
+++ sys/dev/usb/wlan/if_runvar.h (working copy)
@@ -121,6 +121,7 @@ struct run_cmdq {
struct run_vap {
struct ieee80211vap vap;
struct ieee80211_beacon_offsets bo;
+ struct mbuf *beacon_mbuf;
int (*newstate)(struct ieee80211vap *,
enum ieee80211_state, int);
Index: sys/dev/usb/wlan/if_run.c
===
--- sys/dev/usb/wlan/if_run.c (revision 218083)
+++ sys/dev/usb/wlan/if_run.c (working copy)
@@ -856,6 +856,8 @@ run_vap_delete(struct ieee80211vap *vap)
RUN_LOCK(sc);
+ m_freem(rvp->beacon_mbuf);
+
rvp_id = rvp->rvp_id;
sc->ratectl_run &= ~(1 << rvp_id);
sc->rvp_bmap &= ~(1 << rvp_id);
@@ -3903,6 +3905,7 @@ run_update_beacon(struct ieee80211vap *vap, int it
struct run_softc *sc = ic->ic_ifp->if_softc;
uint32_t i;
+ setbit(RUN_VAP(vap)->bo.bo_flags, item);
i = RUN_CMDQ_GET(&sc->cmdq_store);
DPRINTF("cmdq_store=%d\n", i);
sc->cmdq[i].func = run_update_beacon_cb;
@@ -3916,6 +3919,7 @@ static void
run_update_beacon_cb(void *arg)
{
struct ieee80211vap *vap = arg;
+ struct run_vap *rvp = RUN_VAP(vap);
struct ieee80211com *ic = vap->iv_ic;
struct run_softc *sc = ic->ic_ifp->if_softc;
struct rt2860_txwi txwi;
@@ -3925,8 +3929,15 @@ run_update_beacon_cb(void *arg)
if (vap->iv_bss->ni_chan == IEEE80211_CHAN_ANYC)
return;
- if ((m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo)) == NULL)
- return;
+ if (&RUN_VAP(vap)->beacon_mbuf == NULL) {
+ m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo);
+ if (m == NULL)
+ return;
+ rvp->beacon_mbuf = m;
+ } else {
+ m = rvp->beacon_mbuf;
+ ieee80211_beacon_update(vap->iv_bss, &rvp->bo, m, 1);
+ }
memset(&txwi, 0, sizeof txwi);
txwi.wcid = 0xff;
@@ -3941,13 +3952,11 @@ run_update_beacon_cb(void *arg)
txwi.flags = RT2860_TX_TS;
txwi.xflags = RT2860_TX_NSEQ;
- run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)->rvp_id),
- (uint8_t *)&txwi, sizeof txwi);
- run_write_region_1(sc, RT2860_BCN_BASE(RUN_VAP(vap)->rvp_id) + sizeof txwi,
+ run_write_region_1(sc, RT2860_BCN_BASE(rvp->rvp_id), (uint8_t *)&txwi,
+ sizeof txwi);
+ run_write_region_1(sc, RT2860_BCN_BASE(rvp->rvp_id) + sizeof txwi,
mtod(m, uint8_t *), (m->m_pkthdr.len + 1) & ~1); /* roundup len */
- m_freem(m);
-
return;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Friday 04 February 2011 12:40:21 Alexander Zagrebin wrote: > Hi! > > On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > > hostap mode. and I've noticed that if_run doesn't support > > > stations working in the power save mode (PSM). The reason is in > > > lack of the TIM in beacons. The attached patch adds this > > > functionality and completely fixes this issue. Despite the fact > > > that patch is working, it seems that it needs an additional > > > work. For example, now the result of ieee80211_beacon_update is > > > ignored with a corresponding message, but may be necessary to > > > process it... > > > > > > Can somebody review it? > > > > That looks about right, good catch! > > > > Handling ieee80211_beacon_update()'s return value doesn't seem to > > be necessary, the mbuf's length is handled in the next few lines > > of code anyways, doesn't matter if it changed or not. > > > > Though, I have a some doubts about just restoring bo_flags is > > enough (Can't prove that with some obvious code, still..). It > > feels saner to me if we just reuse the whole mbuf, similar to what > > ath(4) does. Can you look at attached patch? Completely untested, > > so I'm not sure what does happen on e.g. changing the SSID. > > I've thought about such solution, and it looks more right, but I've > decided just to add ieee80211_beacon_update() to make the patch > clear. I'll try your patch a bit later, but I already have a > question: on the first invocation of the run_update_beacon_cb() only > ieee80211_beacon_alloc() will be called. So dynamic beacon contents > will not updated. Is it a problem? I don't think it is. The work beacon_update does is handling changes to bo_flags, which are only changed through calls to iv_update_beacon(), so this is safe, because the driver itself does change bo_flags which is immediately followed by the beacon update process. There is one expection I'm not sure about how to handle though, slottime. This value might change based on nodes associating and leaving, resulting in a call to ic_updateslot() which is currently commentted out. Basically there needs to be another call to run_update_beacon_cb() in that function, of course based on the current opmode. > Also I have to note, that it seems that other wlan drivers can has > this problem too: only ral's and ath's code uses > ieee80211_beacon_update(). Yeah, true. > Also, I've found a kern/124753. One of > replies contains a log's fragment with many records, like following: > kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps > mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now > queued kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 > now queued kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 > sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 > packets queue But there are no records, which have to be for a PSM > enabled stations: When a beacon is properly updated, then we have to > see records about 1. TIM updating, like > ieee80211_beacon_update: TIM updated, pending 1, off 0, len 1 > 2. poll messages from a stations, like > wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue > empty > > Thanks for your cooperation! You mean there are missing debug messages in net80211/run? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Saturday 05 February 2011 00:06:15 Alexander Zagrebin wrote: > Hi! > > On 04.02.2011 13:14:17 +0100, Bernhard Schmidt wrote: > > > Also I have to note, that it seems that other wlan drivers can > > > has this problem too: only ral's and ath's code uses > > > ieee80211_beacon_update(). > > > > Yeah, true. > > > > > Also, I've found a kern/124753. One of > > > > > > replies contains a log's fragment with many records, like following: > > > kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's > > > in ps > > > > > > mode kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 > > > now queued kernel: ath0: [00:18:41:c0:06:54] save frame with age > > > 0, 2 now queued kernel: ath0: [00:18:41:c0:06:54] power save > > > mode off, 0 sta's in ps mode kernel: ath0: [00:18:41:c0:06:54] > > > flush ps queue, 2 packets queue But there are no records, which > > > have to be for a PSM enabled stations: When a beacon is properly > > > updated, then we have to see records about 1. TIM updating, like > > > > > > ieee80211_beacon_update: TIM updated, pending 1, off 0, len > > > 1 > > > > > > 2. poll messages from a stations, like > > > > > > wlan0: [18:86:ac:10:4b:88] recv ps-poll, send packet, queue > > > > > > empty > > > > > > Thanks for your cooperation! > > > > You mean there are missing debug messages in net80211/run? > > I meant, that when stations in the PSM are handled correctly, then > the log contains a records like this: > > kernel: wlan0: [18:86:ac:10:4b:88] power save mode on, 1 sta's in ps > mode kernel: wlan0: [18:86:ac:10:4b:88] save frame with age 8, 1 now > queued kernel: wlan0: ieee80211_beacon_update: TIM updated, pending > 1, off 0, len 1 kernel: wlan0: [18:86:ac:10:4b:88] recv ps-poll, > send packet, queue empty kernel: wlan0: ieee80211_beacon_update: TIM > updated, pending 0, off 0, len 1 > > But the log's fragment from the kern/124753 doesn't contain records > with the text "...TIM updated..." and "...recv ps-poll...". > I had the very similar records in the log with the unpatched > if_run.c. Ah I see, ok. Added Adrian to CC, he might be interested. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Saturday 05 February 2011 05:45:59 PseudoCylon wrote:
> - Original Message
>
> > From: Bernhard Schmidt
> > To: Alexander Zagrebin
> > Cc: freebsd-net@freebsd.org; PseudoCylon
> > Sent: Fri, February 4, 2011 5:14:17 AM
> > Subject: Re: if_run in hostap mode: issue with stations in the
> > power save mode
> >
> > On Friday 04 February 2011 12:40:21 Alexander Zagrebin wrote:
> > > Hi!
> > >
> > > On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote:
> > > > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote:
> > > > > I'm using an Ralink RT2870 based adapter (run(4) driver) in
> > > > > the hostap mode. and I've noticed that if_run doesn't
> > > > > support stations working in the power save mode (PSM). The
> > > > > reason is in lack of the TIM in beacons. The attached patch
> > > > > adds this functionality and completely fixes this issue.
> > > > > Despite the fact that patch is working, it seems that it
> > > > > needs an additional work. For example, now the result of
> > > > > ieee80211_beacon_update is ignored with a corresponding
> > > > > message, but may be necessary to process it...
> > > > >
> > > > > Can somebody review it?
> > > >
> > > > That looks about right, good catch!
> > > >
> > > > Handling ieee80211_beacon_update()'s return value doesn't seem
> > > > to be necessary, the mbuf's length is handled in the next few
> > > > lines of code anyways, doesn't matter if it changed or not.
> > > >
> > > > Though, I have a some doubts about just restoring bo_flags is
> > > > enough (Can't prove that with some obvious code, still..). It
> > > >
> > > > feels saner to me if we just reuse the whole mbuf, similar to
> > > > what ath(4) does. Can you look at attached patch? Completely
> > > > untested, so I'm not sure what does happen on e.g. changing
> > > > the SSID.
> > >
> > > I've thought about such solution, and it looks more right, but
> > > I've decided just to add ieee80211_beacon_update() to make the
> > > patch clear. I'll try your patch a bit later, but I already
> > > have a question: on the first invocation of the
> > > run_update_beacon_cb() only ieee80211_beacon_alloc() will be
> > > called. So dynamic beacon contents will not updated. Is it a
> > > problem?
> >
> > I don't think it is. The work beacon_update does is handling
> > changes to bo_flags, which are only changed through calls to
> > iv_update_beacon(), so this is safe, because the driver itself
> > does change bo_flags which is immediately followed by the beacon
> > update process.
>
> I like the way mwl(4) handles it.
> http://fxr.watson.org/fxr/source/dev/mwl/if_mwl.c#L1927
> though I don't know why it uses ieee80211_beacon_alloc() instead of
> _update()
>
> @@run_update_beacon(struct ieee80211vap *vap, int item)
> struct run_vap *rvp = RUN_VAP(vap);
> +int mcast = 0;
> uint32_t i;
>
> +KASSERT(vap != NULL, ("no beacon"));
> +
> +switch (item) {
> +case IEEE80211_BEACON_ERP:
> +run_updateslot(ic->ic_ifp);
> +break;
> +case IEEE80211_BEACON_HTINFO:
> +run_updateprot(ic);
> +break;
> +case IEEE80211_BEACON_TIM:
> +mcast = 1;/*TODO*/
> +break;
> +default:
> +break;
> }
>
> +setbit(rvp->bo.bo_flags, item);
> +ieee80211_beacon_update(vap->iv_bss, &rvp->bo, rvp->bm, mcast);
> +
> i = RUN_CMDQ_GET(&sc->cmdq_store);
> DPRINTF("cmdq_store=%d\n", i);
> sc->cmdq[i].func = run_update_beacon_cb;
That looks good, it handles the case about slottime changes i've
mentioned.
> It's been working fine updating protection mode in HT mode past a few
> days. (Some how, iwn(4) works fine with run(4), I cannot tell it
> works fin with power saving mode.)
Afaik iwn(4) doesn't use PS, never got around implementing that.
> I'd like to move ieee80211_beacon_alloc() into iv_vap_alloc(). Then
> we don't need to test beacon_mbuf == NULL in run_update_beacon_cb(),
> and there is already switch we can use for conditionally alloc mem.
Sounds fine with we.
> > There is one expection I'm not sure about how to handle though,
> > slottime. This value might change based on nodes associating and
> > leaving, resulting in a call to ic_updateslot() which is currently
> > commentted out.
>
> That's only because of LOR. I'm adding another call back function
> since run_updateprot() need to be deferred when it is called
> from run_update_beacon().
Great, thanks.
Can I talk you into integrating that into Alexander's patch?
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Friday 04 February 2011 23:33:40 Alexander Zagrebin wrote: > Hi! > > On 04.02.2011 09:51:34 +0100, Bernhard Schmidt wrote: > > On Friday 04 February 2011 07:08:08 Alexander Zagrebin wrote: > > > I'm using an Ralink RT2870 based adapter (run(4) driver) in the > > > hostap mode. and I've noticed that if_run doesn't support > > > stations working in the power save mode (PSM). The reason is in > > > lack of the TIM in beacons. The attached patch adds this > > > functionality and completely fixes this issue. Despite the fact > > > that patch is working, it seems that it needs an additional > > > work. For example, now the result of ieee80211_beacon_update is > > > ignored with a corresponding message, but may be necessary to > > > process it... > > > > > > Can somebody review it? > > > > That looks about right, good catch! > > > > Handling ieee80211_beacon_update()'s return value doesn't seem to > > be necessary, the mbuf's length is handled in the next few lines > > of code anyways, doesn't matter if it changed or not. > > > > Though, I have a some doubts about just restoring bo_flags is > > enough (Can't prove that with some obvious code, still..). It > > feels saner to me if we just reuse the whole mbuf, similar to what > > ath(4) does. Can you look at attached patch? Completely untested, > > so I'm not sure what does happen on e.g. changing the SSID. > > I've tried the slightly modified version of your patch (see attached > files), and found that it is working too. Moreover, it looks more > safe. For example, suppose we need update the beacon due to a new > TIM. Immediately after updating, but before the beacon with a TIM > will be transmitted, we need update the beacon again for any other > reason. With the first version of the patch the beacon will > completely recreated, so a TIM will be lost. But if we are using the > second version of the patch, then TIM will be preserved. Yeah, correct, that was my intention. I see you also fixed the remaining RUN_VAP() calls I've missed, thanks for that. :) > I had the doubts about ability to change or hide/unhide the SSID, but > it works too. It seems that after `ifconfig wlan0 ssid ...` or > `ifconfig wlan0 (hidessid|-hidessid)` the following occurs: > 1. run_newstate() is called > 2. run_newstate() invokes run_update_beacon_cb() > 3. run_update_beacon_cb() invokes ieee80211_beacon_update() > But I couldn't understand where ieee80211_beacon_update() can change > a SSID... As I see it, it can't. Only a call to ieee80211_beacon_construct() would do that. Can I talk you into figuring out what's going on here? Getting a definitive statement about SSID changes are correctly handled (by means of a trace) would help alot. Thanks. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Monday, February 07, 2011 07:10:01 Alexander Zagrebin wrote: > Hi! > > On 06.02.2011 11:32:40 +0100, Bernhard Schmidt wrote: > > > I had the doubts about ability to change or hide/unhide the SSID, > > > but it works too. It seems that after `ifconfig wlan0 ssid ...` > > > or `ifconfig wlan0 (hidessid|-hidessid)` the following occurs: > > > 1. run_newstate() is called > > > 2. run_newstate() invokes run_update_beacon_cb() > > > 3. run_update_beacon_cb() invokes ieee80211_beacon_update() > > > But I couldn't understand where ieee80211_beacon_update() can > > > change a SSID... > > > > As I see it, it can't. Only a call to ieee80211_beacon_construct() > > would do that. Can I talk you into figuring out what's going on > > here? Getting a definitive statement about SSID changes are > > correctly handled (by means of a trace) would help alot. > > Yes, sure! > What kind of information you need? For example, if you call 'ifconfig wlan0 ssid ' the new ssid is passed over using a IOCTL. It would be interesting to know what function in net80211 are called regarding beacon updates and which of those call into the run driver. Ultimately it's about figuring out if special handling for such cases are required and if so, how to do it. Thanks -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Tuesday, February 08, 2011 09:24:29 Alexander Zagrebin wrote: > Hi! > > On 07.02.2011 09:11:02 +0100, Bernhard Schmidt wrote: > > For example, if you call 'ifconfig wlan0 ssid ' the new > > ssid is passed over using a IOCTL. It would be interesting to know > > what function in net80211 are called regarding beacon updates and > > which of those call into the run driver. Ultimately it's about > > figuring out if special handling for such cases are required and > > if so, how to do it. > > I've added a debug output on allocation, changing and deallocation of > a beacon into if_run.c and tried to change SSID while the > net.wlan.0.debug is -1. Here is the log contents: > > kernel: wlan0: ieee80211_init > kernel: wlan0: start running, 1 vaps running > kernel: wlan0: ieee80211_new_state_locked: RUN -> SCAN (nrunning 0 > nscanning 0) kernel: wlan0: ieee80211_newstate_cb: RUN -> INIT arg 0 > kernel: wlan0: hostap_newstate: RUN -> INIT (0) > kernel: wlan0: node_reclaim: remove > 0xff8003bd7000<00:14:d1:a8:66:1d> from station table, refcnt 1 > kernel: wlan0: ieee80211_alloc_node > 0xff8004eae000<00:14:d1:a8:66:1d> in station table kernel: > wlan0: [00:14:d1:a8:66:1d] ieee80211_alloc_node: inact_reload 2 > kernel: wlan0: ieee80211_newstate_cb: INIT -> SCAN arg 0 > kernel: wlan0: hostap_newstate: INIT -> SCAN (0) > kernel: wlan0: ieee80211_create_ibss: creating HOSTAP on channel 6 > kernel: wlan0: ieee80211_alloc_node > 0xff8003bd7000<00:14:d1:a8:66:1d> in station table kernel: > kernel: wlan0: [00:14:d1:a8:66:1d] ieee80211_alloc_node: inact_reload > 2 kernel: wlan0: set WME_AC_BE (chan) [acm 0 aifsn 3 logcwmin 4 > logcwmax 6 txop 0] kernel: wlan0: set WME_AC_BE (bss ) [acm 0 aifsn > 3 logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: set WME_AC_BK (chan) > [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: set > WME_AC_BK (bss ) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0] > kernel: wlan0: set WME_AC_VI (chan) [acm 0 aifsn 1 logcwmin 3 > logcwmax 4 txop 94] kernel: wlan0: set WME_AC_VI (bss ) [acm 0 aifsn > 2 logcwmin 3 logcwmax 4 txop 94] kernel: wlan0: set WME_AC_VO (chan) > [acm 0 aifsn 1 logcwmin 2 logcwmax 3 txop 47] kernel: wlan0: set > WME_AC_VO (bss ) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop 47] > kernel: wlan0: ieee80211_wme_updateparams_locked: WME params > updated, cap_info 0x6 kernel: wlan0: ieee80211_new_state_locked: > SCAN -> RUN (nrunning 0 nscanning 0) kernel: wlan0: > ieee80211_newstate_cb: SCAN -> RUN arg -1 > kernel: run0: run_update_beacon_cb: updating beacon > kernel: wlan0: ieee80211_beacon_update: traffic 0, enable aggressive > mode kernel: wlan0: update WME_AC_BE (chan+bss) [acm 0 aifsn 2 > logcwmin 4 logcwmax 10 txop 0] kernel: wlan0: update WME_AC_BE > (chan+bss) logcwmin 3 > kernel: wlan0: ieee80211_wme_updateparams_locked: WME params updated, > cap_info 0x7 kernel: wlan0: hostap_newstate: SCAN -> RUN (-1) > kernel: wlan0: synchronized with 00:14:d1:a8:66:1d ssid "test" > channel 6 start 0Mb kernel: wlan0: [00:14:d1:a8:66:1d] > ieee80211_node_authorize: inact_reload 20 > > As you can see, run_update_beacon_cb() is invoked, but at this time > the beacon is already allocated. As the beacon is allocated, > run_update_beacon_cb() invokes ieee80211_beacon_update(). As we > know, the ieee80211_beacon_update() doesn't update the SSID, so the > SSID remains untouched. > Nevertheless the changing or hiding/unhiding a SSID seems to be > working. It is possible to explain: the station uses an active scan. > The ieee80211_send_proberesp()/ieee80211_alloc_proberesp() returns > the frame, containing an updated SSID, but AP continues to broadcast > beacon with the outdated data. > The possible solution is to deallocate a beacon on a state change. > I've decided to deallocate a beacon on 'to RUN' state transition. > The additional patch is attached. > I'll do an additional tests later today... Thank you. That's what I expected actually, when we are going through state changes (RUN -> ... -> RUN) net80211 expects us to throw most knowledge we have aways. This seems to be safest solution. When the beacon mbuf is completely thrown away and created from scratch we can be absolutely sure we handled all cases. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: if_run in hostap mode: issue with stations in the power save mode
On Tuesday, February 08, 2011 02:18:30 PseudoCylon wrote:
> - Original Message
>
> > From: Bernhard Schmidt
> > To: PseudoCylon
> > Cc: Alexander Zagrebin ; freebsd-net@freebsd.org
> > Sent: Sun, February 6, 2011 3:42:43 AM
> > Subject: Re: if_run in hostap mode: issue with stations in the
> > power save mode
>
> Afaik iwn(4) doesn't use PS, never got around implementing that.
>
> > > I'd like to move ieee80211_beacon_alloc() into iv_vap_alloc().
> > > Then we don't need to test beacon_mbuf == NULL in
> > > run_update_beacon_cb(), and there is already switch we can use
> > > for conditionally alloc mem.
> >
> > Sounds fine with we.
>
> Oops, there is switch before malloc vap. the test is still
> in run_update_beacon_cb()
>
> > Can I talk you into integrating that into Alexander's patch?
>
> The patch is attached. (diff to HEAD) Bit long, just because there is
> a couple of new call back functions to avoid LOR.
Thank you!
I've combined both patches (see attachment), if I get an ACK from both
of you I'll try get this into the tree ASAP.
--
Bernhard
Index: sys/dev/usb/wlan/if_runvar.h
===
--- sys/dev/usb/wlan/if_runvar.h (revision 218367)
+++ sys/dev/usb/wlan/if_runvar.h (working copy)
@@ -121,6 +121,7 @@ struct run_cmdq {
struct run_vap {
struct ieee80211vap vap;
struct ieee80211_beacon_offsets bo;
+ struct mbuf *beacon_mbuf;
int (*newstate)(struct ieee80211vap *,
enum ieee80211_state, int);
Index: sys/dev/usb/wlan/if_run.c
===
--- sys/dev/usb/wlan/if_run.c (revision 218367)
+++ sys/dev/usb/wlan/if_run.c (working copy)
@@ -388,6 +388,7 @@ static void run_scan_end(struct ieee80211com *);
static void run_update_beacon(struct ieee80211vap *, int);
static void run_update_beacon_cb(void *);
static void run_updateprot(struct ieee80211com *);
+static void run_updateprot_cb(void *);
static void run_usb_timeout_cb(void *);
static void run_reset_livelock(struct run_softc *);
static void run_enable_tsf_sync(struct run_softc *);
@@ -398,6 +399,7 @@ static void run_set_leds(struct run_softc *, uint1
static void run_set_bssid(struct run_softc *, const uint8_t *);
static void run_set_macaddr(struct run_softc *, const uint8_t *);
static void run_updateslot(struct ifnet *);
+static void run_updateslot_cb(void *);
static void run_update_mcast(struct ifnet *);
static int8_t run_rssi2dbm(struct run_softc *, uint8_t, uint8_t);
static void run_update_promisc_locked(struct ifnet *);
@@ -674,7 +676,7 @@ run_attach(device_t self)
ic->ic_set_channel = run_set_channel;
ic->ic_node_alloc = run_node_alloc;
ic->ic_newassoc = run_newassoc;
- //ic->ic_updateslot = run_updateslot;
+ ic->ic_updateslot = run_updateslot;
ic->ic_update_mcast = run_update_mcast;
ic->ic_wme.wme_update = run_wme_update;
ic->ic_raw_xmit = run_raw_xmit;
@@ -856,6 +858,9 @@ run_vap_delete(struct ieee80211vap *vap)
RUN_LOCK(sc);
+ m_freem(rvp->beacon_mbuf);
+ rvp->beacon_mbuf = NULL;
+
rvp_id = rvp->rvp_id;
sc->ratectl_run &= ~(1 << rvp_id);
sc->rvp_bmap &= ~(1 << rvp_id);
@@ -1790,6 +1795,9 @@ run_newstate(struct ieee80211vap *vap, enum ieee80
sc->runbmap |= bid;
}
+ m_freem(rvp->beacon_mbuf);
+ rvp->beacon_mbuf = NULL;
+
switch (vap->iv_opmode) {
case IEEE80211_M_HOSTAP:
case IEEE80211_M_MBSS:
@@ -3901,8 +3909,29 @@ run_update_beacon(struct ieee80211vap *vap, int it
{
struct ieee80211com *ic = vap->iv_ic;
struct run_softc *sc = ic->ic_ifp->if_softc;
+ struct run_vap *rvp = RUN_VAP(vap);
+ int mcast = 0;
uint32_t i;
+ KASSERT(vap != NULL, ("no beacon"));
+
+ switch (item) {
+ case IEEE80211_BEACON_ERP:
+ run_updateslot(ic->ic_ifp);
+ break;
+ case IEEE80211_BEACON_HTINFO:
+ run_updateprot(ic);
+ break;
+ case IEEE80211_BEACON_TIM:
+ mcast = 1; /*TODO*/
+ break;
+ default:
+ break;
+ }
+
+ setbit(rvp->bo.bo_flags, item);
+ ieee80211_beacon_update(vap->iv_bss, &rvp->bo, rvp->beacon_mbuf, mcast);
+
i = RUN_CMDQ_GET(&sc->cmdq_store);
DPRINTF("cmdq_store=%d\n", i);
sc->cmdq[i].func = run_update_beacon_cb;
@@ -3916,6 +3945,7 @@ static void
run_update_beacon_cb(void *arg)
{
struct ieee80211vap *vap = arg;
+ struct run_vap *rvp = RUN_VAP(vap);
struct ieee80211com *ic = vap->iv_ic;
struct run_softc *sc = ic->ic_ifp->if_softc;
struct rt2860_txwi txwi;
@@ -3925,8 +3955,17 @@ run_update_beacon_cb(void *arg)
if (vap->iv_bss->ni_chan == IEEE80211_CHAN_ANYC)
return;
- if ((m = ieee80211_beacon_alloc(vap->iv_bss, &RUN_VAP(vap)->bo))
Re: if_run in hostap mode: issue with stations in the power save mode
On Tuesday 08 February 2011 10:52:53 Bernhard Schmidt wrote: > I've combined both patches (see attachment), if I get an ACK from both > of you I'll try get this into the tree ASAP. Committed, thanks! -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 80211s HWMP problem
On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: > Hej, wanna check if anyone encountered this problem: > I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) > > But I cant ping from 3 to 0, or 0 to 3, without first ping between > the nodes to fill the hwmp route tables. Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes works though? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 80211s HWMP problem
On Thursday, February 10, 2011 11:42:05 Monthadar Al Jaberi wrote: > Okej, I run all four scenarios: > > 0->2 OK, but the first "ping -c 1" got lost > 1->3 OK, > 2->0 OK, > 3->1 FAIL, works after "ping -c 1" 1->2 > > looks like path is built correct in one way only? :S I have no clue about the mesh code.. but, that smells like there are a few frames discard which are supposed to fill the ARP table. Can I talk you into dumping frames on the interfaces to figure out where those discards happen? > On Thu, Feb 10, 2011 at 11:19 AM, Bernhard Schmidt wrote: > > On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: > >> Hej, wanna check if anyone encountered this problem: > >> I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) > >> > >> But I cant ping from 3 to 0, or 0 to 3, without first ping between > >> the nodes to fill the hwmp route tables. > > > > Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes > > works though? > > > > -- > > Bernhard -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Radiotap, BPF, and related system calls
On Sunday 20 February 2011 23:56:31 Adam Stylinski wrote: > Hello, > > I'm somewhat of a novice C programmer endeavoring in a project to > write my own protocol which will sit on top of the 1480 byte 802.3 > frames (which are on top of 802.11 frames) to accomplish remote file > transmission. The communication will be one way, but one roadblock > I'm running into is discovering the exact system calls I have to > make to send raw frames. I want to work on the higher level API as > opposed to the kernel level (for one I'd like the 802.11 layer to > auto fragment the 802.3 frames for me). The exact protocol will > require two cards in monitor mode so that raw injection and blind > reception can occur. Control signals will be transmitted over a TCP > socket via the internet. I've found documentation that points to > the system independent radiotap specification, and from there I've > seen documentation which talks about initializing the ioctl through > a BPF clone to be utilized by userland applications. I'm sure that > wireshark and other wireless utilities use this, but there is a boat > load of code I've been looking through to find the precise call > which opens up the device ioctl, initiates the the tap, and gives me > simple functions to construct and transmit my simple frames. I've > found in the headers many references to the structs themselves, but > I'm not sure where to start to initiate communication through the > device. Any 802.11 experts on this list that could perhaps give me > some specific instruction or point me to a man page / example code > which does this? > > Thanks in advance for whatever you can offer me. You might want to have a look at tools/tools/net80211/wlaninject, the code there is supposed to inject raw frames into any 802.11 VAP. On a side note, you want to use ahdemo mode for packet injection, not monitor mode. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD TDMA kernel PANIC
On Tuesday, March 01, 2011 03:49:41 Kyungsoo Lee wrote: > Hi, > > whenever I try to set my mini PCI-e card (Anatel AR5BXB6) as Master > (tdmaslot 0), kernel shows PANIC msg like the below. > It's OK when I set the card as not Master like tdmalsot 1,2, and more. What > is the problem? And how can I fix it? > > Interestingly, the kernel PANIC occurs when I use this card with IBM T60. > When I use this card with IBM T61, there is no PANIC message like the below. > Instead, kernel shows never ending "Ath0: Stuck beacon; bmiss..." messages. > > How can I solve the problem? I searched but it is hard to find the answer > for my cases. The panic doesn't seem to be related to ath(4) or do you see ath or wlan in the backtrace? Adrian fixed a few issues regarding stuck beacons in head, you might wanna try this. Also, your last post said you configured the device with % ifconfig wlan0 create wlandev ath0 wlanmode tdma tdmaslot 0 up This is either not the whole truth or you should definitely set a SSID as otherwise no network will be opened. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: dhclient (possibly all networking) not working with some routers and WPA
On Wednesday, March 09, 2011 02:00:40 Michael wrote: > Hi, > > I'm running FreeBSD 8.1-Release with ath0 card. For some unknown reason > this laptop is not able to get IP address from my access point (DHCP) if > WPA encryption is enabled. > > The tricky part is that it says it is associated but has IP of 0.0.0.0. > So it looks like encryption part is working and then other communication > fails. > > Everything works fine if I switch the encryption off. > The same station works fine with other access points. Other operating > systems works fine on the same station with the same access point. And > the same access point works fine with other stations. > In short - it's only FreeBSD that is having problems in this setup. > > What I have tried and it didn't help: > - using FreeBSD 8.0-R and 8.1-R > - using isc-dhcp41-client and isc-dhcp31-client from ports > - turning on/off different QoS settings on the access point > - adding my station to static IP table on the access point > - configuring ip address, netmask and routing table manually on my > station with DHCP server both enabled and disabled > - using different access points - two out of four are not working, all > different makes and models > > [..] > > I'm quite desperate to get it fixed so any ideas/suggestions appreciated. Do I get that right? You've tried setting a fixed IP? Can you also run tcpdump on a remote side? How does your wpa_supplicant.conf look like? Do you have any other device available? an USB wlan stick or something to rule out the Atheros hardware. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: dhclient (possibly all networking) not working with some routers and WPA
On Wednesday, March 09, 2011 02:00:40 Michael wrote: > Hi, > > I'm running FreeBSD 8.1-Release with ath0 card. For some unknown reason > this laptop is not able to get IP address from my access point (DHCP) if > WPA encryption is enabled. > > The tricky part is that it says it is associated but has IP of 0.0.0.0. > So it looks like encryption part is working and then other communication > fails. > > Everything works fine if I switch the encryption off. > The same station works fine with other access points. Other operating > systems works fine on the same station with the same access point. And > the same access point works fine with other stations. > In short - it's only FreeBSD that is having problems in this setup. Was talking with Adrian about that after remembering the famous keycache issue. There are some fixes for that in HEAD, can I talk you into trying HEAD? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: dhclient (possibly all networking) not working with some routers and WPA
On Wednesday, March 09, 2011 10:14:23 Michael wrote: > On 09/03/2011 09:02, Bernhard Schmidt wrote: > > On Wednesday, March 09, 2011 02:00:40 Michael wrote: > >> Hi, > >> > >> I'm running FreeBSD 8.1-Release with ath0 card. For some unknown reason > >> this laptop is not able to get IP address from my access point (DHCP) if > >> WPA encryption is enabled. > >> > >> The tricky part is that it says it is associated but has IP of 0.0.0.0. > >> So it looks like encryption part is working and then other communication > >> fails. > >> > >> Everything works fine if I switch the encryption off. > >> The same station works fine with other access points. Other operating > >> systems works fine on the same station with the same access point. And > >> the same access point works fine with other stations. > >> In short - it's only FreeBSD that is having problems in this setup. > > > > Was talking with Adrian about that after remembering the famous > > keycache issue. There are some fixes for that in HEAD, can I talk you > > into trying HEAD? > > > > Absolutely yes. As I said I am really keen to get it sorted. I have > spent quite a lot of money on two different wireless routers (in 6 > months time, two different locations) that doesn't work wireless with my > FreeBSD laptop - bummer. > Is there some image file I can download and install or do I have to > compile the whole thing from sources? There are snapshots available: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201102/ Maybe the livefs iso is enough for giving this a shot, dunno. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mac_acl - how to get a list of allowed stations
On Wednesday, March 30, 2011 07:24:40 Michael wrote: > Hi, > > To get MAC ACL I'm using wlan_acl and I'm adding stations with "ifconfig > mac:add" command. It works but how can I get a list of currently > allowed/denied stations? Without actually trying this, I'd say the "list" command is what you are looking for. # ifconfig wlan0 list mac -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net80211 and interface requests
On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote: > Hello, > > This list has helped me before so I'll email again with the hopes that > somebody has an answer. All is working well with my project, however for > the life of me I cannot get the interface to inject the raw frames faster > than 11mbps. I'm following the example given in > /usr/src/tools/tools/net80211/wlaninject.c, and manually specifying > parameters such as ucastrate, mcastrate, and mgmtrate within ifconfig. I'm > putting the card into pureg mode, and yet I still can't inject any faster. > I've even gone so far as to specify an ieee802211_txparam struct giving > values of 255 both mcast and ucast rates within the struct (and of course > anding them by 0xff). I then used the ioctl call to set the flags within > the interface request. Any help would be greatly appreciated. You've set the ibp_rate0 parameter right? This one is in half-mbps, so a value of 108 should give you 54m. The only thing I can think of right now is that the device (or channel) is actually configured for 11b not 11g mode. Can we rule that out? Which device are you using? > I am doing nanosleeps in between transmissions as if I don't the bpf clone > can't inject due to the buffer being too full. There's probably a better > way of doing this, but I doubt the nanosleeps are the issue (afterall, I get > almost exactly 11mbps). I should probably note I'm not doing any ACKs, this > is pure transmits. > > If anybody cares enough to look at my unpolished code to get a better idea, > look here: > > http://projhinternet.svn.sourceforge.net/ > > The idea is to allow unidirectional traffic so that with an FCC amateur > license (yes I know I'm not currently broadcasting the call sign as of yet) > you can broadcast unencrypted transmissions for miles (with a linear > amplifier spec'd to 2.4ghz). With the license FCC part15 no longer applies > and you can operate just like in any other amateur band. > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net80211 and interface requests
On Thursday, March 31, 2011 14:20:33 Adam Stylinski wrote: > On Thu, Mar 31, 2011 at 09:02:45AM +0200, Bernhard Schmidt wrote: > > On Wednesday, March 30, 2011 23:17:53 Adam Stylinski wrote: > > > Hello, > > > > > > This list has helped me before so I'll email again with the hopes that > > > somebody has an answer. All is working well with my project, however for > > > the life of me I cannot get the interface to inject the raw frames faster > > > than 11mbps. I'm following the example given in > > > /usr/src/tools/tools/net80211/wlaninject.c, and manually specifying > > > parameters such as ucastrate, mcastrate, and mgmtrate within ifconfig. > > > I'm > > > putting the card into pureg mode, and yet I still can't inject any faster. > > > I've even gone so far as to specify an ieee802211_txparam struct giving > > > values of 255 both mcast and ucast rates within the struct (and of course > > > anding them by 0xff). I then used the ioctl call to set the flags within > > > the interface request. Any help would be greatly appreciated. > > > > You've set the ibp_rate0 parameter right? This one is in half-mbps, so > > a value of 108 should give you 54m. The only thing I can think of right > > now is that the device (or channel) is actually configured for 11b not > > 11g mode. Can we rule that out? Which device are you using? > > > > > I am doing nanosleeps in between transmissions as if I don't the bpf clone > > > can't inject due to the buffer being too full. There's probably a better > > > way of doing this, but I doubt the nanosleeps are the issue (afterall, I > > > get > > > almost exactly 11mbps). I should probably note I'm not doing any ACKs, > > > this > > > is pure transmits. > > > > > > If anybody cares enough to look at my unpolished code to get a better > > > idea, > > > look here: > > > > > > http://projhinternet.svn.sourceforge.net/ > > > > > > The idea is to allow unidirectional traffic so that with an FCC amateur > > > license (yes I know I'm not currently broadcasting the call sign as of > > > yet) > > > you can broadcast unencrypted transmissions for miles (with a linear > > > amplifier spec'd to 2.4ghz). With the license FCC part15 no longer > > > applies > > > and you can operate just like in any other amateur band. > > > ___ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > > > > > I'm using an atheros AR2413 chipset, running in pure g mode, with also the > card put into "mode 11g" and ucast, mcast, and mgmt rates set to 54. I think > the parameter for ibp_rate0 is just for setting it in the header (but I could > be wrong). Regardless I am doing this, let me give you the exact source > files I'm doing this in. Well, the ath_rate_* modules afaik do not honor the fixed rate settings. At least I've heard something about those being broken. The ibp_rate0 parameter set to 108 seems to be correct though. No clue why that doesn't work, you may have to debug ath_tx_findrix(). Adding a printf of the passed over rate and ridx should shed some light on this I guess. > Line 38 in this file: > http://projhinternet.svn.sourceforge.net/viewvc/projhinternet/src/callbacks.c?revision=69&view=markup > > > And the setup_if function in this: > http://projhinternet.svn.sourceforge.net/viewvc/projhinternet/src/libinject.c?revision=69&view=markup > -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ral(4) - RT2560 + RF5222 does it exist?
Hi, while working on getting RT2860 (and friends) support ported over from OpenBSD I've noticed that Damien has removed a few bits related to 5GHz support for RT2560 series chips (about 4 years ago). It looks like the code is not complete to handle 11a channels on hardware which seems to not even exist. Is anyone aware of such cards? I haven't found any.. So, while bringing in a bunch of other fixes, I'd also remove those bits if no one jumps in with such a card. Note, only the RT2560 is affected by this not the RT2x61. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
CFT: 11n support for iwn(4)
Hi, I finally managed to get the 11n bits for iwn(4) sorted out. Well, there is still an issue somewhere with HT40 frame protection or TX chain setup on 5000 adapters, resulting in throughput not being that stable. But overall it seems to work pretty decently This is for HEAD only right now, net80211 in stable/8 does not yet contain the latest 11n related fixes. So, if you run HEAD and have some iwn(4) hardware, I'd appreciate feedback. Some statistically irrelevant numbers on a 4965 adapter: UDP RX on 5GHz/HT40: [ 3] 0.0-30.0 sec 866 MBytes 242 Mbits/sec 0.130 ms UDP TX on 5GHz/HT40: [ 3] 0.0-30.3 sec 846 MBytes 235 Mbits/sec 15.081 ms TCP RX on 5GHz/HT40: [ 3] 0.0-30.0 sec 554 MBytes 155 Mbits/sec TCP TX on 5GHz/HT40: [ 4] 0.0-30.0 sec 585 MBytes 164 Mbits/sec UDP RX on 2GHz/HT20 (4965 has no HT40 support on 2GHz): [ 3] 0.0-30.1 sec 383 MBytes 107 Mbits/sec 0.201 ms UDP TX on 2GHz/HT20: [ 3] 0.0-30.3 sec 350 MBytes 97.0 Mbits/sec 11.965 ms -- Bernhard diff --git a/sys/dev/iwn/if_iwn.c b/sys/dev/iwn/if_iwn.c index 7d6ec68..e2cf4be 100644 --- a/sys/dev/iwn/if_iwn.c +++ b/sys/dev/iwn/if_iwn.c @@ -152,9 +152,7 @@ static void iwn4965_print_power_group(struct iwn_softc *, int); static void iwn5000_read_eeprom(struct iwn_softc *); static uint32_t iwn_eeprom_channel_flags(struct iwn_eeprom_chan *); static void iwn_read_eeprom_band(struct iwn_softc *, int); -#if 0 /* HT */ static void iwn_read_eeprom_ht40(struct iwn_softc *, int); -#endif static void iwn_read_eeprom_channels(struct iwn_softc *, int, uint32_t); static struct iwn_eeprom_chan *iwn_find_eeprom_channel(struct iwn_softc *, struct ieee80211_channel *); @@ -172,10 +170,8 @@ static void iwn_rx_phy(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); static void iwn_rx_done(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); -#if 0 /* HT */ static void iwn_rx_compressed_ba(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); -#endif static void iwn5000_rx_calib_results(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); static void iwn_rx_statistics(struct iwn_softc *, struct iwn_rx_desc *, @@ -186,6 +182,7 @@ static void iwn5000_tx_done(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); static void iwn_tx_done(struct iwn_softc *, struct iwn_rx_desc *, int, uint8_t); +static void iwn_ampdu_tx_done(struct iwn_softc *, int, int, int, void *); static void iwn_cmd_done(struct iwn_softc *, struct iwn_rx_desc *); static void iwn_notif_intr(struct iwn_softc *); static void iwn_wakeup_intr(struct iwn_softc *); @@ -199,7 +196,6 @@ static void iwn5000_update_sched(struct iwn_softc *, int, int, uint8_t, #ifdef notyet static void iwn5000_reset_sched(struct iwn_softc *, int, int); #endif -static uint8_t iwn_plcp_signal(int); static int iwn_tx_data(struct iwn_softc *, struct mbuf *, struct ieee80211_node *); static int iwn_tx_data_raw(struct iwn_softc *, struct mbuf *, @@ -252,24 +248,26 @@ static uint8_t *ieee80211_add_ssid(uint8_t *, const uint8_t *, u_int); static int iwn_scan(struct iwn_softc *); static int iwn_auth(struct iwn_softc *, struct ieee80211vap *vap); static int iwn_run(struct iwn_softc *, struct ieee80211vap *vap); -#if 0 /* HT */ -static int iwn_ampdu_rx_start(struct ieee80211com *, - struct ieee80211_node *, uint8_t); -static void iwn_ampdu_rx_stop(struct ieee80211com *, - struct ieee80211_node *, uint8_t); +static int iwn_ampdu_rx_start(struct ieee80211_node *, + struct ieee80211_rx_ampdu *, int, int, int); +static void iwn_ampdu_rx_stop(struct ieee80211_node *, + struct ieee80211_rx_ampdu *); +static int iwn_addba_request(struct ieee80211_node *, + struct ieee80211_tx_ampdu *, int, int, int); +static int iwn_addba_response(struct ieee80211_node *, + struct ieee80211_tx_ampdu *, int, int, int); static int iwn_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *, uint8_t); -static void iwn_ampdu_tx_stop(struct ieee80211com *, - struct ieee80211_node *, uint8_t); +static void iwn_ampdu_tx_stop(struct ieee80211_node *, + struct ieee80211_tx_ampdu *); static void iwn4965_ampdu_tx_start(struct iwn_softc *, - struct ieee80211_node *, uint8_t, uint16_t); -static void iwn4965_ampdu_tx_stop(struct iwn_softc *, + struct ieee80211_node *, int, uint8_t, uint16_t); +static void iwn4965_ampdu_tx_stop(struct iwn_softc *, int, uint8_t, uint16_t); static void iwn5000_ampdu_tx_start(struct iwn_softc *, - struct ieee80211_node *, uint8_t, uint16_t); -static void iwn5000_ampdu_tx_stop(struct iwn_softc *, + struct ieee80211_node *, int, uint8_t, uint16_t); +static void iwn5000_ampdu_tx_stop(struct iwn_softc *, int, uint8_t, uint16_t); -#endif static int iwn5000_query_calibration(struct iwn_softc *); static int iwn5000_send_calibration(struct iwn_softc *); static int iwn5000_send_wimax_coex(s
Re: CFT: 11n support for iwn(4)
On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote: > Hi, > > I finally managed to get the 11n bits for iwn(4) sorted out. Well, > there is still an issue somewhere with HT40 frame protection or > TX chain setup on 5000 adapters, resulting in throughput not being > that stable. But overall it seems to work pretty decently > > This is for HEAD only right now, net80211 in stable/8 does not yet > contain the latest 11n related fixes. So, if you run HEAD and have > some iwn(4) hardware, I'd appreciate feedback. > .. Updated version, I've missed a locking issue. -- Bernhard diff --git a/sys/dev/iwn/if_iwn.c b/sys/dev/iwn/if_iwn.c index 7d6ec68..e2cf4be 100644 --- a/sys/dev/iwn/if_iwn.c +++ b/sys/dev/iwn/if_iwn.c @@ -152,9 +152,7 @@ static void iwn4965_print_power_group(struct iwn_softc *, int); static void iwn5000_read_eeprom(struct iwn_softc *); static uint32_t iwn_eeprom_channel_flags(struct iwn_eeprom_chan *); static void iwn_read_eeprom_band(struct iwn_softc *, int); -#if 0 /* HT */ static void iwn_read_eeprom_ht40(struct iwn_softc *, int); -#endif static void iwn_read_eeprom_channels(struct iwn_softc *, int, uint32_t); static struct iwn_eeprom_chan *iwn_find_eeprom_channel(struct iwn_softc *, struct ieee80211_channel *); @@ -172,10 +170,8 @@ static void iwn_rx_phy(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); static void iwn_rx_done(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); -#if 0 /* HT */ static void iwn_rx_compressed_ba(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); -#endif static void iwn5000_rx_calib_results(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); static void iwn_rx_statistics(struct iwn_softc *, struct iwn_rx_desc *, @@ -186,6 +182,7 @@ static void iwn5000_tx_done(struct iwn_softc *, struct iwn_rx_desc *, struct iwn_rx_data *); static void iwn_tx_done(struct iwn_softc *, struct iwn_rx_desc *, int, uint8_t); +static void iwn_ampdu_tx_done(struct iwn_softc *, int, int, int, void *); static void iwn_cmd_done(struct iwn_softc *, struct iwn_rx_desc *); static void iwn_notif_intr(struct iwn_softc *); static void iwn_wakeup_intr(struct iwn_softc *); @@ -199,7 +196,6 @@ static void iwn5000_update_sched(struct iwn_softc *, int, int, uint8_t, #ifdef notyet static void iwn5000_reset_sched(struct iwn_softc *, int, int); #endif -static uint8_t iwn_plcp_signal(int); static int iwn_tx_data(struct iwn_softc *, struct mbuf *, struct ieee80211_node *); static int iwn_tx_data_raw(struct iwn_softc *, struct mbuf *, @@ -252,24 +248,26 @@ static uint8_t *ieee80211_add_ssid(uint8_t *, const uint8_t *, u_int); static int iwn_scan(struct iwn_softc *); static int iwn_auth(struct iwn_softc *, struct ieee80211vap *vap); static int iwn_run(struct iwn_softc *, struct ieee80211vap *vap); -#if 0 /* HT */ -static int iwn_ampdu_rx_start(struct ieee80211com *, - struct ieee80211_node *, uint8_t); -static void iwn_ampdu_rx_stop(struct ieee80211com *, - struct ieee80211_node *, uint8_t); +static int iwn_ampdu_rx_start(struct ieee80211_node *, + struct ieee80211_rx_ampdu *, int, int, int); +static void iwn_ampdu_rx_stop(struct ieee80211_node *, + struct ieee80211_rx_ampdu *); +static int iwn_addba_request(struct ieee80211_node *, + struct ieee80211_tx_ampdu *, int, int, int); +static int iwn_addba_response(struct ieee80211_node *, + struct ieee80211_tx_ampdu *, int, int, int); static int iwn_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *, uint8_t); -static void iwn_ampdu_tx_stop(struct ieee80211com *, - struct ieee80211_node *, uint8_t); +static void iwn_ampdu_tx_stop(struct ieee80211_node *, + struct ieee80211_tx_ampdu *); static void iwn4965_ampdu_tx_start(struct iwn_softc *, - struct ieee80211_node *, uint8_t, uint16_t); -static void iwn4965_ampdu_tx_stop(struct iwn_softc *, + struct ieee80211_node *, int, uint8_t, uint16_t); +static void iwn4965_ampdu_tx_stop(struct iwn_softc *, int, uint8_t, uint16_t); static void iwn5000_ampdu_tx_start(struct iwn_softc *, - struct ieee80211_node *, uint8_t, uint16_t); -static void iwn5000_ampdu_tx_stop(struct iwn_softc *, + struct ieee80211_node *, int, uint8_t, uint16_t); +static void iwn5000_ampdu_tx_stop(struct iwn_softc *, int, uint8_t, uint16_t); -#endif static int iwn5000_query_calibration(struct iwn_softc *); static int iwn5000_send_calibration(struct iwn_softc *); static int iwn5000_send_wimax_coex(struct iwn_softc *); @@ -550,21 +548,6 @@ iwn_attach(device_t dev) /* Clear pending interrupts. */ IWN_WRITE(sc, IWN_INT, 0x); - /* Count the number of available chains. */ - sc->ntxchains = - ((sc->txchainmask >> 2) & 1) + - ((sc->txchainmask >> 1) & 1) + - ((sc->txchainmask >> 0) & 1); - sc->nrxchains = - ((s
Re: CFT: 11n support for iwn(4)
On Sunday, May 01, 2011 23:36:56 Brandon Gooch wrote: > On Sun, May 1, 2011 at 8:24 AM, Bernhard Schmidt wrote: > > On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote: > >> Hi, > >> > >> I finally managed to get the 11n bits for iwn(4) sorted out. Well, > >> there is still an issue somewhere with HT40 frame protection or > >> TX chain setup on 5000 adapters, resulting in throughput not being > >> that stable. But overall it seems to work pretty decently > >> > >> This is for HEAD only right now, net80211 in stable/8 does not yet > >> contain the latest 11n related fixes. So, if you run HEAD and have > >> some iwn(4) hardware, I'd appreciate feedback. > >> .. > > > > Updated version, I've missed a locking issue. > > > > -- > > Bernhard > > Thanks for working on this Bernhard! > > Unfortunately, I'm having trouble achieving HT rates. > > After 'wlandebug 0x', lots of: > ... > May 1 14:38:15 x300 kernel: wlan0: received beacon from > 00:1d:0f:d3:fb:cc rssi 47 > May 1 14:38:15 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard beacon > frame, ie too short, got 26, expected 30 > ... > > I've attached relevant debugging information, but let me know if there > may be anything else that could help. I need to work on DTracing > net80211, any tips on relevant function traces? Attachment seems to be missing? I'd start of with enabling bootverbose to figure out if your adapter supports 11n at all. There are some where the 11n bits have been disabled. Next thing would be to check with % ifconfig -v wlan0 list chan if the HT channel setup works, if so it should list several HT20/HT40 channels. With % wlanconfig +11n you should at least see something like "Switching channel to HT20" right before moving into RUN state. Also, does % ifconfig wlan0 list scan show HTCAP for the AP you're associating too? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CFT: 11n support for iwn(4)
On Monday, May 02, 2011 09:34:31 Brandon Gooch wrote: > 2011/5/2 Bernhard Schmidt : > > On Sunday, May 01, 2011 23:36:56 Brandon Gooch wrote: > >> On Sun, May 1, 2011 at 8:24 AM, Bernhard Schmidt > >> wrote: > >> > On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote: > >> >> Hi, > >> >> > >> >> I finally managed to get the 11n bits for iwn(4) sorted out. Well, > >> >> there is still an issue somewhere with HT40 frame protection or > >> >> TX chain setup on 5000 adapters, resulting in throughput not being > >> >> that stable. But overall it seems to work pretty decently > >> >> > >> >> This is for HEAD only right now, net80211 in stable/8 does not yet > >> >> contain the latest 11n related fixes. So, if you run HEAD and have > >> >> some iwn(4) hardware, I'd appreciate feedback. > >> >> .. > >> > > >> > Updated version, I've missed a locking issue. > >> > > >> > -- > >> > Bernhard > >> > >> Thanks for working on this Bernhard! > >> > >> Unfortunately, I'm having trouble achieving HT rates. > >> > >> After 'wlandebug 0x', lots of: > >> ... > >> May 1 14:38:15 x300 kernel: wlan0: received beacon from > >> 00:1d:0f:d3:fb:cc rssi 47 > >> May 1 14:38:15 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard beacon > >> frame, ie too short, got 26, expected 30 > >> ... > >> > >> I've attached relevant debugging information, but let me know if there > >> may be anything else that could help. I need to work on DTracing > >> net80211, any tips on relevant function traces? > > > > Attachment seems to be missing? > > I'll send the attachment again, directly to you, bypassing the list... > > > I'd start of with enabling bootverbose to figure out if your adapter > > supports 11n at all. > > .. > iwn0: 11na MCS 20MHz > iwn0: MCS 0-7: 6.5Mbps - 65Mbps > iwn0: MCS 8-15: 13Mbps - 130Mbps > .. That indicates 11n support. > >There are some where the 11n bits have been > > disabled. Next thing would be to check with > > % ifconfig -v wlan0 list chan > > I think you may be right about this, despite the dmesg output, as I > see no 11n listed in the output: > > # ifconfig -v wlan0 list chan > > Channel 1 : 2412 MHz 11g ht/20Channel 40 : 5200* MHz 11a ht/40- HT channels are available. > > if the HT channel setup works, if so it should list several HT20/HT40 > > channels. With > > % wlanconfig +11n > > # wlandebug +11n > > May 2 02:22:24 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <268:331> (0 frames) rxseq 267 tid 0 (retransmit) > May 2 02:22:28 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <336:399> (0 frames) rxseq 335 tid 0 (retransmit) > May 2 02:22:28 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <393:456> (0 frames) rxseq 392 tid 0 (retransmit) > May 2 02:22:28 x300 kernel: wlan0: [00:1d:0f:d3:fb:cc] discard MPDU > frame, BA win <406:469> (0 frames) rxseq 405 tid 0 (retransmit) That is probably the reason why you're seeing low performance. I remember seeing this with ath9k but didn't dig any deeper. Well, time to do so now. > > you should at least see something like "Switching channel to HT20" > > right before moving into RUN state. Also, does > > % ifconfig wlan0 list scan > > show HTCAP for the AP you're associating too? > > # ifconfig -v wlan0 list scan > > bingo00:1d:0f:d3:fb:cc 11 54M -71:-95 > .. > txop 47]> VEN HTCAPhttp://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: > Hi, > > does anybody know what happened to the attempts to support Intel WiFi > 5100/5300 interfaces in the iwn-driver? Are any patches available which > could be used to start working on support for these interfaces? I'm curious too, as I'm playing with idea to start porting the latest changes to if_iwn from OpenBSD. Already started with adding the 5000 series firmware to iwnfw... -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
Hi, Just to let you know, I started working on that myself and was finally able to get a connection and make traffic yesterday :) I'm still having issues scanning 5Ghz channels though.. anyways, I'll post updates on sunday. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Friday 16 October 2009 02:52:26 Brandon Gooch wrote: > On Thu, Oct 15, 2009 at 6:15 AM, Bernhard Schmidt > > wrote: > > Hi, > > > > Just to let you know, I started working on that myself and was finally > > able to get a connection and make traffic yesterday :) I'm still having > > issues scanning 5Ghz channels though.. anyways, I'll post updates on > > sunday. > > > > -- > > Bernhard > > That's great! > > BTW, which chip are you working with? Are you planning on pushing back > your updates to Daniel's SVN repo? I'm working with a 5100 currently, I do also have a 5300 and 4965 to test. As I did start from scratch (didn't know about the repo at that point) the diff against that it is probably quite large, have to check that though. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > .. anyways, I'll post updates on sunday. Here we go. http://techwires.net/~bschmidt/patches/freebsd/iwn/ Testers/feedback welcome! Code is pretty stable although there are still a few open issues. Nothing major I should be able to figure them out. * I did only tests with a 5100 card, other might not yet work.. I will do tests wie 5300 and 4965 cards later this week. * 11N has not been tested at all. * Deauth/disconnect frames are not handled correctly, those yield firmware errors. The remote side might therefore not be able to clean up correctly, whichs lead to no answers to probe requests on new scans. * Encryption of any kind does not yet work. * Monitor mode/radiotap does not yet work. * IBSS mode has not been tested. * iwnfw module is locked somehow on kldunload. * RF kill switch might not work correctly. * Manpage needs an update. :) * Suspend/resume is broken. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Sunday 18 October 2009 21:41:36 Lucius Windschuh wrote: > Hi Bernhard, > I tried your module on my T400 with a PRO/Wireless 5300 and WITNESS, > INVARIANTS enabled. > If the RF kill switch is set to "WLAN disabled", this command sequence [..] Thanks for reporting this, there seems to be an issue in iwn_cleanup(). > BTW: With the RF kill switch set to "WLAN enabled", it works for open > networks. But ifconfig wlan1 list ap did not return my 802.11a access > point. Is this expected? No it's not. I'll noticed that also during the last tests, scanning on 5Ghz channels does not work reliably, setting a fixed channel works though. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > > .. anyways, I'll post updates on sunday. > > Here we go. Update: * All reported issues should now be fixed, please verify. * WPA does work. Still open: * Test reports welcome, especially with 4965, 5150, 5300 and 5350. At this point, if no issue come up, the driver has the same functionality as the in tree one. http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ or http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Wednesday 21 October 2009 01:11:34 David Horn wrote: > On Tue, Oct 20, 2009 at 4:47 PM, Bernhard Schmidt > > wrote: > > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: > >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > >> > .. anyways, I'll post updates on sunday. > >> > >> Here we go. > > > > Update: > > * All reported issues should now be fixed, please verify. > > * WPA does work. > > 4965 with mode 11g WPA2/AES works well on 2.4Ghz (Have not tried > 5Ghz/11a or 5Ghz/11n) > > > Still open: > > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. > > > > At this point, if no issue come up, the driver has the same functionality > > as the in tree one. > > Any thoughts on IBSS or 11n mode support ? (I could not get 4965 11ng > mode to work, and IBSS support is disabled in the drivercaps) Of > course, this is on-par with the in-tree iwn driver as well. Have not spend time on that one, another time maybe. > The only new issue I have found so far is that I must manually load > iwnfw.ko before loading if_iwn.ko (the module depend used to work on > the in-tree driver) Hmm.. that is probably related to the rename of the firmware image, iwnfw-5000 instead of iwnfw. Is MODULE_DEPEND(iwn, iwnfw, 1, 1, 1); an option there? > Thanks for your work on this driver! You're welcome :) -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Wednesday 21 October 2009 09:29:13 David Horn wrote: > >> The only new issue I have found so far is that I must manually load > >> iwnfw.ko before loading if_iwn.ko (the module depend used to work on > >> the in-tree driver) > > > > Hmm.. that is probably related to the rename of the firmware image, > > iwnfw-5000 instead of iwnfw. Is MODULE_DEPEND(iwn, iwnfw, 1, 1, 1); an > > option there? > > MODULE_DEPEND(iwn, iwnfw_fw, 1, 1, 1) > > added to if_iwn.c fixes it nicely (note: iwnfw_fw not just iwnfw). It > turns out the original driver loaded the iwnfw.ko module as part of > firmware_get() since the firmware module name matched the first > firmware image name (see firmware.h comments). Looking at the other > drivers, the other option is to break up the firmware images into > unique kernel modules (e.g. ral or iwi), and allow firmware_get() to > do the load. I would think that this would reduce kernel memory usage > as well (several individual firmware modules vs all firmware images in > one module). Just a thought. Any "offical" opinions on that one? Should we break iwnfw up into individual modules? -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Friday 23 October 2009 19:32:27 Nicolas wrote: > Hi Bernhard, > > I'm trying to use your driver but i have a problem: > > iwn0: mem 0xde00-0xde001fff irq 16 at > device 0.0 on pci2 > iwn0: MIMO 1T2R, MoW, address 00:21:6b:2b:78:04 > iwn0: [ITHREAD] > iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > iwn0: 11na MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps > 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps > iwn0: 11ng MCS: 15Mbps 30Mbps 45Mbps 60Mbps 90Mbps 120Mbps 135Mbps > 150Mbps 30Mbps 60Mbps 90Mbps 120Mbps 180Mbps 240Mbps 270Mbps 300Mbps > wlan0: Ethernet address: 00:21:6b:2b:78:04 > iwn0: iwn_init_locked: radio is disabled by hardware switch > > I load iwnfw.ko before if_iwn.ko. > But i have all time the message: > iwn0: iwn_init_locked: radio is disabled by hardware switch > > But when i press the button nothing change, no options in the bios too. > Have you an idea where the problem come from ? > > Thanks in adavance, > Nicolas. I have no clue.. Do you have any status indication for the button, LED or something? Try press it a few times and kldunload/kldload if_iwn again. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
Hi, Update: * iwnfw has now been split into individual modules so autoloading of firmware module(s) does work again. * Changes have been made to RUN -> AUTH transition, this should fix the issue reported by Glen and others. * Brandon reported issues in iwn_cmd() with large commands, those have been fixed to. * DEAUTH is now handled correctly. http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091024.tar.gz or http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Saturday 24 October 2009 00:08:24 Rui Paulo wrote: > On 20 Oct 2009, at 21:47, Bernhard Schmidt wrote: > > On Sunday 18 October 2009 16:27:37 Bernhard Schmidt wrote: > >> On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > >>> .. anyways, I'll post updates on sunday. > >> > >> Here we go. > > > > Update: > > * All reported issues should now be fixed, please verify. > > * WPA does work. > > > > Still open: > > * Test reports welcome, especially with 4965, 5150, 5300 and 5350. > > > > At this point, if no issue come up, the driver has the same > > functionality as > > the in tree one. > > > > http://techwires.net/~bschmidt/patches/freebsd/iwn/sys/ > > or > > http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn-20091020.tar.gz > > This is now committed to HEAD. > > Thanks! A few minutes to early, there's been an update. Sorry for that. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited > a bunch of changes to their iwn driver. maybe some of it is useful for > FreeBSD as well? > > Log message: > huge diff introducing many of the recent changes made by intel to iwlwifi: > - ICT interrupts for >=5000 series (avoids reading IWN_INT which is slow) > - support v2 firmware header (including build number) > - switch to v2 firmware api (requires a firmware package upgrade) > - initial support for 1000 series and initial bits for upcoming 6000 > series (untested as hardware is not available to the general public) > - many bug fixes, including workarounds for hardware bugs > > make sure to update your iwn-firmware package to iwn-firmware-5.2. Definitely, I'll look into that. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
The following reply was made to PR kern/140036; it has been noted by GNATS. From: Bernhard Schmidt To: bug-follo...@freebsd.org, ka...@mit.edu Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Thu, 29 Oct 2009 08:19:44 +0100 Hi, Removing the IWN_LOCK(sc) leads to races when calling iwn_cmd(). It's better to drop the IEEE80211_LOCK(ic). I do have a patch in test which hopefully will hit the tree soon. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Sunday 25 October 2009 10:24:06 Bernhard Schmidt wrote: > On Saturday 24 October 2009 21:41:39 Sam Fourman Jr. wrote: > > Just wanted to make everyone aware that OpenBSD just 1 hour ago commited > > a bunch of changes to their iwn driver. maybe some of it is useful for > > FreeBSD as well? > > Definitely, I'll look into that. Another update: * ICT interrupts for 5000/6000 series * New firmware * Initial support for 1000 series and initial bits for upcoming 6000 series (untested as hardware is not available to the general public) * Many bug fixes, including workarounds for hardware bugs * Addresses kern/140036 Most of this stuff has been obtained from OpeBSD. Testes/Feedback welcome! http://techwires.net/~bschmidt/patches/freebsd/iwn/iwn_merge_20081028.diff.bz2 -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100/5300
On Saturday 31 October 2009 18:46:31 Mykola Dzham wrote: > But sometimes i receive error: > > iwn0: iwn5000_post_alive: could not configure WiMAX coexistence, error 35 > iwn0: iwn_init_locked: could not initialize hardware, error 35 > > And adapter not work after this error kldunload if_iwn && kldload > if_iwn does not fix problem, only reboot. > If i add any other options to ifconfig wlan0 create (for example mode, > country, or up) i always receive this error. Does it help if you add a bit of delay between kldunload and kldload? I have the feeling that your device is either still powered down or gets powered down on the way. somewhere. I'm not able to reproduce this myself, yet I'm trying. Thanks for the feedback! By the way, current iwn development is done here: http://svn.techwires.net/ -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: AR5212 wlan adapter
On Saturday 31 October 2009 21:12:26 ipre...@freebsd.org wrote: > I have D-LINK DWA-520 adapter (AR5212 chipset) running on 8.0-BETA2 > machine (same thing on -RC1). It appears as ath0 interface, but I can't > get scan results. > ifconfig ath0 up scan > reports that it can't get scan results. > When I add wpa_supplicant configuration and try to start it, it reports > errors with IOCTL. > > Do I miss something here? > > Any help? man ath ifconfig wlan0 create wlandev ath0 ifconfig wlan0 up ifconfig wlan0 scan -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Intel WiFi 5100, PANIC 9.0-CURRENT FreeBSD
On Monday 09 November 2009 21:45:20 Alireza Torabi wrote: > at /usr/src/sys/amd64/amd64/busdma_machdep.c:933 > #7 0x80cac6ae in iwn_notif_intr (sc=0xff80002fb000) > at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:2185 > #8 0x80cacbf5 in iwn_intr (arg=Variable "arg" is not available. > ) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:2477 Never seen this one before. Can you reproduce this with code from http://svn.techwires.net/svn/ ? There are few changes at those lines. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
The following reply was made to PR kern/140036; it has been noted by GNATS.
From: Bernhard Schmidt
To: Benjamin Kaduk
Cc: s...@freebsd.org, bug-follo...@freebsd.org
Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock
and iwn0 softc lock
Date: Sat, 5 Dec 2009 09:56:23 +0100
On Saturday 05 December 2009 03:49:42 Benjamin Kaduk wrote:
> Okay, I've been getting these lockups fairly frequently -- in fact,
> there was this one room where I was getting them every five minutes
> or so. I hypothesized that dissociation/association events might
> be triggers, so I set dev.iwn.0.debug=-1 and started wandering around
> this building (which is chock full of APs).
> I get:
> panic: lock (sleep mutex) iwn0_com_lock not locked @
> /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254
Are you sure your code is in sync? there is nothing accessing the lock in
if_iwn.c:3254
3251 if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) {
3252 ieee80211_free_node(ni);
3253 m_freem(m);
3254 return ENETDOWN;
3255 }
> Unfortunately, it appears to have messed up my machine pretty badly,
> as only numlock blinks the LED, and I don't have a db> prompt ...
>
> Trying again without the debugging spew gets a useful debugger, though.
> "show alllocks" produces empty output (?!).
> backtrace is:
> kdb_enter
> panic
> witness_unlock
> _mtx_unlock_flags
> iwn_raw_xmit
> ieee80211_send_probereq
> beacom_miss
> taskqueue_run
> taskqueue_thread_loop
> fork_exit
>
> Looking at the coredump, I'm inclined to suspect this block of
> ieee80211_proto.c (in beacon_miss() ):
> 1.46 sam 1379:/* XXX locking */
> 1380:TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) {
> 1.38 sam 1381:/*
> 1.46 sam 1382: * We only pass events through for sta
> vap's in RUN state; 1383: * may be too restrictive but for
> now this saves all the 1384: * handlers duplicating these
> checks. 1.38 sam 1385: */
> 1.46 sam 1386:if (vap->iv_opmode == IEEE80211_M_STA
> && 1.64 sam 1387:vap->iv_state >=
> IEEE80211_S_RUN && 1.46 sam 1388:vap->iv_bmiss
> != NULL)
> 1389:vap->iv_bmiss(vap);
>
>
> Sam, do you have any thoughts as to why throwing a
> IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH
> might not be a good idea?
> I'm currently running with that, which gives me a new LOR
> (iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and
> iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289)
> but it hasn't locked up or panic()ed on me, yet.
>
>
> I am happy to pull more information from the coredump if needed.
>
> Thanks,
>
> Ben Kaduk
>
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation
The following reply was made to PR bin/142547; it has been noted by GNATS. From: Bernhard Schmidt To: bug-follo...@freebsd.org, sweetpea-free...@tentacle.net Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation Date: Sun, 10 Jan 2010 10:28:14 +0100 Hi, can you confirm that this does also occur with iwn(4) from CURRENT or with http://forums.freebsd.org/showpost.php?p=47627&postcount=16 for STABLE? There has been quite some work done to iwn(4) which might have fixed that. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/142018: [iwi] [patch] Possibly wrong interpretation of beacon-> number in if_iwi.c
The following reply was made to PR kern/142018; it has been noted by GNATS.
From: Bernhard Schmidt
To: bug-follo...@freebsd.org, andre.albsme...@siemens.com
Cc:
Subject: Re: kern/142018: [iwi] [patch] Possibly wrong interpretation of
beacon->number in if_iwi.c
Date: Thu, 14 Jan 2010 16:10:28 +0100
Hi,
It might be simple endianess related issue, does this patch make any
difference?
Index: if_iwi.c
===
--- sys/dev/iwi/if_iwi.c (revision 202285)
+++ sys/dev/iwi/if_iwi.c (working copy)
@@ -1499,9 +1499,9 @@ iwi_notification_intr(struct iwi_softc *sc, struct
beacon = (struct iwi_notif_beacon_state *)(notif + 1);
DPRINTFN(5, ("Beacon state (%u, %u)\n",
- beacon->state, le32toh(beacon->number)));
+ le32toh(beacon->state), le32toh(beacon->number)));
- if (beacon->state == IWI_BEACON_MISS) {
+ if (le32toh(beacon->state) == IWI_BEACON_MISS) {
/*
* The firmware notifies us of every beacon miss
* so we need to track the count against the
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation
The following reply was made to PR bin/142547; it has been noted by GNATS. From: Bernhard Schmidt To: bug-follo...@freebsd.org, sweetpea-free...@tentacle.net Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation Date: Sun, 17 Jan 2010 16:14:35 +0100 I'm not able to reproduce that on HEAD or 8-STABLE. Could you add output of wlandebug 0x during a re-keying process? Maybe we are missing something obvious here. -- Bernhard ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Software TKIP group rekeying and phase1 issue
Hi,
When hostapd triggers rekeying of the group key, wpa_supplicant successfully
sets the correct new key. On first use of the new key tkip_mixing_phase1()
should be applied before decrypting any frames, tkip_decrypt() does this as
if (iv32 != (u32)(key->wk_keyrsc[tid] >> 16) || !ctx->rx_phase1_done) {
tkip_mixing_phase1(ctx->rx_ttak, key->wk_key,
wh->i_addr2, iv32);
ctx->rx_phase1_done = 1;
}
But, after a rekeying event, neither of this condition match, especially as
rx_phase1_done is no longer zero, therefore tkip_mixing_phase1() isn't called
which leads to dropped frames with "TKIP ICV mismatch on decrypt" messages.
A working solution for that is to set rx_phase1_done to zero inside
tkip_setkey(). I'm not sure whether that is the best solution or if it is
better to set/reset the wk_keyrsc sequence, at least this diff works for me
and few other over at the Forums.
Index: sys/net80211/ieee80211_crypto_tkip.c
===
--- sys/net80211/ieee80211_crypto_tkip.c(revision 203242)
+++ sys/net80211/ieee80211_crypto_tkip.c(working copy)
@@ -144,6 +144,8 @@ tkip_setkey(struct ieee80211_key *k)
return 0;
}
k->wk_keytsc = 1; /* TSC starts at 1 */
+ if (k->wk_flags & IEEE80211_KEY_GROUP)
+ ctx->rx_phase1_done = 0;
return 1;
}
--
Bernhard
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
