Re: Issues with urtwn
El día Monday, September 08, 2014 a las 08:19:45AM +0200, Vladimir Botka
escribió:
Hi Vladimir,
> maybe the wpa_passphrase utility could help you to create the config.
> In this particular case:
>
> $ wpa_passphrase "Naturhotel Wieserhof" "N@tur%Wieser"
> network={
> ssid="Naturhotel Wieserhof"
> #psk="N@tur%Wieser"
> psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
> }
What is the benefit of coding the PSK? I have never used it; the
wpa_supplicant.conf file tested was:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
# Hotel Wieserhof
#
network={
ssid="Naturhotel Wieserhof"
scan_ssid=1
# key_mgmt=WPA-PSK WPA-EAP IEEE8021X
key_mgmt=WPA-PSK
# key_mgmt=WPA-PSK WPA-EAP
psk="N@tur%Wieser"
# key_mgmt=NONE
# wep_tx_keyidx=0
# wep_key0="N@tur%Wieser"
}
as you see in the comments, I tested a lot of different key_mgmt=
values; the one shown active, gave the best results (but only in my
hotel room, not in the lobby);
> ,or you might want to try wpa_gui.
I have never used it, but will install the port and give it a try next
time.
Thx
matthias
PD: To Adrian, I'm willing to file a PR, but the problem is, I will not
return to this hotel and can not provide more information or tests.
--
Matthias Apitz | /"\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Issues with urtwn
Hi Matthias,
On Mon, 8 Sep 2014 09:32:29 +0200
Matthias Apitz wrote:
> El día Monday, September 08, 2014 a las 08:19:45AM +0200, Vladimir
> Botka escribió:
>
> Hi Vladimir,
>
> > maybe the wpa_passphrase utility could help you to create the
> > config. In this particular case:
> >
> > $ wpa_passphrase "Naturhotel Wieserhof" "N@tur%Wieser"
> > network={
> > ssid="Naturhotel Wieserhof"
> > #psk="N@tur%Wieser"
> > psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
> > }
>
> What is the benefit of coding the PSK? I have never used it; the
> wpa_supplicant.conf file tested was:
>
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> eapol_version=1
> ap_scan=1
> fast_reauth=1
>
> # Hotel Wieserhof
> #
> network={
> ssid="Naturhotel Wieserhof"
> scan_ssid=1
> # key_mgmt=WPA-PSK WPA-EAP IEEE8021X
> key_mgmt=WPA-PSK
> # key_mgmt=WPA-PSK WPA-EAP
> psk="N@tur%Wieser"
> # key_mgmt=NONE
> # wep_tx_keyidx=0
> # wep_key0="N@tur%Wieser"
> }
>
> as you see in the comments, I tested a lot of different key_mgmt=
> values; the one shown active, gave the best results (but only in my
> hotel room, not in the lobby);
>
> > ,or you might want to try wpa_gui.
>
> I have never used it, but will install the port and give it a try next
> time.
>
> Thx
>
> matthias
>
> PD: To Adrian, I'm willing to file a PR, but the problem is, I will
> not return to this hotel and can not provide more information or
> tests.
psk="N@tur%Wieser"
and
psk=b853709a9edcd50edf0835f68bf099255cb32fc462e492117fe3c42ab2a387cb
are equivalent.
If you have troubles to configure it manually, I recommend to try
wpa_gui as a next step. In the upstream, wpa_gui is maintained together
with wpa_supplicant by the same maintainer. Therefor wpa_gui has always
been working fine with wpa_supplicant and might help you to create a
consistent configuration.
If this doesn't work, there might be a problem in the (1) lower layer
(driver), (2) AP, or (3) HW in general. If so, to debug it might be a
complex issue suitable for a bug entry.
Cheers,
-vlado
signature.asc
Description: PGP signature
[Bugzilla] Commit Needs MFC
Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by ead...@freebsd.org. (7 bugs) Bug 140567: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=140567 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [ath] [patch] ath is not worked on my notebook PC Bug 154598: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=154598 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [ath] Atheros 5424/2424 can't connect to WPA network Bug 163312: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163312 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [panic] [ath] kernel panic: page fault with ath0 taskq Bug 166190: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166190 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [ath] TX hangs and frames stuck in TX queue Bug 166357: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166357 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [ath] 802.11n TX stall when the first frame in the BAW is in the software queue Bug 166642: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166642 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [ieee80211] [patch] in 802.11n mode for FreeBSD AP, having a station in powersave cripples AP TX. Bug 169362: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169362 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-wireless@FreeBSD.org Status: Needs MFC Resolution: Summary: [ath] AR5416: radar pulse PHY errors sometimes include the CRC Error bit set as well as the PHY errors ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
[Bug 193458] New: can not connect reliable to Wifi AP with WPA-PSK / WPA-EAP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193458
Bug ID: 193458
Summary: can not connect reliable to Wifi AP with WPA-PSK /
WPA-EAP
Product: Base System
Version: 11.0-CURRENT
Hardware: i386
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: wireless
Assignee: freebsd-wireless@FreeBSD.org
Reporter: g...@unixarea.de
$ uname -a
FreeBSD tiny-r269739 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r269739M: Fri Aug 15
18:07:41 CEST 2014 guru@vm-tiny-r269739:/usr/obj/usr/src/sys/GENERIC i386
Wifi NIC:
urtwn0: on
usbus4
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
wlan0: Ethernet address: 80:1f:02:ee:16:37
# cat /etc/wpa_supplicant.conf
#
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=1
ap_scan=1
fast_reauth=1
# Hotel Wieserhof
#
network={
ssid="Naturhotel Wieserhof"
scan_ssid=1
# key_mgmt=WPA-PSK WPA-EAP IEEE8021X
key_mgmt=WPA-PSK
# key_mgmt=WPA-PSK WPA-EAP
psk="N@tur%Wieser"
# key_mgmt=NONE
# wep_tx_keyidx=0
# wep_key0="N@tur%Wieser"
}
note: credentials have been was by local hotel management staff as:
Wi-Fi: Naturhotel Wieserhof
Password: N@tur%Wieser
i.e. the credentials are correct and the SSID was visible with ifconfig wlan0
list scan
WPA started as:
# /usr/sbin/wpa_supplicant -d -i wlan0 -c /etc/wpa_supplicant.conf -D bsd
connection (associating, IP by DHCP) was only sometimes possible far away from
the AP (in the hotel room, where the staff said it is not supposed to work),
and was never possible near the AP (in the lobby, where it was supposed to
work);
I tested the various combinations, the best was what is visible above as aktive
lines;
I will attach log files;
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
[Bug 193458] can not connect reliable to Wifi AP with WPA-PSK / WPA-EAP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193458 --- Comment #1 from Matthias Apitz --- Created attachment 147057 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147057&action=edit wpa debug log -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
[Bug 193458] can not connect reliable to Wifi AP with WPA-PSK / WPA-EAP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193458 --- Comment #2 from Matthias Apitz --- Created attachment 147058 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147058&action=edit wpa debug log (2) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Issues with urtwn
> wpa_gui as a next step. In the upstream, wpa_gui is maintained together > with wpa_supplicant by the same maintainer. Therefor wpa_gui has always > been working fine with wpa_supplicant and might help you to create a > consistent configuration. I too have found wpa_gui useful to detect syntax errs from my wpa_supplicant.conf (& useful to know same maintainer). Matthias, a word of warning: copy wpa_supplicant.conf before you enable update_config=1 because wpa_gui will discard all lines with comments. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Interleave replies Below, like a play script. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Issues with urtwn
On Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd wrote: > Hi, > > On 7 September 2014 19:16, Thiago Farina wrote: >> On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn >> wrote: >>> I've been having some issues with connection stability in urtwn for several >>> months. The usual symptom is that after some period of time the connection >>> will apparently stall. If I'm running ping continuously, for instance, it >>> will at some point stop receiving replies. Then, sometime later, immediately >>> if I use the "reassociate" command in wpa_cli, the connection will fix >>> itself and all the packets I didn't get earlier get delivered at once: >>> hundreds of ping replies, for instance, some with time stamps minutes in the >>> past. No data is actually lost, though. >>> >>> I think the issue is that the driver does not actually support powersave >>> mode (maybe it should?) but reports to the AP that it does: >>> ifconfig wlan0 list sta (this is on the AP) >>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >>> 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN >>> >>> I don't know enough about wireless to fix this, but the AP waiting for a >>> powersave poll and never getting one seems consistent with the problem. >> >> I think what you are relating here is what I observed recently too. >> Sorry, I'm new to FreeBSD. Just installed it recently, and I noticed >> that after I left it idle (I went to do something for some hours) for >> some time it lost the connection. Only rebooting makes it connect >> again to my network. > > Which NIC are you seeing this on? > Mine is urtwn0: Realtek RTL8187L from my Gateway laptop. -- Thiago Farina ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Issues with urtwn
So it's definitely to do with powersave. Here's a bunch of iterations of ifconfig list sta on my laptop: ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.00 4385 37104 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4412 39360 EPS A HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP RSN WME You can see the connection die on the third line, when the txseq and rxseq counters stop incrementing and 'P' gets added to the FLAG field. Does this mean the AP has turned on powersave on its end? -Nathan On 09/07/14 14:07, Adrian Chadd wrote: Hi, The way it's supposed to work in the legacy 802.11 powersave world is that you send a/any data frame with the powermgt bit in the 802.11 header set to 0 and the AP goes "oh they're awake!" and sends you your buffered frames. By default powersave isn't enabled, so we should never be _telling_ the AP that we're going to sleep and the stack always sends data frames with pwrmgt=0. You can ensure it's disabled by ifconfig wlan0 -powersave The code in -HEAD that manages that is in ieee80211_power.c. I added an explicit powersave support mode for NICs that need it done for them - and the only one it's enabled for right now is ath(4). The only reason net80211 sends pwrmgt changes outside of having net80211 power save enabled is the background scan code. I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug +scan to see if somehow there's some scanning going on; and wlandebug +power to see if any power save transitions occur. Are you absolutely sure it's a receive side buffering problem, rather than a send side problem? It's also possible that the NIC stops receiving and the AP treats that as "oh ok, they've gone to sleep for a while." ath(4) now does this in hostap mode. -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Issues with urtwn
Please compile your kernel with IEEE80211_DEBUG, then enable debugging - wlandebug +state +power You can disable powersave with 'ifconfig wlan0 -powersave', but it shouldn't be enabled by default. -a On 8 September 2014 15:14, Nathan Whitehorn wrote: > So it's definitely to do with powersave. Here's a bunch of iterations of > ifconfig list sta on my laptop: > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 54:78:1a:a0:91:22 1491 54M 37.00 4385 37104 EPS A HTCAP > RSN WME > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 54:78:1a:a0:91:22 1491 54M 37.50 4412 39360 EPS A HTCAP > RSN WME > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP > RSN WME > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP > RSN WME > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > 54:78:1a:a0:91:22 1491 54M 37.50 4417 39360 EPS AP HTCAP > RSN WME > > You can see the connection die on the third line, when the txseq and rxseq > counters stop incrementing and 'P' gets added to the FLAG field. Does this > mean the AP has turned on powersave on its end? > -Nathan > > > On 09/07/14 14:07, Adrian Chadd wrote: >> >> Hi, >> >> The way it's supposed to work in the legacy 802.11 powersave world is >> that you send a/any data frame with the powermgt bit in the 802.11 >> header set to 0 and the AP goes "oh they're awake!" and sends you your >> buffered frames. >> >> By default powersave isn't enabled, so we should never be _telling_ >> the AP that we're going to sleep and the stack always sends data >> frames with pwrmgt=0. >> >> You can ensure it's disabled by ifconfig wlan0 -powersave >> >> The code in -HEAD that manages that is in ieee80211_power.c. I added >> an explicit powersave support mode for NICs that need it done for them >> - and the only one it's enabled for right now is ath(4). >> >> The only reason net80211 sends pwrmgt changes outside of having >> net80211 power save enabled is the background scan code. >> >> I'd compile in IEEE80211_DEBUG in your kernel, then I'd use wlandebug >> +scan to see if somehow there's some scanning going on; and wlandebug >> +power to see if any power save transitions occur. >> >> Are you absolutely sure it's a receive side buffering problem, rather >> than a send side problem? >> >> It's also possible that the NIC stops receiving and the AP treats that >> as "oh ok, they've gone to sleep for a while." ath(4) now does this in >> hostap mode. >> >> >> -a >> > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Intel Centrino Wireless-N 2230 status
I'm not sure why yours is misbehaving. I don't ahve anything channel 3 though, that's for sure. I don't also run it in the HU country/regdomain. :) Can you try updating to the latest -HEAD and retrying? -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: TP-LINK TL-WN821N
On Sun, Aug 24, 2014 at 06:01:20PM +0200, Carlos Jacobo Puga Medina wrote: > > Hi Kevin, Hi, Sorry for the late response. > Sometimes my wireless device fails to connect at boot, and I need to restart > the system. Also it states that the device is not configured. > > /boot/loader.conf > if_urtwn_load="YES" > legal.realtek.license_ack=1 You might add the following lines to /boot/loader.conf: urtwn-rtl8192cfwT_load="YES" urtwn-rtl8192cfwU_load="YES" > It shows the following output: > > urtwn0: timeout waiting for checksum report > > Any thoughts? I thought this problem was fixed in r263154, but apparently not. Could you try this patch? Thanks Index: sys/dev/usb/wlan/if_urtwn.c === --- sys/dev/usb/wlan/if_urtwn.c (revision 271297) +++ sys/dev/usb/wlan/if_urtwn.c (working copy) @@ -2280,8 +2280,6 @@ urtwn_fw_reset(struct urtwn_softc *sc) return; urtwn_ms_delay(sc); } - /* Force 8051 reset. */ - urtwn_write_2(sc, R92C_SYS_FUNC_EN, reg & ~R92C_SYS_FUNC_EN_CPUEN); } static void ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Issues with urtwn
On Mon, Sep 08, 2014 at 12:16:53PM -0300, Thiago Farina wrote: > > On Sun, Sep 7, 2014 at 11:36 PM, Adrian Chadd wrote: > > Hi, > > > > On 7 September 2014 19:16, Thiago Farina wrote: > >> On Sun, Sep 7, 2014 at 12:09 PM, Nathan Whitehorn > >> wrote: > >>> I've been having some issues with connection stability in urtwn for > >>> several > >>> months. The usual symptom is that after some period of time the connection > >>> will apparently stall. If I'm running ping continuously, for instance, it > >>> will at some point stop receiving replies. Then, sometime later, > >>> immediately > >>> if I use the "reassociate" command in wpa_cli, the connection will fix > >>> itself and all the packets I didn't get earlier get delivered at once: > >>> hundreds of ping replies, for instance, some with time stamps minutes in > >>> the > >>> past. No data is actually lost, though. > >>> > >>> I think the issue is that the driver does not actually support powersave > >>> mode (maybe it should?) but reports to the AP that it does: > >>> > ifconfig wlan0 list sta (this is on the AP) > >>> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > >>> 80:1f:02:cc:47:a91 11 11M 8.50 5526 55712 EPS AE RSN > >>> > >>> I don't know enough about wireless to fix this, but the AP waiting for a > >>> powersave poll and never getting one seems consistent with the problem. > >> > >> I think what you are relating here is what I observed recently too. > >> Sorry, I'm new to FreeBSD. Just installed it recently, and I noticed > >> that after I left it idle (I went to do something for some hours) for > >> some time it lost the connection. Only rebooting makes it connect > >> again to my network. > > > > Which NIC are you seeing this on? > > > Mine is urtwn0: Realtek RTL8187L from my Gateway laptop. Typo? urtw(4) supports Realtek RTL8187L, not urtwn(4). > -- > Thiago Farina Kevin ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: TL-WN722N support on FreeBSD.
On Mon, Sep 01, 2014 at 11:11:20AM -0700, Adrian Chadd wrote: > > The problem -is- the money. The people will come when there's enough > interest and enough money. > > The problem is that people think things like wifi drivers that are > debugged, perform well and get updated as new standards appear is a > few months effort - and I think the herculean efforts done in the past > by people like Sam fuel this myth. > > I've spent almost two years of weekends and evenings hacking on > net80211 and the atheros driver to get it to where it is. The 11n > support for atheros chips appeared when someone (hi Hobnob!) paid me > for six months to get 11n done. I'm still debugging weird corner cases > with rate control and congestion handling even now. And this is _on > top_ of all the work done by the Atheros team to write the HAL in the > first place. > > I've spent almost 18 months of weekends/evenings hacking on the intel > iwn driver to find all the little odd corner cases that make it > unusable by a lot of people. I keep saying I'm not, but since the > laptops I'm using have iwn in them, I end up getting annoyed enough to > fix it. This has all been for free. > > Wireless stuff is a very complicated, very time consuming thing that's > immensely fun if you're into this kind of thing. But please understand > - it's a huge time commitment for each individual device and new > standard. > > So yes, it's the money. I've jokingly said that it's $100k and 2 years > for me in (evenings, weekends) time and equipment to port and debug > one driver for a given NIC. Not just do a "oh look here's an openbsd > driver ported from linux in a month" port - that's just the beginning > (and I tend to quote something like $10k for that) - I mean, something > that ends up implementing the updated standards (11n, 11ac soon); > something that includes powersave, something that includes debugging, > something that handles a multitude of bad environments that people see > every day and complain about. Ie - the level of work that makes it "oh > it just works, I can get on with work now" level of work. > > I don't want to let myself be dragged into another two years of > weekends. I kind of need some sleep here and there. I can't find a reason why I disagree with you. I have almost forgotten that wifi hacking can be fun if it results in something working... > -a Kevin ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: TL-WN722N support on FreeBSD.
Oh it is fun. :) +a On Sep 8, 2014 10:54 PM, "Kevin Lo" wrote: > On Mon, Sep 01, 2014 at 11:11:20AM -0700, Adrian Chadd wrote: > > > > The problem -is- the money. The people will come when there's enough > > interest and enough money. > > > > The problem is that people think things like wifi drivers that are > > debugged, perform well and get updated as new standards appear is a > > few months effort - and I think the herculean efforts done in the past > > by people like Sam fuel this myth. > > > > I've spent almost two years of weekends and evenings hacking on > > net80211 and the atheros driver to get it to where it is. The 11n > > support for atheros chips appeared when someone (hi Hobnob!) paid me > > for six months to get 11n done. I'm still debugging weird corner cases > > with rate control and congestion handling even now. And this is _on > > top_ of all the work done by the Atheros team to write the HAL in the > > first place. > > > > I've spent almost 18 months of weekends/evenings hacking on the intel > > iwn driver to find all the little odd corner cases that make it > > unusable by a lot of people. I keep saying I'm not, but since the > > laptops I'm using have iwn in them, I end up getting annoyed enough to > > fix it. This has all been for free. > > > > Wireless stuff is a very complicated, very time consuming thing that's > > immensely fun if you're into this kind of thing. But please understand > > - it's a huge time commitment for each individual device and new > > standard. > > > > So yes, it's the money. I've jokingly said that it's $100k and 2 years > > for me in (evenings, weekends) time and equipment to port and debug > > one driver for a given NIC. Not just do a "oh look here's an openbsd > > driver ported from linux in a month" port - that's just the beginning > > (and I tend to quote something like $10k for that) - I mean, something > > that ends up implementing the updated standards (11n, 11ac soon); > > something that includes powersave, something that includes debugging, > > something that handles a multitude of bad environments that people see > > every day and complain about. Ie - the level of work that makes it "oh > > it just works, I can get on with work now" level of work. > > > > I don't want to let myself be dragged into another two years of > > weekends. I kind of need some sleep here and there. > > I can't find a reason why I disagree with you. > I have almost forgotten that wifi hacking can be fun if it results > in something working... > > > -a > > Kevin > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
