gmane.linux.kernel.wireless.general

Re: [PATCH] nl80211: Report max TX power in NL80211_BAND_ATTR_FREQS

Johannes Berg — 2008-11-22T18:26:15

Yeah, true, I think we originally wanted it in the regulatory code and also push it throughout but then ended up converting it in the kernel. However, the userspace API is defined with the extra accuracy. Broadcom hw at least supports 1/4 dBm steps, iirc. So it could at least make some sense. True, but that's in the kernel and much easier to change later than userspace APIs. johannes

Re: [PATCH] nl80211: Report max TX power in NL80211_BAND_ATTR_FREQS

Jouni Malinen — 2008-11-22T18:20:51

Well.. Maximum TX power is stored as dBm and it is used as dBm in Country IE. Some of the current uses of EIRP seem to be converting the values between dBm and mBm, so it does not look like the extra accuracy would be needed there. Why was mBm used in the first place? It does not seem to be used anywhere outside Linux regulatory code as a standard unit which makes it quite a bit less obvious than dBm.. I kind of agree with consistency being a good reason for a change here, but I just find the mBm a bit odd choice as a unit unless there is need for greater accuracy than 1 dBm (and in that case, the chan->max_power value should likely be changed to use mBm, too).

Re: ieee80211_wep_encrypt_data_fix_unaligned_access.patch

Johannes Berg — 2008-11-22T17:59:48

any other architecture too... looks fine, you just need to send a proper changelog and s-o-b johannes

Re: ieee80211_wep_encrypt_data_fix_unaligned_access.patch

Johannes Berg — 2008-11-22T17:58:53

Never mind. johannes

Re: [PATCH] nl80211: Report max TX power in NL80211_BAND_ATTR_FREQS

Johannes Berg — 2008-11-22T17:54:24

I think for consistency we should use the same format that the regulatory stuff has for NL80211_ATTR_POWER_RULE_MAX_EIRP, i.e. a u32 value with mBm (I think) johannes

Re: ieee80211_wep_encrypt_data_fix_unaligned_access.patch

Johannes Berg — 2008-11-22T17:18:26

Aren't you putting a pointer now?? johannes

Re: ath5k: problems during the connection to a sitecom AP

Fabio Rossi — 2008-11-22T16:33:56

CONFIG_MAC80211_VERBOSE_DEBUG was already set in the previous log (I used "echo -n "all" > /debug/ath5k/phy1/debug"). The problem is that there are no direct probe requests, the card doesn't transmit at all (there are no TX dumps). I have compared the logs with the two access points (both are configured in the same way, no SSID broadcast, WEP and 802.11b&g mode). With the 3com AP at a certain point I see the following lines (with TX and RX dumps not reported here): kernel: ath0: direct probe to AP 00:0d:54:fb:55:33 try 1 kernel: ath0 direct probe responded kernel: ath0: authenticate with AP 00:0d:54:fb:55:33 kernel: ath0: authenticated kernel: ath0: associate with AP 00:0d:54:fb:55:33 kernel: ath0: RX AssocResp from 00:0d:54:fb:55:33 (capab=0x431 status=0 aid=5) kernel: ath0: associated kernel: phy14: Allocated STA 00:0d:54:fb:55:33 kernel: phy14: Inserted STA 00:0d:54:fb:55:33 while with the Sitecom AP I see nothing similar. I have also tried a PCMCIA card which uses the rtl8180 driver. The resu

Re: BCM4312 Fails when xdm is started

Michael Buesch — 2008-11-22T15:13:00

^^ ^^ Somebody disabled MMIO and busmastering. And somebody cleared the CACHE_LINE_SIZE register.

Re: Issues with AR5213A

Nick Kossifidis — 2008-11-22T14:19:56

2008/11/22 Alexander public.gmane.org>: Your card is based on 2413 chip (0x78) (it seems that ath5k doesn't report your chip name correctly which shouldn't happen). Can you please check out the latest code from compat-wireless and see what happens ? Current code supports both 5213 and 2413 chips.

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

