iwlwifi-driver card doesn't work with 3.19-rc2+

iwlwifi-driver card doesn't work with 3.19-rc2+

[Jiri Kosina]

Hi,

I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and 
wifi doesn't work. iwconfig is telling me that wlan0 interface has no 
wireless extensions.

Previous kernel that is known to work on this machine is 3.18-rc5. I can 
do a bisect if needed, but wanted to ask in case this is a known problem.

Please find the relevant part of dmesg below. The card in question is 
this:

03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection [8086:4237]
        Subsystem: Intel Corporation WiFi Link 5100 AGN [8086:1211]
        Flags: bus master, fast devsel, latency 0, IRQ 29
        Memory at f2500000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [e0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 00-22-fa-ff-ff-34-b0-4c
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi



=== snip ===
[    6.357092] Intel(R) Wireless WiFi driver for Linux, in-tree:d
[    6.358637] Copyright(c) 2003- 2014 Intel Corporation
[    6.387473] iwlwifi 0000:03:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
[    6.399552] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:1f:16:15:7a:65
[    6.401162] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    6.402751] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 8, PBA No: 1008FF-0FF
[    6.404838] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
[    6.407182] ACPI Warning: SystemIO range 0x0000000000001028-0x000000000000102f conflicts with OpRegion 0x0000000000001000-0x000000000000107f (\_SB_.PCI0.LPC_.PMIO) (20141107/utaddress-258)
[    6.410662] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    6.412580] ACPI Warning: SystemIO range 0x00000000000011b0-0x00000000000011bf conflicts with OpRegion 0x0000000000001180-0x00000000000011ff (\_SB_.PCI0.LPC_.LPIO) (20141107/utaddress-258)
[    6.416296] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    6.418145] ACPI Warning: SystemIO range 0x0000000000001180-0x00000000000011af conflicts with OpRegion 0x0000000000001180-0x00000000000011ff (\_SB_.PCI0.LPC_.LPIO) (20141107/utaddress-258)
[    6.422111] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    6.424214] lpc_ich: Resource conflict(s) found affecting gpio_ich
[    6.432054] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c
[    6.440414] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c
[    6.444012] microcode: CPU0 updated to revision 0x60f, date = 2010-09-29
[    6.451926] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c
[    6.479540] thinkpad_acpi: ThinkPad ACPI Extras v0.25
[    6.481632] thinkpad_acpi: http://ibm-acpi.sf.net/
[    6.483636] thinkpad_acpi: ThinkPad BIOS 6DET38WW (2.02 ), EC 7XHT21WW-1.03
[    6.485724] thinkpad_acpi: Lenovo ThinkPad X200s, model 7470BN2
[    6.513239] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c
[    6.516007] microcode: CPU1 updated to revision 0x60f, date = 2010-09-29
[    6.525254] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    6.557365] thinkpad_acpi: detected a 16-level brightness capable ThinkPad
[    6.561203] thinkpad_acpi: radio switch found; radios are enabled
[    6.563537] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
[    6.565722] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
[    6.582468] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked
[    6.613516] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
[    6.628357] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input8
[    6.830228] sound hdaudioC0D0: CX20561 (Hermosa): BIOS auto-probing.
[    6.835254] sound hdaudioC0D0: autoconfig: line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker
[    6.837530] sound hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    6.839860] sound hdaudioC0D0:    hp_outs=2 (0x19/0x16/0x0/0x0/0x0)
[    6.842102] sound hdaudioC0D0:    mono: mono_out=0x0
[    6.844365] sound hdaudioC0D0:    dig-out=0x1c/0x0
[    6.846498] sound hdaudioC0D0:    inputs:
[    6.848629] sound hdaudioC0D0:      Mic=0x18
[    6.850637] sound hdaudioC0D0:      Internal Mic=0x1d
[    6.850639] sound hdaudioC0D0:      Dock Mic=0x17
[    6.855780] sound hdaudioC0D0: Enable sync_write for stable communication
[    6.887289] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input9
[    6.895980] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[    6.899740] input: HDA Intel Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[    6.910154] input: HDA Intel Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[    6.919309] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
[    6.935484] Adding 2104476k swap on /dev/sda1.  Priority:-1 extents:1 across:2104476k SS
[    6.959360] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[    6.961480] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[    6.963595] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[    6.965638] iwlwifi 0000:03:00.0: Detected Intel(R) WiFi Link 5100 AGN, REV=0x54
[    6.968106] iwlwifi 0000:03:00.0: L1 Disabled - LTR Disabled
[    7.020451] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[    7.034582] iTCO_vendor_support: vendor-support=0
[    7.037422] cfg80211: World regulatory domain updated:
[    7.039411] cfg80211:  DFS Master region: unset
[    7.039440] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[    7.043249] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[    7.045119] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[    7.046891] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[    7.048649] cfg80211:   (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
[    7.050432] cfg80211:   (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[    7.052058] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[    7.053637] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[    7.055220] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
=== snip ===

-- 
Jiri Kosina
SUSE Labs

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Emmanuel Grumbach]

On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>
> Hi,
>
> I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and
> wifi doesn't work. iwconfig is telling me that wlan0 interface has no
> wireless extensions.
>

So why do you used them?
They have been deprecated for a couple of years now. You should be
using nl80211 based tools such as iw.

> Previous kernel that is known to work on this machine is 3.18-rc5. I can
> do a bisect if needed, but wanted to ask in case this is a known problem.
>

3.19 is the first kernel that actually removed the wireless extensions.

> Please find the relevant part of dmesg below. The card in question is
> this:
>
> 03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection [8086:4237]
>         Subsystem: Intel Corporation WiFi Link 5100 AGN [8086:1211]
>         Flags: bus master, fast devsel, latency 0, IRQ 29
>         Memory at f2500000 (64-bit, non-prefetchable) [size=8K]
>         Capabilities: [c8] Power Management version 3
>         Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Capabilities: [e0] Express Endpoint, MSI 00
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [140] Device Serial Number 00-22-fa-ff-ff-34-b0-4c
>         Kernel driver in use: iwlwifi
>         Kernel modules: iwlwifi
>
>
>
> === snip ===
> [    6.357092] Intel(R) Wireless WiFi driver for Linux, in-tree:d
> [    6.358637] Copyright(c) 2003- 2014 Intel Corporation
> [    6.387473] iwlwifi 0000:03:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
> [    6.399552] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:1f:16:15:7a:65
> [    6.401162] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
> [    6.402751] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 8, PBA No: 1008FF-0FF
> [    6.404838] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
> [    6.407182] ACPI Warning: SystemIO range 0x0000000000001028-0x000000000000102f conflicts with OpRegion 0x0000000000001000-0x000000000000107f (\_SB_.PCI0.LPC_.PMIO) (20141107/utaddress-258)
> [    6.410662] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [    6.412580] ACPI Warning: SystemIO range 0x00000000000011b0-0x00000000000011bf conflicts with OpRegion 0x0000000000001180-0x00000000000011ff (\_SB_.PCI0.LPC_.LPIO) (20141107/utaddress-258)
> [    6.416296] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [    6.418145] ACPI Warning: SystemIO range 0x0000000000001180-0x00000000000011af conflicts with OpRegion 0x0000000000001180-0x00000000000011ff (\_SB_.PCI0.LPC_.LPIO) (20141107/utaddress-258)
> [    6.422111] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [    6.424214] lpc_ich: Resource conflict(s) found affecting gpio_ich
> [    6.432054] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c
> [    6.440414] microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c
> [    6.444012] microcode: CPU0 updated to revision 0x60f, date = 2010-09-29
> [    6.451926] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c
> [    6.479540] thinkpad_acpi: ThinkPad ACPI Extras v0.25
> [    6.481632] thinkpad_acpi: http://ibm-acpi.sf.net/
> [    6.483636] thinkpad_acpi: ThinkPad BIOS 6DET38WW (2.02 ), EC 7XHT21WW-1.03
> [    6.485724] thinkpad_acpi: Lenovo ThinkPad X200s, model 7470BN2
> [    6.513239] microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c
> [    6.516007] microcode: CPU1 updated to revision 0x60f, date = 2010-09-29
> [    6.525254] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    6.557365] thinkpad_acpi: detected a 16-level brightness capable ThinkPad
> [    6.561203] thinkpad_acpi: radio switch found; radios are enabled
> [    6.563537] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
> [    6.565722] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
> [    6.582468] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked
> [    6.613516] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
> [    6.628357] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input8
> [    6.830228] sound hdaudioC0D0: CX20561 (Hermosa): BIOS auto-probing.
> [    6.835254] sound hdaudioC0D0: autoconfig: line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker
> [    6.837530] sound hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> [    6.839860] sound hdaudioC0D0:    hp_outs=2 (0x19/0x16/0x0/0x0/0x0)
> [    6.842102] sound hdaudioC0D0:    mono: mono_out=0x0
> [    6.844365] sound hdaudioC0D0:    dig-out=0x1c/0x0
> [    6.846498] sound hdaudioC0D0:    inputs:
> [    6.848629] sound hdaudioC0D0:      Mic=0x18
> [    6.850637] sound hdaudioC0D0:      Internal Mic=0x1d
> [    6.850639] sound hdaudioC0D0:      Dock Mic=0x17
> [    6.855780] sound hdaudioC0D0: Enable sync_write for stable communication
> [    6.887289] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input9
> [    6.895980] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
> [    6.899740] input: HDA Intel Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
> [    6.910154] input: HDA Intel Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
> [    6.919309] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
> [    6.935484] Adding 2104476k swap on /dev/sda1.  Priority:-1 extents:1 across:2104476k SS
> [    6.959360] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
> [    6.961480] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
> [    6.963595] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
> [    6.965638] iwlwifi 0000:03:00.0: Detected Intel(R) WiFi Link 5100 AGN, REV=0x54
> [    6.968106] iwlwifi 0000:03:00.0: L1 Disabled - LTR Disabled
> [    7.020451] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
> [    7.034582] iTCO_vendor_support: vendor-support=0
> [    7.037422] cfg80211: World regulatory domain updated:
> [    7.039411] cfg80211:  DFS Master region: unset
> [    7.039440] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> [    7.043249] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [    7.045119] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
> [    7.046891] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
> [    7.048649] cfg80211:   (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
> [    7.050432] cfg80211:   (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
> [    7.052058] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
> [    7.053637] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
> [    7.055220] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
> === snip ===
>
> --
> Jiri Kosina
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Peter Hurley]

On 12/30/2014 09:23 AM, Emmanuel Grumbach wrote:
> On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>>
>> Hi,
>>
>> I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and
>> wifi doesn't work. iwconfig is telling me that wlan0 interface has no
>> wireless extensions.
>>
> 
> So why do you used them?
> They have been deprecated for a couple of years now. You should be
> using nl80211 based tools such as iw.

A couple of years is not very long where userspace is concerned.

Regards,
Peter Hurley

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

[Grumbach, Emmanuel]

PiANCj4gT24gMTIvMzAvMjAxNCAwOToyMyBBTSwgRW1tYW51ZWwgR3J1bWJhY2ggd3JvdGU6DQo+
ID4gT24gVHVlLCBEZWMgMzAsIDIwMTQgYXQgMzozMyBQTSwgSmlyaSBLb3NpbmEgPGprb3NpbmFA
c3VzZS5jej4gd3JvdGU6DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBJIGp1c3QgYm9vdGVk
IGN1cnJlbnQgTGludXMnIHRyZWUgKDVmYWEwMTU0ZmUzMykgb24gbXkgeDIwMHMNCj4gPj4gdGhp
bmtwYWQsIGFuZCB3aWZpIGRvZXNuJ3Qgd29yay4gaXdjb25maWcgaXMgdGVsbGluZyBtZSB0aGF0
IHdsYW4wDQo+ID4+IGludGVyZmFjZSBoYXMgbm8gd2lyZWxlc3MgZXh0ZW5zaW9ucy4NCj4gPj4N
Cj4gPg0KPiA+IFNvIHdoeSBkbyB5b3UgdXNlZCB0aGVtPw0KPiA+IFRoZXkgaGF2ZSBiZWVuIGRl
cHJlY2F0ZWQgZm9yIGEgY291cGxlIG9mIHllYXJzIG5vdy4gWW91IHNob3VsZCBiZQ0KPiA+IHVz
aW5nIG5sODAyMTEgYmFzZWQgdG9vbHMgc3VjaCBhcyBpdy4NCj4gDQo+IEEgY291cGxlIG9mIHll
YXJzIGlzIG5vdCB2ZXJ5IGxvbmcgd2hlcmUgdXNlcnNwYWNlIGlzIGNvbmNlcm5lZC4NCj4gDQpX
ZWxsIC0gdGhlIGRlY2VudGx5IG5ldyB3aXJlbGVzcyB0b29scyBkbyB0YWxrIG5sODAyMTEuDQpZ
b3UgY2FuIHN0aWxsIGVuYWJsZSBpdCAoQ0ZHODAyMTFfV0VYVCkuDQpJdCBoYXMgYmVlbiBkaXNh
YmxlZCBieToNCg0KY29tbWl0IDI0YTBhYTIxMmVlMmRiZTQ0MzYwMjg4Njg0NDc4ZDc2YThlMjBh
MGENCkF1dGhvcjogSm9oYW5uZXMgQmVyZyA8am9oYW5uZXMuYmVyZ0BpbnRlbC5jb20+DQpEYXRl
OiAgIEZyaSBOb3YgMjggMTI6MTQ6MDYgMjAxNCArMDEwMA0KDQogICAgY2ZnODAyMTE6IG1ha2Ug
V0VYVCBjb21wYXRpYmlsaXR5IHVuc2VsZWN0YWJsZQ0K

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

[Jiri Kosina]

On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote:

> > > So why do you used them?
> > > They have been deprecated for a couple of years now. You should be
> > > using nl80211 based tools such as iw.
> > 
> > A couple of years is not very long where userspace is concerned.
> > 
> Well - the decently new wireless tools do talk nl80211.

With 3.18-rc5, I get this:

# iwconfig --version
iwconfig  Wireless-Tools version 30
          Compatible with Wireless Extension v11 to v22.

Kernel    Currently compiled with Wireless Extension v22.

wlan0     Recommend Wireless Extension v21 or later,
          Currently compiled with Wireless Extension v22.


With 3.19-rc, I get (with the same userspace) this:

# iwconfig --version
iwconfig  Wireless-Tools version 30
          Compatible with Wireless Extension v11 to v22.

          Cannot read /proc/net/wireless

And nothing else (iwlist, etc) works either. This is with

# rpm -qi wireless-tools | grep Ver
Version     : 30.pre9

from openSUSE 13.2. That's not decently new enough?

> You can still enable it (CFG80211_WEXT).
> It has been disabled by:
> 
> commit 24a0aa212ee2dbe44360288684478d76a8e20a0a
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Fri Nov 28 12:14:06 2014 +0100
>
>    cfg80211: make WEXT compatibility unselectable

I think this needs to be reverted.

-- 
Jiri Kosina
SUSE Labs

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Grumbach, Emmanuel]