Maxim Levitsky — 2008-11-22T13:25:51

Mystery solved, and sorry for the noise, short answer is, wpa_supplicant. My network is WPA2 protected, and I only test against it, and it takes time to go to AP settings, change encryption to WEP, and not forget to change it back, etc... So, wpa_supplicant wasn't aware of new mac, but I remember that WPA uses mac as part of encryption. restarting it solved the problem. I also applied (by hand) your latest patch, so maybe it did help, I'll check without it too. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [ath5k-devel] Unusually low speeds with ath5k and iwl3945

Maxim Levitsky — 2008-11-22T12:33:16

Hi, Well, iwl3945 was showing 54M all the time in iwconfig, also it doesn't support setting fixed rate, at least not using iwconfig. ath5k never shows higher that 18M, and supports setting fixed rate, but if I set it to anything higher that 18M, speeds drop to 0Kbytes/s immediately. Speeds lower that 18M work, and affect throughput accordantly For most of tests speeds are ether 18M or lower, but then when I set them to 18M this didn't increase throughput. iwl3945 was always at 54M Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] orinoco: Provide option to avoid unnecessary fw caching

David Kilroy — 2008-11-22T10:37:28

Make firmware caching on startup optional, and make it default. When the option is not selected and PM_SLEEP is configured, then cache firmware in the suspend pm_notifier. This configuration saves about 64k RAM in normal use, but can lead to a situation where the driver is configured to use a different firmware. Signed-off by: David Kilroy public.gmane.org> --- drivers/net/wireless/Kconfig | 15 ++++++++ drivers/net/wireless/orinoco/orinoco.c | 57 ++++++++++++++++++++++++++++++++ drivers/net/wireless/orinoco/orinoco.h | 3 ++ 3 files changed, 75 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index 7ea916b..ea543fc 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig < at >< at > -214,6 +214,21 < at >< at > config HERMES configure your card and that /etc/pcmcia/wireless.opts works : +config HERMES_CACHE_FW_ON_INIT +bool "

[PATCH 3/4] orinoco: Resume spectrum_cs in the same way as orinoco_cs

David Kilroy — 2008-11-22T10:37:27