T24gVHVlLCAyMDE0LTEyLTMwIGF0IDE2OjIxICswMTAwLCBKaXJpIEtvc2luYSB3cm90ZToNCj4g
T24gVHVlLCAzMCBEZWMgMjAxNCwgR3J1bWJhY2gsIEVtbWFudWVsIHdyb3RlOg0KPiANCj4gPiA+
ID4gU28gd2h5IGRvIHlvdSB1c2VkIHRoZW0/DQo+ID4gPiA+IFRoZXkgaGF2ZSBiZWVuIGRlcHJl
Y2F0ZWQgZm9yIGEgY291cGxlIG9mIHllYXJzIG5vdy4gWW91IHNob3VsZCBiZQ0KPiA+ID4gPiB1
c2luZyBubDgwMjExIGJhc2VkIHRvb2xzIHN1Y2ggYXMgaXcuDQo+ID4gPiANCj4gPiA+IEEgY291
cGxlIG9mIHllYXJzIGlzIG5vdCB2ZXJ5IGxvbmcgd2hlcmUgdXNlcnNwYWNlIGlzIGNvbmNlcm5l
ZC4NCj4gPiA+IA0KPiA+IFdlbGwgLSB0aGUgZGVjZW50bHkgbmV3IHdpcmVsZXNzIHRvb2xzIGRv
IHRhbGsgbmw4MDIxMS4NCj4gDQo+IFdpdGggMy4xOC1yYzUsIEkgZ2V0IHRoaXM6DQo+IA0KPiAj
IGl3Y29uZmlnIC0tdmVyc2lvbg0KPiBpd2NvbmZpZyAgV2lyZWxlc3MtVG9vbHMgdmVyc2lvbiAz
MA0KPiAgICAgICAgICAgQ29tcGF0aWJsZSB3aXRoIFdpcmVsZXNzIEV4dGVuc2lvbiB2MTEgdG8g
djIyLg0KPiANCj4gS2VybmVsICAgIEN1cnJlbnRseSBjb21waWxlZCB3aXRoIFdpcmVsZXNzIEV4
dGVuc2lvbiB2MjIuDQo+IA0KPiB3bGFuMCAgICAgUmVjb21tZW5kIFdpcmVsZXNzIEV4dGVuc2lv
biB2MjEgb3IgbGF0ZXIsDQo+ICAgICAgICAgICBDdXJyZW50bHkgY29tcGlsZWQgd2l0aCBXaXJl
bGVzcyBFeHRlbnNpb24gdjIyLg0KPiANCj4gDQo+IFdpdGggMy4xOS1yYywgSSBnZXQgKHdpdGgg
dGhlIHNhbWUgdXNlcnNwYWNlKSB0aGlzOg0KPiANCj4gIyBpd2NvbmZpZyAtLXZlcnNpb24NCj4g
aXdjb25maWcgIFdpcmVsZXNzLVRvb2xzIHZlcnNpb24gMzANCj4gICAgICAgICAgIENvbXBhdGli
bGUgd2l0aCBXaXJlbGVzcyBFeHRlbnNpb24gdjExIHRvIHYyMi4NCj4gDQo+ICAgICAgICAgICBD
YW5ub3QgcmVhZCAvcHJvYy9uZXQvd2lyZWxlc3MNCj4gDQo+IEFuZCBub3RoaW5nIGVsc2UgKGl3
bGlzdCwgZXRjKSB3b3JrcyBlaXRoZXIuIFRoaXMgaXMgd2l0aA0KPiANCj4gIyBycG0gLXFpIHdp
cmVsZXNzLXRvb2xzIHwgZ3JlcCBWZXINCj4gVmVyc2lvbiAgICAgOiAzMC5wcmU5DQo+IA0KPiBm
cm9tIG9wZW5TVVNFIDEzLjIuIFRoYXQncyBub3QgZGVjZW50bHkgbmV3IGVub3VnaD8NCj4gDQoN
CllvdSBzaG91bGQgYWxzbyBoYXZlIHRoZSBpdyB0b29sIHdoaWNoIHdpbGwgcHJvdmlkZSBhbGwg
eW91IG5lZWQNCnVzaW5nIHRoZSBubDgwMjExIGludGVyZmFjZSB3aGljaCBpcyBub3cgdGhlIHBy
ZWZlcnJlZCBpbnRlcmZhY2UuDQoNCj4gPiBZb3UgY2FuIHN0aWxsIGVuYWJsZSBpdCAoQ0ZHODAy
MTFfV0VYVCkuDQo+ID4gSXQgaGFzIGJlZW4gZGlzYWJsZWQgYnk6DQo+ID4gDQo+ID4gY29tbWl0
IDI0YTBhYTIxMmVlMmRiZTQ0MzYwMjg4Njg0NDc4ZDc2YThlMjBhMGENCj4gPiBBdXRob3I6IEpv
aGFubmVzIEJlcmcgPGpvaGFubmVzLmJlcmdAaW50ZWwuY29tPg0KPiA+IERhdGU6ICAgRnJpIE5v
diAyOCAxMjoxNDowNiAyMDE0ICswMTAwDQo+ID4NCj4gPiAgICBjZmc4MDIxMTogbWFrZSBXRVhU
IGNvbXBhdGliaWxpdHkgdW5zZWxlY3RhYmxlDQo+IA0KPiBJIHRoaW5rIHRoaXMgbmVlZHMgdG8g
YmUgcmV2ZXJ0ZWQuDQo+IA0KDQo=

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Jiri Kosina]

On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote:

> You should also have the iw tool which will provide all you need
> using the nl80211 interface which is now the preferred interface.

There indeed is an iw tool.

The thing is really as simple as -- userspace which is calling other 
wireless-utils directly (such as, but absolutely not limited to, wicd), 
will completely stop working after commit 24a0aa212e.

I am still convinced that 24a0aa212e needs to be reverted, and compat 
layer maintained for *much* longer than 2 years.

If wireless maintainers think otherwise, I'll send a revert request to 
Linus for consideration.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Borislav Petkov]

On Tue, Dec 30, 2014 at 09:41:41PM +0100, Jiri Kosina wrote:
> If wireless maintainers think otherwise, I'll send a revert request to
> Linus for consideration.

I wonder if the reaction would be like this one:

https://lkml.org/lkml/2012/12/23/75

:-)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Larry Finger]

On 12/30/2014 03:23 PM, Borislav Petkov wrote:
> On Tue, Dec 30, 2014 at 09:41:41PM +0100, Jiri Kosina wrote:
>> If wireless maintainers think otherwise, I'll send a revert request to
>> Linus for consideration.
>
> I wonder if the reaction would be like this one:
>
> https://lkml.org/lkml/2012/12/23/75
>
> :-)

It would be a little like that.

One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit 
24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made it 
impossible to select the IPW2200. The patch to allow selecting the IPW2200, 
which automatically selects CFG80211_WEXT has been added to wireless-drivers, 
but it has not yet made it to mainline. Once it does, then choosing to build the 
IPW2200 will provide a workaround.

In my opinion, the need for the IPW2200 to have CFG80211_WEXT means that the 
original commit will likely be reverted, but your voice will help.

I use openSUSE 13.2, but I control my wireless with NetworkManager. For that 
reason, this is a non-issue for me.

Larry

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Jiri Kosina]

On Tue, 30 Dec 2014, Larry Finger wrote:

> > > If wireless maintainers think otherwise, I'll send a revert request to
> > > Linus for consideration.
> > 
> > I wonder if the reaction would be like this one:
> > 
> > https://lkml.org/lkml/2012/12/23/75
> > 
> > :-)
> 
> It would be a little like that.
> 
> One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
> 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made it
> impossible to select the IPW2200. The patch to allow selecting the IPW2200,
> which automatically selects CFG80211_WEXT has been added to wireless-drivers,
> but it has not yet made it to mainline. Once it does, then choosing to build
> the IPW2200 will provide a workaround.
> 
> In my opinion, the need for the IPW2200 to have CFG80211_WEXT means that the
> original commit will likely be reverted, but your voice will help.

Ok, thanks a lot for another datapoint. I am sending revert patch to Linus 
tonight.

-- 
Jiri Kosina
SUSE Labs

[PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Jiri Kosina]

This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.

It's causing severe userspace breakage. Namely, all the utilities
from wireless-utils which are relying on CONFIG_WEXT (which means
tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
is a 'iw' utility in newer wireless-tools, which is supposed to be
a replacement for all the "deprecated" binaries, but it's far away
from being massively adopted.

Please see [1] for example of the userspace breakage this is causing.

In addition to that, Larry Finger reports [2] that this patch is also
causing ipw2200 driver being impossible to build.

To me this clearly shows that CONFIG_WEXT is far, far away from being
"deprecated enough" to be removed.

[1] http://thread.gmane.org/gmane.linux.kernel/1857010
[2] http://thread.gmane.org/gmane.linux.network/343688

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 net/wireless/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 22ba971..29c8675 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
 	  Most distributions have a CRDA package.  So if unsure, say N.
 
 config CFG80211_WEXT
-	bool
+	bool "cfg80211 wireless extensions compatibility"
 	depends on CFG80211
 	select WEXT_CORE
 	help
-- 
Jiri Kosina
SUSE Labs

RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Grumbach, Emmanuel]

> Subject: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
> 
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
> 
> It's causing severe userspace breakage. Namely, all the utilities from
> wireless-utils which are relying on CONFIG_WEXT (which means tools like
> 'iwconfig', 'iwlist', etc) are not working anymore. There is a 'iw' utility in
> newer wireless-tools, which is supposed to be a replacement for all the
> "deprecated" binaries, but it's far away from being massively adopted.
> 
> Please see [1] for example of the userspace breakage this is causing.
> 
> In addition to that, Larry Finger reports [2] that this patch is also causing
> ipw2200 driver being impossible to build.
> 
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.
> 
> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Wait. I don't want to discuss the userspace API deprecation here but
I do think that this patch should be applied to the proper tree if at all.
The proper tree is mac80211.git. Now you are unhappy with what happens
there and want to escalate - fine. But then, please do so following the
natural hierarchy of the trees: net.git. Then mac80211.git's maintainer
(Johannes) will be able to sync with your change more easily.
Johannes doesn't need me as an advocate, but I feel that reverting a
mac80211 patch in linux.git while we are only in -rc2 while everybody
is on holiday leave is a bit unfair.

> ---
>  net/wireless/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index
> 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
>  	  Most distributions have a CRDA package.  So if unsure, say N.
> 
>  config CFG80211_WEXT
> -	bool
> +	bool "cfg80211 wireless extensions compatibility"
>  	depends on CFG80211
>  	select WEXT_CORE
>  	help
> --
> Jiri Kosina
> SUSE Labs

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/30/14 23:52, Jiri Kosina wrote:
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>
> It's causing severe userspace breakage. Namely, all the utilities
> from wireless-utils which are relying on CONFIG_WEXT (which means
> tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
> is a 'iw' utility in newer wireless-tools, which is supposed to be
> a replacement for all the "deprecated" binaries, but it's far away
> from being massively adopted.
>
> Please see [1] for example of the userspace breakage this is causing.
>
> In addition to that, Larry Finger reports [2] that this patch is also
> causing ipw2200 driver being impossible to build.
>
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.

Hi Jiri,

You mentioned in the discussion and I quote: "*If* wireless maintainers 
think otherwise, I'll send a revert request to Linus for 
consideration.". However, you did not wait for any response from the 
wireless maintainers nor from the author of the patch you are reverting. 
Seems like an overreaction to me though personally I do not disgree with 
the revert itself.

Regards,
Arend

> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688
>
> Signed-off-by: Jiri Kosina<jkosina@suse.cz>
> ---
>   net/wireless/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
>   	  Most distributions have a CRDA package.  So if unsure, say N.
>
>   config CFG80211_WEXT
> -	bool
> +	bool "cfg80211 wireless extensions compatibility"
>   	depends on CFG80211
>   	select WEXT_CORE
>   	help

RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Grumbach, Emmanuel]

> On 12/30/14 23:52, Jiri Kosina wrote:
> > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
> >
> > It's causing severe userspace breakage. Namely, all the utilities from
> > wireless-utils which are relying on CONFIG_WEXT (which means tools
> > like 'iwconfig', 'iwlist', etc) are not working anymore. There is a
> > 'iw' utility in newer wireless-tools, which is supposed to be a
> > replacement for all the "deprecated" binaries, but it's far away from
> > being massively adopted.
> >
> > Please see [1] for example of the userspace breakage this is causing.
> >
> > In addition to that, Larry Finger reports [2] that this patch is also
> > causing ipw2200 driver being impossible to build.
> >
> > To me this clearly shows that CONFIG_WEXT is far, far away from being
> > "deprecated enough" to be removed.
> 
> Hi Jiri,
> 
> You mentioned in the discussion and I quote: "*If* wireless maintainers think
> otherwise, I'll send a revert request to Linus for consideration.". However,
> you did not wait for any response from the wireless maintainers nor from the
> author of the patch you are reverting.
> Seems like an overreaction to me though personally I do not disgree with the
> revert itself.

Not to mention the patch has already been applied on Linus's tree...