Retrieval of external firmware has been resolved, and should work with the standard orinoco resume algorithm. This fixes an issue where priv->hw_unavailable indicates the card is ready when firmware has not been loaded. Signed-off by: David Kilroy public.gmane.org> --- drivers/net/wireless/orinoco/spectrum_cs.c | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/orinoco/spectrum_cs.c b/drivers/net/wireless/orinoco/spectrum_cs.c index 852789a..c6c6d12 100644 --- a/drivers/net/wireless/orinoco/spectrum_cs.c +++ b/drivers/net/wireless/orinoco/spectrum_cs.c < at >< at > -450,10 +450,29 < at >< at > spectrum_cs_resume(struct pcmcia_device *link) { struct net_device *dev = link->priv; struct orinoco_private *priv = netdev_priv(dev); +unsigned long flags; +int err; + +err = orinoco_reinit_firmware(dev); +if (err) { +printk(KERN_ERR "%s: Error %d re-initializing firmware\n", + dev->name, err); +return -EIO; +} + +spi

[PATCH 2/4] orinoco: Cache Symbol firmware

David Kilroy — 2008-11-22T10:37:26

Signed-off by: David Kilroy public.gmane.org> --- drivers/net/wireless/orinoco/orinoco.c | 46 ++++++++++++++++++++++--------- drivers/net/wireless/orinoco/orinoco.h | 3 +- 2 files changed, 34 insertions(+), 15 deletions(-) diff --git a/drivers/net/wireless/orinoco/orinoco.c b/drivers/net/wireless/orinoco/orinoco.c index 4cefb80..4c8f4c2 100644 --- a/drivers/net/wireless/orinoco/orinoco.c +++ b/drivers/net/wireless/orinoco/orinoco.c < at >< at > -645,34 +645,41 < at >< at > symbol_dl_firmware(struct orinoco_private *priv, int ret; const struct firmware *fw_entry; -if (request_firmware(&fw_entry, fw->pri_fw, - priv->dev) != 0) { -printk(KERN_ERR "%s: Cannot find firmware: %s\n", - dev->name, fw->pri_fw); -return -ENOENT; -} +if (!priv->cached_pri_fw) { +if (request_firmware(&fw_entry, fw->pri_fw, priv->dev) != 0) { +printk(KERN_ERR "%s: Cannot find firmware: %s\n", + dev->name, fw->pri_fw); +return -ENOENT; +} +} else +fw_entry = priv->cach

[PATCH 1/4] orinoco: Separate fw caching from download

David Kilroy — 2008-11-22T10:37:25

This refactorring will make it easier to share logic with Symbol firmware. Signed-off by: David Kilroy public.gmane.org> --- drivers/net/wireless/orinoco/orinoco.c | 53 +++++++++++++++++++++++--------- 1 files changed, 38 insertions(+), 15 deletions(-) diff --git a/drivers/net/wireless/orinoco/orinoco.c b/drivers/net/wireless/orinoco/orinoco.c index 5459b69..4cefb80 100644 --- a/drivers/net/wireless/orinoco/orinoco.c +++ b/drivers/net/wireless/orinoco/orinoco.c < at >< at > -431,9 +431,9 < at >< at > struct fw_info { }; const static struct fw_info orinoco_fw[] = { -{ "", "agere_sta_fw.bin", "agere_ap_fw.bin", 0x00390000, 1000 }, -{ "", "prism_sta_fw.bin", "prism_ap_fw.bin", 0, 1024 }, -{ "symbol_sp24t_prim_fw", "symbol_sp24t_sec_fw", "", 0x00003100, 512 } +{ NULL, "agere_sta_fw.bin", "agere_ap_fw.bin", 0x00390000, 1000 }, +{ NULL, "prism_sta_fw.bin", "prism_ap_fw.bin", 0, 1024 }, +{ "symbol_sp24t_prim_fw", "symbol_sp24t_sec_fw", NULL, 0x00003100, 512 } }; /* Structure used to

[PATCH 0/4] orinoco: clean up firmware download

David Kilroy — 2008-11-22T10:37:24

This series is a refactorring of the RFC previously posted as orinoco: Don't keep cached firmware around permanently The recent patch to load orinoco firmware correctly on resume simply kept the firmware in RAM for the entire time the module was loaded, and only applied to Agere firmware. The first two patches extend this to Symbol firmware. The third makes the spectrum_cs driver use this functionality directly during resume instead of resetting the card. The final patch provides an option to use the new power management notifiers to load the firmware prior to suspend and release it after resume. David Kilroy (4): orinoco: Separate fw caching from download orinoco: Cache Symbol firmware orinoco: Resume spectrum_cs in the same way as orinoco_cs orinoco: Provide option to avoid unnecessary fw caching drivers/net/wireless/Kconfig | 15 +++ drivers/net/wireless/orinoco/orinoco.c | 156 ++++++++++++++++++++++----- drivers/net/wireless/orinoco/orinoco.h | 6 +- drivers/n

Re: [ipw3945-devel] Unusually low speeds with ath5k and iwl3945

Rafał Miłecki — 2008-11-22T10:16:07

2008/11/21 Maxim Levitsky gmail.com>: I've no idea if this can be related, but recently there was some report about ath5k && b43. Maybe it's some bug in ath5k? https://lists.berlios.de/pipermail/bcm43xx-dev/2008-November/008315.html

Ath9k wont go in properly AP mode

W. van den Akker — 2008-11-22T09:12:01

Hi, My ath9k refuses to go into AP mode. I am using: - a 5416 wireless card (WMP300Nv2) - linuxkernel 2.7.27.6 - hostapd 0.6.5 - wireless-testing 11-11-2008 When I try to set the ath9k in AP with hostapd I get: xxx:/home/xxx# hostapd -dd /etc/hostapd/hostapd.conf Configuration file: /etc/hostapd/hostapd.conf ctrl_interface_group=0 Opening raw packet socket for ifindex 0 BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf Failed to update rate sets in kernel module RATE[0] rate=10 flags=0x2 RATE[1] rate=20 flags=0x2 RATE[2] rate=55 flags=0x2 RATE[3] rate=110 flags=0x2 RATE[4] rate=60 flags=0x0 RATE[5] rate=90 flags=0x0 RATE[6] rate=120 flags=0x0 RATE[7] rate=180 flags=0x0 RATE[8] rate=240 flags=0x0 RATE[9] rate=360 flags=0x0 RATE[10] rate=480 flags=0x0 RATE[11] rate=540 flags=0x0 Could not set passive scanning: Unknown error 4294967295 Flushing old station entries Deauthenticate all stations Mode: IEEE 802.11g Channel: 8 Frequency: 2447 MHz Failed

Re: [Orinoco-devel] Agere PCMCIA sometimes takes very long time to associate with 9.48 FW

Andrey Borzenkov — 2008-11-22T07:56:21

In some place wpa_supplicant is using this to mark invalid BSSID; I do not think it leaks it into the driver now though. And it is value that is use by Hermes to indicate invalid BSSID. It is even documents in iwconfig.c :) /* * Display an Wireless Access Point Socket Address in readable format. * Note : 0x44 is an accident of history, that's what the Orinoco/PrismII * chipset report, and the driver doesn't filter it. */ Anyway I now have Yet Another Theory that actually fits quite well into what I have seen in wpa_supplicant logs and explains 44:... BSSID as well. Mandriva is using approximately the following sequence to start wireless: ifconfig eth1 up iwconfig eth1 whatever-is-set-for-it wpa_supplicant eth1 Now I had these parameters for eth1: ### WIRELESS_MODE=Managed ### WIRELESS_ESSID="Home, sweet home" WIRELESS_WPA_DRIVER=wext ### WIRELESS_POWER=on ### WIRELESS_SENS=3 Notice WIRELESS_ESSID. So what happened was apparently this iwcofnig eth1 ESSID driver starts asso

Issues with AR5213A

Alexander — 2008-11-22T07:48:58

Dear Atheros Experts, I have an issue with an atheros card that was working fine under suse10.3 after installation of the madwifi drivers. When installing suse 11.0, a driver was automatically loaded, but it does not work. I have posted the details here: http://forums.opensuse.org/network- internet/wireless/400074-atheros-5005g-card-doesnt-find-signal.html#post1898247 Larry proposed me to mail the output of dmesg to you. I would appreciate if you could help me solving this issue. Thanks in advance Alexander ---------------------------------------------------- The critical section is as follows: ath5k_pci 0000:02:00.0: registered as 'phy0' phy0: Selected rate control algorithm 'pid' ath5k phy0: Atheros AR5213A chip found (MAC: 0x78, PHY: 0x45) ath5k phy0: RF2112A 2GHz radio found (0x56) ADDRCONF(NETDEV_UP): wlan0: link is not ready ath5k phy0: failed to wakeup the MAC Chip ath5k phy0: can't reset hardware (-5) pccard: card ejected from slot 0 It appears that the ath5k driver does not support the

Re: BCM4312 Fails when xdm is started

Yuval Hager — 2008-11-22T06:39:24

When the wireless is working: $ lspci -d 14e4:4312 -x 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 02) 00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00 10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00 After it fails: $ lspci -d 14e4:4312 -x 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 02) 00: e4 14 12 43 00 00 10 00 02 00 80 02 00 00 00 00 10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00 Sorry for the long time to reply, it took a while to recreate the problem. According to the logs, it happened exactly when I checked the machine in the morning. At the beginning, the register dumps look like this: [ 57.279984] ****** b43: B43_MMIO_MACCTL 0x840A0503 [ 57.279992] ****** b43: SSB_TMSLOW 0x20150000 (these line repeat exactly the s