> 
> Regards,
> Arend
> 
> > [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> > [2] http://thread.gmane.org/gmane.linux.network/343688
> >
> > Signed-off-by: Jiri Kosina<jkosina@suse.cz>
> > ---
> >   net/wireless/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index
> > 22ba971..29c8675 100644
> > --- a/net/wireless/Kconfig
> > +++ b/net/wireless/Kconfig
> > @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
> >   	  Most distributions have a CRDA package.  So if unsure, say N.
> >
> >   config CFG80211_WEXT
> > -	bool
> > +	bool "cfg80211 wireless extensions compatibility"
> >   	depends on CFG80211
> >   	select WEXT_CORE
> >   	help

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/31/14 12:10, Grumbach, Emmanuel wrote:
>> On 12/30/14 23:52, Jiri Kosina wrote:
>>> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>>>
>>> It's causing severe userspace breakage. Namely, all the utilities from
>>> wireless-utils which are relying on CONFIG_WEXT (which means tools
>>> like 'iwconfig', 'iwlist', etc) are not working anymore. There is a
>>> 'iw' utility in newer wireless-tools, which is supposed to be a
>>> replacement for all the "deprecated" binaries, but it's far away from
>>> being massively adopted.
>>>
>>> Please see [1] for example of the userspace breakage this is causing.
>>>
>>> In addition to that, Larry Finger reports [2] that this patch is also
>>> causing ipw2200 driver being impossible to build.
>>>
>>> To me this clearly shows that CONFIG_WEXT is far, far away from being
>>> "deprecated enough" to be removed.
>>
>> Hi Jiri,
>>
>> You mentioned in the discussion and I quote: "*If* wireless maintainers think
>> otherwise, I'll send a revert request to Linus for consideration.". However,
>> you did not wait for any response from the wireless maintainers nor from the
>> author of the patch you are reverting.
>> Seems like an overreaction to me though personally I do not disgree with the
>> revert itself.
>
> Not to mention the patch has already been applied on Linus's tree...

Water under the bridge. The thing with WEXT is that it will stay as is. 
So if tools like wicd want to support new features like P2P it will need 
to make the switch. I checked out wicd repo and found a number of 
iwconfig calls and they kick off wpa_supplicant with wext driver.

With libnl python support wicd could use nl80211 directly avoiding 
screen-scraping iw output, but it seems not included in distros.

Regards,
Arend

>>
>> Regards,
>> Arend
>>
>>> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
>>> [2] http://thread.gmane.org/gmane.linux.network/343688
>>>
>>> Signed-off-by: Jiri Kosina<jkosina@suse.cz>
>>> ---
>>>    net/wireless/Kconfig | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index
>>> 22ba971..29c8675 100644
>>> --- a/net/wireless/Kconfig
>>> +++ b/net/wireless/Kconfig
>>> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
>>>    	  Most distributions have a CRDA package.  So if unsure, say N.
>>>
>>>    config CFG80211_WEXT
>>> -	bool
>>> +	bool "cfg80211 wireless extensions compatibility"
>>>    	depends on CFG80211
>>>    	select WEXT_CORE
>>>    	help
>

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Jiri Kosina]

On Wed, 31 Dec 2014, Arend van Spriel wrote:

> The thing with WEXT is that it will stay as is. So if tools like wicd 
> want to support new features like P2P it will need to make the switch. I 
> checked out wicd repo and found a number of iwconfig calls and they kick 
> off wpa_supplicant with wext driver.

Unfortunately this is by no means just about wicd. I have already received 
a few off-list mails from people who were wondering why their home-made 
scripts / tools, which are running 'iwconfig' directly suddenly stopped to 
work, and that it was indeed fallout of WEXT going away. Given the very 
short time this has been in mainline, you can probably imagine the 
fireworks once this appears in major release.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/31/14 15:07, Jiri Kosina wrote:
> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>
>> The thing with WEXT is that it will stay as is. So if tools like wicd
>> want to support new features like P2P it will need to make the switch. I
>> checked out wicd repo and found a number of iwconfig calls and they kick
>> off wpa_supplicant with wext driver.
>
> Unfortunately this is by no means just about wicd. I have already received
> a few off-list mails from people who were wondering why their home-made
> scripts / tools, which are running 'iwconfig' directly suddenly stopped to
> work, and that it was indeed fallout of WEXT going away. Given the very
> short time this has been in mainline, you can probably imagine the
> fireworks once this appears in major release.

It is unfortunately indeed. I think iwconfig and friends will never go 
away although iw is a better alternative, simply because people don't 
like to change their home-made scripts/tools. WIRELESS_EXT actually is 
largely, but not entirely, gone in upstream drivers and what we are 
talking about here is CFG80211_WEXT which allows WEXT userspace to 
interact with cfg80211-based drivers through a compatibility layer.

Regards,
Arend

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Theodore Ts'o]

On Wed, Dec 31, 2014 at 04:02:24PM +0100, Arend van Spriel wrote:
> 
> It is unfortunately indeed. I think iwconfig and friends will never go away
> although iw is a better alternative, simply because people don't like to
> change their home-made scripts/tools. WIRELESS_EXT actually is largely, but
> not entirely, gone in upstream drivers and what we are talking about here is
> CFG80211_WEXT which allows WEXT userspace to interact with cfg80211-based
> drivers through a compatibility layer.

Most poeple are still using "route" and "ifconfig" instead of "ip".
Deal with it.  Personally, I find it much easier to use the existing
commands instead of figuring all of the various subcommands, and the
options to the subcommands to commands like "ip" and "iw".  At least
"ip help route" will give me all of the options to "ip route", where
as "iw help phy" doesn't tell give me the options; instead I have to
paw through 300 lines of "iw help" in order to find the command I
need.  So having a better user interface / help system so people can
better understand how to use iw would be a great step forward.

Better yet, why not hack into the "iw" command backwards compatibility
so that if argv[0] is "iwlist" or "iwconfig", it provides the limited
subset compatibility to the legacy commands.  Then all you need to do
is to convince the distributions to set up the packaging rules so that
"iw" conflicts with wireless-tools, and you will be able to get
everyone switched over to iw after at least seven years. 

Note that I said *seven* years --- there are people who try to use an
enterprise kernel, or an older Debian Stable or Ubuntu LTS userspace,
with a newer kernel, and and if said users notice, and complain, Linus
*will* revert the commit.  (Note that I've worked at more than one
company where I was forced to use an older Ubuntu LTS or RHEL distro
if I wanted to connect to the intranet, and I was using bleeding edge
kernels --- and if anything like that had broken, I would have
complained directly to Linus, cc'ing the patch author and the wireless
maintainers with the revert.  And while I fortunately am not trying to
do upstream development with a stable distro, be sure there are other
such folks around who have to live with similar restrictions.)

   	      	  	     	   - Ted

P.S.  If you really think it's evil that users use the
simpler-to-understand iwconfig/iwlist interface over the iw command
line interface, if you provide full backwards compatibility for the
iwconfig/iwlist commands so you can "take over" from wireless-tools,
you could even have a mode which, in addition to doing what the user
wants, prints a "by the way, here's the equivalent if you want to use
the iw command instead".  I don't see the reason of allowing users to
continue to use iwconfig and iwlist, though --- face it, route and
ifconfig are going to be around for a long time; why not let users use
iwconfig and iwlist if it's sufficient for their needs?

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Linus Torvalds]

On Wed, Dec 31, 2014 at 9:31 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> Most poeple are still using "route" and "ifconfig" instead of "ip".
> Deal with it.

Indeed. This whole "let's throw out the old and broken" stuff is a disease.

It would have been much better (and it's still an option, as Ted
points out) for the new commands to provide compatibility with what
users - and scripts - have been doing for ages with the old ones.

As it is, this inability for the new tools to just do what the old
tools did clearly just means that not just the old tools, but all the
old infrastructure, will need to be around for years to come.

Thinking you can just start from a clean slate is naive, bordering on
stupid. "New and improved" is only really improved if it also takes
backwards compatibility into account, rather than saying "now
everybody must do things the new and improved - and different - way"

We've succeeded in getting rid of some old interfaces in the kernel,
but it has usually been for some *really* esoteric stuff that nobody
does by hand. And even then it has generally been an uphill battle,
and in most cases we've ended up having the rule that new capabilities
absolutely *have* to be a superset of the old, and we continue to
support the old model using the new code.

It's entirely possible that we might be able to cut down on the WEXT
support a tiny bit by slowly removing some parts of it that nobody
uses and depends on, but the whole "let's just make it a non-option"
was clearly just a drug-fueled bad fantasy.

                     Linus

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/31/14 18:31, Theodore Ts'o wrote:
> On Wed, Dec 31, 2014 at 04:02:24PM +0100, Arend van Spriel wrote:
>>
>> It is unfortunately indeed. I think iwconfig and friends will never go away
>> although iw is a better alternative, simply because people don't like to
>> change their home-made scripts/tools. WIRELESS_EXT actually is largely, but
>> not entirely, gone in upstream drivers and what we are talking about here is
>> CFG80211_WEXT which allows WEXT userspace to interact with cfg80211-based
>> drivers through a compatibility layer.
>
> Most poeple are still using "route" and "ifconfig" instead of "ip".
> Deal with it.  Personally, I find it much easier to use the existing
> commands instead of figuring all of the various subcommands, and the
> options to the subcommands to commands like "ip" and "iw".  At least
> "ip help route" will give me all of the options to "ip route", where
> as "iw help phy" doesn't tell give me the options; instead I have to
> paw through 300 lines of "iw help" in order to find the command I
> need.  So having a better user interface / help system so people can
> better understand how to use iw would be a great step forward.

Agree. I can't even recall using "ip" ever. iw help system does provide 
command specific help. The phy keyword is both a command and a selector 
key, which I realize is confusing to the user, eg. 'iw help info' does 
provide help for the 'info' subcommand.

> Better yet, why not hack into the "iw" command backwards compatibility
> so that if argv[0] is "iwlist" or "iwconfig", it provides the limited
> subset compatibility to the legacy commands.  Then all you need to do
> is to convince the distributions to set up the packaging rules so that
> "iw" conflicts with wireless-tools, and you will be able to get
> everyone switched over to iw after at least seven years.

Thanks. If there are still drivers, upstream or out-of-tree, providing 
only WEXT API this will not work unless iwconfig/iwlist can distinguish 
those from cfg80211-based drivers (which is possible) and fallback to 
WEXT ioctl syscalls. Just not sure if it is worth the effort. As you 
stated below, it does not seem "evil" to retain WEXT if that is 
providing users what they need.

Regards,
Arend

> Note that I said *seven* years --- there are people who try to use an
> enterprise kernel, or an older Debian Stable or Ubuntu LTS userspace,
> with a newer kernel, and and if said users notice, and complain, Linus
> *will* revert the commit.  (Note that I've worked at more than one
> company where I was forced to use an older Ubuntu LTS or RHEL distro
> if I wanted to connect to the intranet, and I was using bleeding edge
> kernels --- and if anything like that had broken, I would have
> complained directly to Linus, cc'ing the patch author and the wireless
> maintainers with the revert.  And while I fortunately am not trying to
> do upstream development with a stable distro, be sure there are other
> such folks around who have to live with similar restrictions.)
>
>     	      	  	     	   - Ted
>
> P.S.  If you really think it's evil that users use the
> simpler-to-understand iwconfig/iwlist interface over the iw command
> line interface, if you provide full backwards compatibility for the
> iwconfig/iwlist commands so you can "take over" from wireless-tools,
> you could even have a mode which, in addition to doing what the user
> wants, prints a "by the way, here's the equivalent if you want to use
> the iw command instead".  I don't see the reason of allowing users to
> continue to use iwconfig and iwlist, though --- face it, route and
> ifconfig are going to be around for a long time; why not let users use
> iwconfig and iwlist if it's sufficient for their needs?

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Theodore Ts'o]

On Wed, Dec 31, 2014 at 09:32:13PM +0100, Arend van Spriel wrote:
> 
> Agree. I can't even recall using "ip" ever. iw help system does provide
> command specific help. The phy keyword is both a command and a selector key,
> which I realize is confusing to the user, eg. 'iw help info' does provide
> help for the 'info' subcommand.

Yeah, the confusing part is that "ip" tends to use "verb object"
scheme, which is consistent with the Cisco IOS command set it was
trying to emulate.   So for ip, you do something like

ip link info eth0

Where as for "iw" it's almost exactly backwards, i.e.:

iw wlan0 info

It's actually rather unfortunate that there is no consistency between
many of these tools, for example:

ethtool --show-features eth0

If we were going to create a new interface, wouldn't be nice if we
could have some kind of consistency?  Sigh; oh well, water under the
bridge at this point.

> Thanks. If there are still drivers, upstream or out-of-tree, providing only
> WEXT API this will not work unless iwconfig/iwlist can distinguish those
> from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl
> syscalls. Just not sure if it is worth the effort. As you stated below, it
> does not seem "evil" to retain WEXT if that is providing users what they
> need.

Is it really that much effort?  Unless there is some license
incompatibility nonsense (i.e., GPLv2 vs GPLv3), the code's already
there in the wireless-tools source.  It would just be a matter of
trying the new ioctls first, and then falling back to the WEXT ones if
needed, right?

Cheers,

					- Ted

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Linus Torvalds]

On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> Yeah, the confusing part is that "ip" tends to use "verb object"
> scheme, which is consistent with the Cisco IOS command set it was
> trying to emulate.

Side note: does anybody think that was really a good idea to begin
with? I mean, Cisco iOS is just _soooo_ universally loved, right?

And yeah, I refuse to use "ip link" or other insane commands. Let's
face it, "ifconfig" and "route" are perfectly fine commands, and a
whole lot less confusing than "ip" with random crap after it.  I'm
really not seeing why that "ip" command was seen as an improvement.

(Ok, "ip route" isn't any more complex than "route", but "ip link"
sure as hell isn't simpler than "ifconfig" for most things I can think
of)

                     Linus

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Theodore Ts'o]

On Wed, Dec 31, 2014 at 01:57:59PM -0800, Linus Torvalds wrote:
> Side note: does anybody think that was really a good idea to begin
> with? I mean, Cisco iOS is just _soooo_ universally loved, right?

Well, at the time when it was "ip" came out, Cisco had a defacto
monopoly on routing equipment, and some of the folks who were working
on Linux networking had this insane dream of having Linux be better at
the routing game than Cisco (there was this minor issue of Cisco
having hardware assist for their fastpath :-).  So I think I
*understand* the rationale behind the design choice, even though it's
probably not the decision I would have made at the time, and certainly
not with the benefit of 20/20 hindsight!

And I won't say that I *loved* IOS, but I certainly used it enough
when I was working in the MIT Network Operations group.  :-)

> And yeah, I refuse to use "ip link" or other insane commands. Let's
> face it, "ifconfig" and "route" are perfectly fine commands, and a
> whole lot less confusing than "ip" with random crap after it.  I'm
> really not seeing why that "ip" command was seen as an improvement.

The real problem is that they were trying to do way more complicated
things in terms of routing rules (including some stuff that could be
done by Cisco IOS).  So if you want to try to do the insanely
complicated stuff, you have to use the "ip route" command.

Meh.  Could it have been shoehorned into the legacy "route" command?
Perhaps, although it would have been a bit of mess, I suspect.

The question I find more interesting is how many people are actually
*using* all of the complexity that currently can only be accessed via
the "ip", "tc", and "ss" commands.

But in any case, given that "ip", "tc", "ss", etc. are using the IOS
syntax, most users will probably find it confusing and surprising that
"iw" is using something different.  It's probably too hard to maintain
script compatibility to make such a UX change to iw at this point,
though.  And besides, most users are probably using "ifconfig",
"route", and if they're not using network-manager or wicdw, they're
using "iwconfig" or "iwlist" --- so it's a moot point.  :-)

						- Ted

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/31/14 22:57, Linus Torvalds wrote:
> On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o<tytso@mit.edu>  wrote:
>>
>> Yeah, the confusing part is that "ip" tends to use "verb object"
>> scheme, which is consistent with the Cisco IOS command set it was
>> trying to emulate.
>
> Side note: does anybody think that was really a good idea to begin
> with? I mean, Cisco iOS is just _soooo_ universally loved, right?

I think I sense a bit cynical (under)tone here ;-)

> And yeah, I refuse to use "ip link" or other insane commands. Let's
> face it, "ifconfig" and "route" are perfectly fine commands, and a
> whole lot less confusing than "ip" with random crap after it.  I'm
> really not seeing why that "ip" command was seen as an improvement.

So does "ip" provide the same functionality as "ifconfig" and "route" or 
does the package have more to offer.

The "iw" tool provides much more subcommands to perform different 
wireless tasks that are not provided by "iwconfig" and friends. So 
functionally "iw" provides a superset. Just have to get equivalent 
output format to mimic "iwconfig" as Ted suggested.

Well, that's something for next year as we are getting close to midnight 
over here.

Regards,
Arend

> (Ok, "ip route" isn't any more complex than "route", but "ip link"
> sure as hell isn't simpler than "ifconfig" for most things I can think
> of)
>
>                       Linus

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[David Lang]

On Wed, 31 Dec 2014, Arend van Spriel wrote:

> On 12/31/14 22:57, Linus Torvalds wrote:
>> On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o<tytso@mit.edu>  wrote:
>>> 
>>> Yeah, the confusing part is that "ip" tends to use "verb object"
>>> scheme, which is consistent with the Cisco IOS command set it was
>>> trying to emulate.
>> 
>> Side note: does anybody think that was really a good idea to begin
>> with? I mean, Cisco iOS is just _soooo_ universally loved, right?
>
> I think I sense a bit cynical (under)tone here ;-)
>
>> And yeah, I refuse to use "ip link" or other insane commands. Let's
>> face it, "ifconfig" and "route" are perfectly fine commands, and a
>> whole lot less confusing than "ip" with random crap after it.  I'm
>> really not seeing why that "ip" command was seen as an improvement.
>
> So does "ip" provide the same functionality as "ifconfig" and "route" or does 
> the package have more to offer.

there are things that you can do with "ip" that you can't do with "ifconfig", 
but they tend to be rather esoteric things (hundreds of IP addresses on "eth0" 
without using eth0:1, eth0:2, etc as one example)

The trouble is that doing simple things is harder with "ip" than "ifconfig"

David Lang

> The "iw" tool provides much more subcommands to perform different wireless 
> tasks that are not provided by "iwconfig" and friends. So functionally "iw" 
> provides a superset. Just have to get equivalent output format to mimic 
> "iwconfig" as Ted suggested.
>
> Well, that's something for next year as we are getting close to midnight over 
> here.
>
> Regards,
> Arend
>
>> (Ok, "ip route" isn't any more complex than "route", but "ip link"
>> sure as hell isn't simpler than "ifconfig" for most things I can think
>> of)
>>
>>                       Linus
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Richard Weinberger]

On Thu, Jan 1, 2015 at 1:22 AM, David Lang <david@lang.hm> wrote:
> there are things that you can do with "ip" that you can't do with
> "ifconfig", but they tend to be rather esoteric things (hundreds of IP
> addresses on "eth0" without using eth0:1, eth0:2, etc as one example)
>
> The trouble is that doing simple things is harder with "ip" than "ifconfig"

Jan did a nice overview:
http://inai.de/2008/02/19

-- 
Thanks,
//richard

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Lennart Sorensen]

On Wed, Dec 31, 2014 at 01:57:59PM -0800, Linus Torvalds wrote:
> Side note: does anybody think that was really a good idea to begin
> with? I mean, Cisco iOS is just _soooo_ universally loved, right?
> 
> And yeah, I refuse to use "ip link" or other insane commands. Let's
> face it, "ifconfig" and "route" are perfectly fine commands, and a
> whole lot less confusing than "ip" with random crap after it.  I'm
> really not seeing why that "ip" command was seen as an improvement.
> 
> (Ok, "ip route" isn't any more complex than "route", but "ip link"
> sure as hell isn't simpler than "ifconfig" for most things I can think
> of)

Well at least in the past (not sure these days), ifconfig was reading
rather inefficiently from /proc rather than using netlink, and it had
annoying bugs like only showing the first 9 characters of the interface
name, not handling IPv6 (I think that has been fixed by now), and many
other awfulnesses.

I just did a quick check to see how ifconfig does longer interface names
and got this:
tun0-12345678:2: error fetching interface information: Device not found

for an interface I had renamed to tun0-123456789

ip had no issue with it.

Renaming it to tun0-12345678 made ifconfig not die on it.  I wonder if
someone failed to understand that 15 character interface names meant
that 15 characters before the NULL should be allowed.  If did show all
of the 14 characters though, so the old cut at 9 character limit is at
least gone these days.

ifconfig seems to just be broken for many cases of perfectly nice features
in the kernel.

So yes some parts of ip are pretty painful, while others are rather nice
(I certainly like ip route, where the output actually matches the syntax
of the input, unlike the route command).

Would be nice if all features of the ip command were actually documented,
but they clearly are not.

-- 
Len Sorensen

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Linus Torvalds]

On Thu, Jan 1, 2015 at 11:44 AM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
>
> ifconfig seems to just be broken for many cases of perfectly nice features
> in the kernel.

So I'm not saying "ifconfig is wonderful". It's not.

But I *am* saying that "changing user interfaces and then expecting
people to change is f*cking stupid".

The fact is, ifconfig is simple for the simple cases, but more
importantly, a lot of people learnt how to use it. Saying "you should
all change, because we made up a new syntax" is not good policy.

The people who did "ip" could have fairly easily have done a wrapper
around the same code that also left the old "ifconfig" syntax. Then,
distros could have trivially just dropped the old "ifconfig" package,
and entirely replaced it with the new "ip" package.

As it is, we have two different models, and they'll basically stay
around forever.

For something like ifconfig, very few people care. But *all* the same
arguments are true wrt "iw" and "iwconfig".

The people who are trying to deprecate the WEXT interfaces should put
the blame firmly where it belongs - on the people who thought that
"we'll just ignore all old history".

Because people who think that "we'll just redesign everything" are
actually f*cking morons. Really.

There's a real reason the kernel has the "no regression" policy. And
that reason is that I'm not a moron.

History matter. Legacy uses matter.

                          Linus

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Lennart Sorensen]

On Thu, Jan 01, 2015 at 12:14:15PM -0800, Linus Torvalds wrote:
> So I'm not saying "ifconfig is wonderful". It's not.
> 
> But I *am* saying that "changing user interfaces and then expecting
> people to change is f*cking stupid".
> 
> The fact is, ifconfig is simple for the simple cases, but more
> importantly, a lot of people learnt how to use it. Saying "you should
> all change, because we made up a new syntax" is not good policy.

Perhaps it would be good to at least fix the buggy bits of ifconfig and
perhaps make it work with netlink instead of parsing /proc.  Maybe not
add features, but at least fix the broken bits and make it use modern
interfaces.  The interface to the user can stay.  And of course if it
happens to encounter a really old kernel, it should still remember how
to speak to it with the old interface.

> The people who did "ip" could have fairly easily have done a wrapper
> around the same code that also left the old "ifconfig" syntax. Then,
> distros could have trivially just dropped the old "ifconfig" package,
> and entirely replaced it with the new "ip" package.

Hmm, that might be a better idea.

> As it is, we have two different models, and they'll basically stay
> around forever.
> 
> For something like ifconfig, very few people care. But *all* the same
> arguments are true wrt "iw" and "iwconfig".
> 
> The people who are trying to deprecate the WEXT interfaces should put
> the blame firmly where it belongs - on the people who thought that
> "we'll just ignore all old history".
> 
> Because people who think that "we'll just redesign everything" are
> actually f*cking morons. Really.
> 
> There's a real reason the kernel has the "no regression" policy. And
> that reason is that I'm not a moron.
> 
> History matter. Legacy uses matter.

Sounds good to me.

-- 
Len Sorensen

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Michal Kubecek]

On Thu, Jan 01, 2015 at 02:44:17PM -0500, Lennart Sorensen wrote:

> not handling IPv6 (I think that has been fixed by now), and many
> other awfulnesses.

Some basic setting can be done. But it illustrates nicely what is wrong
with the idea of extending ifconfig to support new features. IPv6
addresses are added and removed (which is how it really works) while
with IPv4, ifconfig keeps pretending interface has exactly one address
and to set more, a virtual interface must be created. In reality, both
IPv4 and IPv6 addresses are handled in pretty much the same way.

This "virtual interface" does not actually exist so that its parameters
can't be set; and worse, if you try, ifconfig silently sets them for the
actual interface (try e.g. "ifconfig eth0:0 mtu 1400"). You also can't
use its name with other commands. Just google for users asking why
iptables or tcpdump does not recognize their 'eth0:0'... and then people
come and say that ip (unlike ifconfig) is confusing.

But, yes, as the old ioctl interface can't be removed, lot of people
will claim that ifconfig "just works" and that it must be preserved. And
they will teach new generations of linux users to use it. So I'm afraid
this exact discussion will be still repeated even after next 15 years.

> Would be nice if all features of the ip command were actually documented,
> but they clearly are not.

As far as I can say, there may still be some missing parts but in recent
versions, both manual pages and "ip ... help" cover the functions quite
well (even if they are a bit too terse sometimes). On the other hand,
"route --help" doesn't even tell me how to add a simple route.

                                                        Michal Kubecek

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/31/14 22:44, Theodore Ts'o wrote:
> On Wed, Dec 31, 2014 at 09:32:13PM +0100, Arend van Spriel wrote:
>>
>> Agree. I can't even recall using "ip" ever. iw help system does provide
>> command specific help. The phy keyword is both a command and a selector key,
>> which I realize is confusing to the user, eg. 'iw help info' does provide
>> help for the 'info' subcommand.
>
> Yeah, the confusing part is that "ip" tends to use "verb object"
> scheme, which is consistent with the Cisco IOS command set it was
> trying to emulate.   So for ip, you do something like
>
> ip link info eth0
>
> Where as for "iw" it's almost exactly backwards, i.e.:
>
> iw wlan0 info
>
> It's actually rather unfortunate that there is no consistency between
> many of these tools, for example:
>
> ethtool --show-features eth0
>
> If we were going to create a new interface, wouldn't be nice if we
> could have some kind of consistency?  Sigh; oh well, water under the
> bridge at this point.

And on that water there are different ships with different captains ;-)

>> Thanks. If there are still drivers, upstream or out-of-tree, providing only
>> WEXT API this will not work unless iwconfig/iwlist can distinguish those
>> from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl
>> syscalls. Just not sure if it is worth the effort. As you stated below, it
>> does not seem "evil" to retain WEXT if that is providing users what they
>> need.
>
> Is it really that much effort?  Unless there is some license
> incompatibility nonsense (i.e., GPLv2 vs GPLv3), the code's already
> there in the wireless-tools source.  It would just be a matter of
> trying the new ioctls first, and then falling back to the WEXT ones if
> needed, right?

I don't think it is much effort. I think the nl80211 netlink api is not 
an ioctl, but yeah it seems trivial. But if WEXT needs to stay for 
people using WEXT-only drivers, it may be fine to keep cfg80211 wext 
compatibility in place.

Regards,
Arend

> Cheers,
>
> 					- Ted

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Andreas Hartmann]

Jiri Kosina wrote:
> On Wed, 31 Dec 2014, Arend van Spriel wrote:
> 
>> The thing with WEXT is that it will stay as is. So if tools like wicd 
>> want to support new features like P2P it will need to make the switch. I 
>> checked out wicd repo and found a number of iwconfig calls and they kick 
>> off wpa_supplicant with wext driver.
> 
> Unfortunately this is by no means just about wicd. I have already received 
> a few off-list mails from people who were wondering why their home-made 
> scripts / tools, which are running 'iwconfig' directly suddenly stopped to 
> work, and that it was indeed fallout of WEXT going away. Given the very 
> short time this has been in mainline, you can probably imagine the 
> fireworks once this appears in major release.

It is not just the userspace tools (I prefer them, too), which need
wext, but a lot of drivers, too, such as Mediathek drivers e.g. which
perform *much* better compared to rt2x00, especially concerning USB
chips like the one used by Linksys AE3000 (3x3 Mimo)
(https://wikidevi.com/wiki/Linksys_AE3000), which achieves average
throughputs around 14 MB/s *average* with scp of big (> 10 GB) crypted
files even through reinforced-concrete floor(!) - rt2x00 is *far* away
of providing such a performance.

Next bad point of rt2x00 e.g. is the huge CPU overhead - compare
rt5572sta on Raspi with rt2x00 running netperf and you will see the huge
problem of rt2x00 (which is covered on x86 by mostly oversized multi
core CPUs).

Another big advantage of rt5572sta is: it is *stable* over a lot of
kernel versions (as long as the kernel didn't break interfaces - but
there are patches to catch them).

Even ath9k, which usually is a really fine driver, is broken on some
kernel versions (link and throughput is not stable - my use case depends
*heavily* on very high and longterm stable throughput). That's why I'm
using a VM for my ath9k-device to be independent of these quality
problems of mac80211 (or maybe ath9k - don't know) over different kernel
versions.


All in all:
If you want to get rid of wext, you still have to go a *very* long way
to get the same *stable* and high throughput quality with *all* chips
depending on mac80211 and not just a few flagship drivers like Atheros.



Kind regards,
Andreas Hartmann

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 12/31/14 16:14, Andreas Hartmann wrote:
> Jiri Kosina wrote:
>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>
>>> The thing with WEXT is that it will stay as is. So if tools like wicd
>>> want to support new features like P2P it will need to make the switch. I
>>> checked out wicd repo and found a number of iwconfig calls and they kick
>>> off wpa_supplicant with wext driver.
>>
>> Unfortunately this is by no means just about wicd. I have already received
>> a few off-list mails from people who were wondering why their home-made
>> scripts / tools, which are running 'iwconfig' directly suddenly stopped to
>> work, and that it was indeed fallout of WEXT going away. Given the very
>> short time this has been in mainline, you can probably imagine the
>> fireworks once this appears in major release.
>
> It is not just the userspace tools (I prefer them, too), which need
> wext, but a lot of drivers, too, such as Mediathek drivers e.g. which
> perform *much* better compared to rt2x00, especially concerning USB
> chips like the one used by Linksys AE3000 (3x3 Mimo)
> (https://wikidevi.com/wiki/Linksys_AE3000), which achieves average
> throughputs around 14 MB/s *average* with scp of big (>  10 GB) crypted
> files even through reinforced-concrete floor(!) - rt2x00 is *far* away
> of providing such a performance.
>
> Next bad point of rt2x00 e.g. is the huge CPU overhead - compare
> rt5572sta on Raspi with rt2x00 running netperf and you will see the huge
> problem of rt2x00 (which is covered on x86 by mostly oversized multi
> core CPUs).
>
> Another big advantage of rt5572sta is: it is *stable* over a lot of
> kernel versions (as long as the kernel didn't break interfaces - but
> there are patches to catch them).
>
> Even ath9k, which usually is a really fine driver, is broken on some
> kernel versions (link and throughput is not stable - my use case depends
> *heavily* on very high and longterm stable throughput). That's why I'm
> using a VM for my ath9k-device to be independent of these quality
> problems of mac80211 (or maybe ath9k - don't know) over different kernel
> versions.
>
>
> All in all:
> If you want to get rid of wext, you still have to go a *very* long way
> to get the same *stable* and high throughput quality with *all* chips
> depending on mac80211 and not just a few flagship drivers like Atheros.

Hi Andreas,

That's a nice list of unrelated stuff. This has all nothing to do with 
WEXT. Actually, you can build rt5572sta with cfg80211 support 
(RT_CFG80211_SUPPORT). This thread is about the configuration API and 
not about driver performance.

Regards,
Arend

> Kind regards,
> Andreas Hartmann
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Andreas Hartmann]

Arend van Spriel wrote:
> On 12/31/14 16:14, Andreas Hartmann wrote:
[...]
>> All in all:
>> If you want to get rid of wext, you still have to go a *very* long way
>> to get the same *stable* and high throughput quality with *all* chips
>> depending on mac80211 and not just a few flagship drivers like Atheros.
> 
> Hi Andreas,
> 
> That's a nice list of unrelated stuff. This has all nothing to do with
> WEXT. Actually, you can build rt5572sta with cfg80211 support
> (RT_CFG80211_SUPPORT).

You seem to know sources I don't know off. Could you please tell me,
where to find them?

I have DPO_RT5572_LinuxSTA_2.6.0.1_20120629 which doesn't compile with
HAS_CFG80211_SUPPORT=y because -DCONFIG_AP_SUPPORT, on which
RT_CFG80211_SUPPORT relies, is broken.

DPO_RT5572_LinuxSTA_2.6.1.3_20121022 removed the necessary broken AP
code completely.

> This thread is about the configuration API and
> not about driver performance.

I know.

I tried to show, why WEXT as a whole is still necessary even if there is
a mac80211 based driver, because of the weakness of rt2800usb:
Nip it in the bud.



Kind regards,
Andreas

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Arend van Spriel]

On 01/01/15 11:56, Andreas Hartmann wrote:
> Arend van Spriel wrote:
>> On 12/31/14 16:14, Andreas Hartmann wrote:
> [...]
>>> All in all:
>>> If you want to get rid of wext, you still have to go a *very* long way
>>> to get the same *stable* and high throughput quality with *all* chips
>>> depending on mac80211 and not just a few flagship drivers like Atheros.
>>
>> Hi Andreas,
>>
>> That's a nice list of unrelated stuff. This has all nothing to do with
>> WEXT. Actually, you can build rt5572sta with cfg80211 support
>> (RT_CFG80211_SUPPORT).
>
> You seem to know sources I don't know off. Could you please tell me,
> where to find them?
>
> I have DPO_RT5572_LinuxSTA_2.6.0.1_20120629 which doesn't compile with
> HAS_CFG80211_SUPPORT=y because -DCONFIG_AP_SUPPORT, on which
> RT_CFG80211_SUPPORT relies, is broken.
>
> DPO_RT5572_LinuxSTA_2.6.1.3_20121022 removed the necessary broken AP
> code completely.

Nice.

>> This thread is about the configuration API and
>> not about driver performance.
>
> I know.
>
> I tried to show, why WEXT as a whole is still necessary even if there is
> a mac80211 based driver, because of the weakness of rt2800usb:
> Nip it in the bud.

Yes. WEXT needs to stay for a while. Not arguing that. Just saying this 
is really about cfg80211 providing "WEXT compatibility" so WEXT 
user-space apps can interact with cfg80211-based drivers and how to come 
up with a plan to phase out "WEXT compatibility", not WEXT.

Regards,
Arend

> Kind regards,
> Andreas

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Jiri Kosina]

On Wed, 31 Dec 2014, Arend van Spriel wrote:

> You mentioned in the discussion and I quote: "*If* wireless maintainers 
> think otherwise, I'll send a revert request to Linus for 
> consideration.". However, you did not wait for any response from the 
> wireless maintainers nor from the author of the patch you are reverting. 
> Seems like an overreaction to me though personally I do not disgree with 
> the revert itself.

My understanding from the whole thread was that Emmanuel disagrees with 
the revert, and I consider Emmanuel to definitely belong to the "wireless 
maintainers" group. If my understanding was wrong on this, sorry for that.

One way or another, the revert really is a-must-have, as it causes visible 
userspace regressions. I am really surprised that it's causing so lively 
discussion and doubts.

-- 
Jiri Kosina
SUSE Labs

RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Grumbach, Emmanuel]

> 
> On Wed, 31 Dec 2014, Arend van Spriel wrote:
> 
> > You mentioned in the discussion and I quote: "*If* wireless
> > maintainers think otherwise, I'll send a revert request to Linus for
> > consideration.". However, you did not wait for any response from the
> > wireless maintainers nor from the author of the patch you are reverting.
> > Seems like an overreaction to me though personally I do not disgree
> > with the revert itself.
> 
> My understanding from the whole thread was that Emmanuel disagrees with
> the revert, and I consider Emmanuel to definitely belong to the "wireless
> maintainers" group. If my understanding was wrong on this, sorry for that.

You understanding is wrong. This patch has an author and you could I didn't
sign-off the patch which is an obvious indication I am not a "wireless maintainer".
You didn't even make the minimal effort to check how this patch should be properly
routed.

Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
the userland developers that an API will be deprecated at some point. I haven't seen
any response / suggestion from you on that.

> 
> One way or another, the revert really is a-must-have, as it causes visible
> userspace regressions. I am really surprised that it's causing so lively
> discussion and doubts.
> 
> --
> Jiri Kosina
> SUSE Labs

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Peter Hurley]

On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
>>
>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>
>>> You mentioned in the discussion and I quote: "*If* wireless
>>> maintainers think otherwise, I'll send a revert request to Linus for
>>> consideration.". However, you did not wait for any response from the
>>> wireless maintainers nor from the author of the patch you are reverting.
>>> Seems like an overreaction to me though personally I do not disgree
>>> with the revert itself.
>>
>> My understanding from the whole thread was that Emmanuel disagrees with
>> the revert, and I consider Emmanuel to definitely belong to the "wireless
>> maintainers" group. If my understanding was wrong on this, sorry for that.
> 
> You understanding is wrong. This patch has an author and you could I didn't
> sign-off the patch which is an obvious indication I am not a "wireless maintainer".
> You didn't even make the minimal effort to check how this patch should be properly
> routed.
> 
> Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
> the userland developers that an API will be deprecated at some point. I haven't seen
> any response / suggestion from you on that.

pr_notice_once("WEXT compatibility has been deprecated since _____" \
               " Upgrade your userspace tools to nl80211!\n");

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Julian Calaby]

Hi,

On Thu, Jan 1, 2015 at 12:49 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
>>>
>>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>>
>>>> You mentioned in the discussion and I quote: "*If* wireless
>>>> maintainers think otherwise, I'll send a revert request to Linus for
>>>> consideration.". However, you did not wait for any response from the
>>>> wireless maintainers nor from the author of the patch you are reverting.
>>>> Seems like an overreaction to me though personally I do not disgree
>>>> with the revert itself.
>>>
>>> My understanding from the whole thread was that Emmanuel disagrees with
>>> the revert, and I consider Emmanuel to definitely belong to the "wireless
>>> maintainers" group. If my understanding was wrong on this, sorry for that.
>>
>> You understanding is wrong. This patch has an author and you could I didn't
>> sign-off the patch which is an obvious indication I am not a "wireless maintainer".
>> You didn't even make the minimal effort to check how this patch should be properly
>> routed.
>>
>> Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
>> the userland developers that an API will be deprecated at some point. I haven't seen
>> any response / suggestion from you on that.
>
> pr_notice_once("WEXT compatibility has been deprecated since _____" \
>                " Upgrade your userspace tools to nl80211!\n");

Sadly, nobody will read that. It needs to be at least an error,
possibly with a big splat to scare people.

Maybe using one of WARN()'s siblings instead.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Borislav Petkov]

On Thu, Jan 01, 2015 at 01:40:53AM +1100, Julian Calaby wrote:
> Sadly, nobody will read that. It needs to be at least an error,
> possibly with a big splat to scare people.
> 
> Maybe using one of WARN()'s siblings instead.

And that opens a lot of useless bugzillas...

The right thing to do is go talk to the maintainers of the userspace
tools or send patches.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Julian Calaby]

Hi Borislav,

On Thu, Jan 1, 2015 at 1:46 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Thu, Jan 01, 2015 at 01:40:53AM +1100, Julian Calaby wrote:
>> Sadly, nobody will read that. It needs to be at least an error,
>> possibly with a big splat to scare people.
>>
>> Maybe using one of WARN()'s siblings instead.
>
> And that opens a lot of useless bugzillas...
>
> The right thing to do is go talk to the maintainers of the userspace
> tools or send patches.

The point is that WEXT has been depreciated for _years_. Nobody seems
to have listened. Yes, talking to maintainers will get the last
holdouts of the "big" tools (e.g. wicd) to fix them, but it's not
going to change all the people out there with hacked together
home-grown setups.

Yes, a full WARN() will end up with loads of duplicated bugzillas -
and I wish I had the time to volunteer to close every last one with
"upgrade your userspace to use nl80211 / iw" - but I feel that
speaking quietly hasn't worked: maybe now we need to yell.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Jiri Kosina]

On Thu, 1 Jan 2015, Julian Calaby wrote:

> The point is that WEXT has been depreciated for _years_. Nobody seems
> to have listened. Yes, talking to maintainers will get the last
> holdouts of the "big" tools (e.g. wicd) to fix them, but it's not
> going to change all the people out there with hacked together
> home-grown setups.

Exactly. So why not work with whoever maintains iwconfig and friends, so 
that they are turned into functionally equivalent wrappers around iw? Only 
then it seems to make sense to start any kind of depreciation.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Borislav Petkov]

On Thu, Jan 01, 2015 at 01:56:54AM +1100, Julian Calaby wrote:
> The point is that WEXT has been depreciated for _years_. Nobody
> seems to have listened. Yes, talking to maintainers will get the
> last holdouts of the "big" tools (e.g. wicd) to fix them, but it's
> not going to change all the people out there with hacked together
> home-grown setups.

That's fine - you can fix the major tools first and then take a look at
the home-grown fun later.

> Yes, a full WARN() will end up with loads of duplicated bugzillas -
> and I wish I had the time to volunteer to close every last one with
> "upgrade your userspace to use nl80211 / iw" - but I feel that
> speaking quietly hasn't worked: maybe now we need to yell.

This goes to show once again how hard it is to design a userspace
interface properly and how hard it is to change it once it gets exposed.

But yeah, screaming or not screaming, you will have to support it anyway
as long as there are tools using it. This is why I think the proper and
maybe faster way to address the situation is to go fix userspace tools
instead of issuing warnings. People never look at those as long as it
works, in my experience.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Pavel Machek]

On Wed 2014-12-31 08:49:00, Peter Hurley wrote:
> On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
> >>
> >> On Wed, 31 Dec 2014, Arend van Spriel wrote:
> >>
> >>> You mentioned in the discussion and I quote: "*If* wireless
> >>> maintainers think otherwise, I'll send a revert request to Linus for
> >>> consideration.". However, you did not wait for any response from the
> >>> wireless maintainers nor from the author of the patch you are reverting.
> >>> Seems like an overreaction to me though personally I do not disgree
> >>> with the revert itself.
> >>
> >> My understanding from the whole thread was that Emmanuel disagrees with
> >> the revert, and I consider Emmanuel to definitely belong to the "wireless
> >> maintainers" group. If my understanding was wrong on this, sorry for that.
> > 
> > You understanding is wrong. This patch has an author and you could I didn't
> > sign-off the patch which is an obvious indication I am not a "wireless maintainer".
> > You didn't even make the minimal effort to check how this patch should be properly
> > routed.
> > 
> > Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
> > the userland developers that an API will be deprecated at some point. I haven't seen
> > any response / suggestion from you on that.
> 
> pr_notice_once("WEXT compatibility has been deprecated since _____" \
>                " Upgrade your userspace tools to nl80211!\n");

Kernel interfaces are not being removed, not now, not ever. No need to
spam logs.

(And to the person who suggested WARN(): No.)

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

[Paul Bolle]

On Tue, 2014-12-30 at 23:52 +0100, Jiri Kosina wrote:
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
> 
> It's causing severe userspace breakage. Namely, all the utilities
> from wireless-utils which are relying on CONFIG_WEXT (which means
> tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
> is a 'iw' utility in newer wireless-tools, which is supposed to be
> a replacement for all the "deprecated" binaries, but it's far away
> from being massively adopted.
> 
> Please see [1] for example of the userspace breakage this is causing.
> 
> In addition to that, Larry Finger reports [2] that this patch is also
> causing ipw2200 driver being impossible to build.
> 
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.
> 
> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688

So [2] already entered mainline as commit dddd60220f41 ("ipw2200: select
CFG80211_WEXT"). As this revert has now been applied, I think my patch
should now be reverted too. But I don't think it's a good idea to submit
a patch, however trivial, in the last hours before new year. So I'll
have a look into this in the first days of next year.

> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>  net/wireless/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
>  	  Most distributions have a CRDA package.  So if unsure, say N.
>  
>  config CFG80211_WEXT
> -	bool
> +	bool "cfg80211 wireless extensions compatibility"
>  	depends on CFG80211
>  	select WEXT_CORE
>  	help


Paul Bolle

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

[Grumbach, Emmanuel]

> 
> On Tue, 30 Dec 2014, Larry Finger wrote:
> 
> > > > If wireless maintainers think otherwise, I'll send a revert
> > > > request to Linus for consideration.
> > >
> > > I wonder if the reaction would be like this one:
> > >
> > > https://lkml.org/lkml/2012/12/23/75
> > >
> > > :-)
> >
> > It would be a little like that.
> >
> > One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
> > 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made
> > it impossible to select the IPW2200. The patch to allow selecting the
> > IPW2200, which automatically selects CFG80211_WEXT has been added to
> > wireless-drivers, but it has not yet made it to mainline. Once it
> > does, then choosing to build the IPW2200 will provide a workaround.
> >
> > In my opinion, the need for the IPW2200 to have CFG80211_WEXT means
> > that the original commit will likely be reverted, but your voice will help.
> 
> Ok, thanks a lot for another datapoint. I am sending revert patch to Linus
> tonight.
> 
I don't see this as another datapoint. All it means is that there are ancient drivers
that won't work at all with newer tools and that are taken into consideration while
trying to deprecate an API.
Now - basically all your argument is on Johannes's comment: "deprecated enough".
I think we have a chicken and egg problem here. We can't break things towards userland.
Good. But we do want to deprecate this API because lots of valid purely technical reasons.
Unfortunately, I don't see what we could do to send a strong signal to userspace tools developers
to have them work / plan a move to a modern API.

RE: iwlwifi-driver card doesn't work with 3.19-rc2+

[Sujith Manoharan]

Grumbach, Emmanuel wrote:
> I don't see this as another datapoint. All it means is that there are ancient
> drivers that won't work at all with newer tools and that are taken into
> consideration while trying to deprecate an API.

Not just drivers, tools and applications too.

I don't think we can ever lose the WEXT baggage since there will probably be
tools that will never migrate to nl80211. But, we can direct to /dev/null all
kernel bugs that are related to WEXT. :-)

Sujith

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Borislav Petkov]

On Wed, Dec 31, 2014 at 07:50:19AM +0000, Grumbach, Emmanuel wrote:
> Now - basically all your argument is on Johannes's comment:
> "deprecated enough". I think we have a chicken and egg problem here.
> We can't break things towards userland. Good. But we do want to
> deprecate this API because lots of valid purely technical reasons.
> Unfortunately, I don't see what we could do to send a strong signal to
> userspace tools developers to have them work / plan a move to a modern
> API.

I don't see what all the fuss is all about. If you're still unsure, go
read Linus' message once more. You're absolutely not allowed to break
userspace. Fullstop. No ifs and buts and whatever.

Everything extra you wanna do is probably fine. You can go talk to
userspace tools maintainers using the deprecated API, you can go and fix
it yourself, and so on and so on...

And giving Jiri hard time for "bypassing" maintainers for something
which is clearly a no-no and has to be reverted the moment it hits
mainline shows yet again you haven't really understood the rule yet:

There is no breaking of userspace. Fullstop.

Things like that get reverted ASAP. No "it needs to go through my tree",
"I'm not sure, blabalba" ...

So instead of giving him hard time, say "thank you for sending the
revert and thank you for helping us maintainers". Now, before you say
something, remember this: there is no breaking of userspace!

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: iwlwifi-driver card doesn't work with 3.19-rc2+

[Jiri Kosina]

On Tue, 30 Dec 2014, Emmanuel Grumbach wrote:

> > I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and
> > wifi doesn't work. iwconfig is telling me that wlan0 interface has no
> > wireless extensions.
> 
> So why do you used them?
> They have been deprecated for a couple of years now. You should be
> using nl80211 based tools such as iw.

My userspace wireless setup tool (wicd) is using wireless extensions, and 
even the most recent version uses solely that.

I am pretty sure that's not the only tool in the world.

> > Previous kernel that is known to work on this machine is 3.18-rc5. I 
> > can do a bisect if needed, but wanted to ask in case this is a known 
> > problem.
> 
> 3.19 is the first kernel that actually removed the wireless extensions.

That's userspace breakage I am pretty sure a LOT of people will be 
hitting. I don't think this fits into the way we are maintaining userspace 
compatibility at all.

-- 
Jiri Kosina
SUSE Labs