Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[poma]

On 30.03.2017 16:06, Jes Sorensen wrote:
> On 03/30/2017 03:15 AM, Greg Kroah-Hartman wrote:
>> On Wed, Mar 29, 2017 at 08:20:19PM -0500, Larry Finger wrote:
>>> On 03/29/2017 12:47 PM, Hans de Goede wrote:
 The rtl8723bs is found on quite a few systems used by Linux users,
 such as on Atom systems (Intel Computestick and various other
 Atom based devices) and on many (budget) ARM boards such as
 the CHIP.

 The plan moving forward with this is for the new clean,
 written from scratch, rtl8xxxu driver to eventually gain
 support for sdio devices. But there is no clear timeline
 for that, so lets add this driver included in staging for now.

 Cc: Bastien Nocera 
 Cc: Larry Finger 
 Cc: Jes Sorensen 
 Signed-off-by: Hans de Goede 
>>>
>>> Hans,
>>>
>>> I am still building the driver on my CherryTrail tablet, but I did see some
>>> warnings and errors listed by Smatch as follows:
>>>
> [snip]
>>> The indent problems can probably be ignored, but many of the others are
>>> serious enough to be addressed now.
>>>
>>> Once this driver is merged into staging, the Outreachy folks will be really 
>>> busy.
>>>
>>> Thanks for posting this driver,
>>
>> So, no objection from you?  Great, I'll go queue it up later today...
>>
>> thanks,
>>
>> greg k-h
>>
> 
> As much as I hate adding more Realtek vendor code to the kernel, I do 
> agree this is the right thing to do in the interim. Not sure when I'll 
> get to SDIO support in rtl8xxxu, but I will process patches, hint hint :)
> 
> Jes
> 

A day after tomorrow? :)

Re: compile driver for rtl8192su

[poma]

On 29.03.2017 14:51, walter strametz wrote:
> Hi - I try to get my D-Link N300 running and compiled the sources on
> github (chunkeey - rtl8192su).  Other trials also failed, because the
> driver-source is not compatible with the (newer) kernel.
> 
> See more information in the enclosed textfile .
> 
> Can you help me?
> 
> Thx, Walter
> 

>From the aforementioned attachment - compileerror.txt
[...]
walter@thinkpad ~/rtl8192su $ lsusb
Bus 002 Device 004: ID 2001:3319 D-Link Corp. 
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[...]

= Bus 002 Device 004: ID 2001:3319 D-Link Corp. =


Support - DWA-131 - Revision E
http://www.dlink.com/uk/en/support/product/dwa-131-wireless-n-nano-usb-adapter?revision=deu_reve#downloads
Drivers
ftp://ftp.dlink.eu/Products/dwa/dwa-131/driver_software/DWA-131_drv_revE_5-03_eu_multi_20161215.zip

$ unzip DWA-131_drv_revE_5-03_eu_multi_20161215.zip
$ unzip 20161124_DWA-131E_V5.04b03.zip

$ dos2unix < 
20161124_DWA-131E_V5.04b03/Drivers/WinXPx86_Win2K/Dnetrtwlanu_XP.inf | grep 
2001.*3319
%DLink_131E.DeviceDesc% = RTL8192eu.ndi,
USB\VID_2001_3319



D-Link DWA-131 (N300, USB, WiFi Adapter)
http://www.linux-hardware-guide.com/2013-11-16-d-link-dwa-131-n300-usb-wifi-adapter
...
Version E1: 2001:3319
A new version of the DWA-131 was identified with USB ID 2001:3319
Bus 001 Device 003: ID 2001:3319 D-Link Corp
and seems to be based on the Realtek RTL8192eu chipset.
...

http://support.dlink.com.au/download/download.aspx?product=DWA-131
Drivers
ftp://files.dlink.com.au/products/DWA-131/REV_E/Drivers/DWA-131_Linux_driver_v4.3.1.1.zip

$ unzip DWA-131_Linux_driver_v4.3.1.1.zip
$ tar xf 20140812_rtl8192EU_linux_v4.3.1.1_11320.tar.gz

$ grep 2001.*3319 
20140812_rtl8192EU_linux_v4.3.1.1_11320/os_dep/linux/usb_intf.c
{USB_DEVICE(0x2001, 0x3319),.driver_info = RTL8192E}, /* D-Link - 
DWA-131 */

...

Drivers for the rtl8192eu chipset for wireless adapters (D-Link DWA-131 rev E1 
included!)
https://github.com/Mange/rtl8192eu-linux-driver

$ git clone https://github.com/Mange/rtl8192eu-linux-driver.git
$ cd rtl8192eu-linux-driver/
$ make
$ modinfo 8192eu.ko | grep 2001.3319
alias:  usb:v2001p3319d*dc*dsc*dp*ic*isc*ip*in*

Re: [PATCH 4.11] genetlink: fix counting regression on ctrl_dumpfamily()

[poma]

On 22.03.2017 16:08, Stanislaw Gruszka wrote:
> Commit 2ae0f17df1cd ("genetlink: use idr to track families") replaced
> 
>   if (++n < fams_to_skip)
>   continue;
> into:
> 
>   if (n++ < fams_to_skip)
>   continue;
> 
> This subtle change cause that on retry ctrl_dumpfamily() call we omit
> one family that failed to do ctrl_fill_info() on previous call, because
> cb->args[0] = n number counts also family that failed to do
> ctrl_fill_info().
> 
> Patch fixes the problem and avoid confusion in the future just decrease
> n counter when ctrl_fill_info() fail.
> 
> User visible problem caused by this bug is failure to get access to
> some genetlink family i.e. nl80211. However problem is reproducible
> only if number of registered genetlink families is big enough to
> cause second call of ctrl_dumpfamily().
> 
> Cc: Xose Vazquez Perez <xose.vazq...@gmail.com>
> Cc: Larry Finger <larry.fin...@lwfinger.net>
> Cc: Johannes Berg <johan...@sipsolutions.net>
> Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
> Signed-off-by: Stanislaw Gruszka <sgrus...@redhat.com>
> ---
> Dave, please also target this for 4.10+ -stable.
> 
>  net/netlink/genetlink.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index fb6e10f..92e0981 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -783,8 +783,10 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct 
> netlink_callback *cb)
>  
>   if (ctrl_fill_info(rt, NETLINK_CB(cb->skb).portid,
>  cb->nlh->nlmsg_seq, NLM_F_MULTI,
> -skb, CTRL_CMD_NEWFAMILY) < 0)
> +    skb, CTRL_CMD_NEWFAMILY) < 0) {
> + n--;
>   break;
> + }
>   }
>  
>   cb->args[0] = n;
> 


Thanks Stanislaw, Larry!

Tested-by: poma <p...@gmail.com>

Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1422247

R92SU - Realtek RTL8192SU/RTL8191SU/RTL8188SU USB Wireless Network Adapters

[poma]

Hello fellows!

https://github.com/chunkeey/rtl8192su/tree/master/r92su
r92su seems like the simplest and most effective replacement for r8712u.

https://bugzilla.redhat.com/show_bug.cgi?id=1421383
Christian, I can not add you there, so I'm asking here,
is there any particular reason why r92su is not already accepted in mainline?

Is there an intention to "Realtek RTL8192SU/RTL8191SU/RTL8188SU USB Wireless 
Network Adapters" join "RTL8XXXu USB mac80211 Wireless LAN Driver" support?

Thanks
 

Re: How to activate MAC address randomization?

[poma]

On 24.05.2016 16:46, poma wrote:
> On 24.05.2016 13:22, poma wrote:
>>
>> [...] NetworkManager [...]
>>
>> WPA Supplicant comparative test
>> - wpa_supplicant v2.6-devel git a26c9c2 2016-05-20
>> - Linux 4.6
>> - QEMU emulator version 2.6.0 (Hotspot)
>>
>>
>> Pre-association / Scanning random MAC address
>>
>>  = Client (mt7601u) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> preassoc_mac_addr=1
>> network={
>> ssid="WiFiRd"
>> bssid=ee:dd:cc:bb:aa:00
>> key_mgmt=WPA-PSK
>> psk="**"
>> }
>>
>>
>> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f 
>> wpasuplog.txt
>>
>>
>> # grep -i 'mac\|rand\|connected' wpasuplog.txt
>> random: Trying to read entropy from /dev/random
>> preassoc_mac_addr=1
>> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
>> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
>> EAPOL: SUPP_PAE entering state DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
>> random: Got 20/20 bytes from /dev/random
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> nl80211: set_mac_addr for wlp0s2f1u3 to 4a:b1:d6:28:4c:90
>> wlp0s2f1u3: Using random MAC address 4a:b1:d6:28:4c:90
>> nl80211: set_mac_addr for wlp0s2f1u3 to 00:aa:bb:cc:dd:ee
>> wlp0s2f1u3: Using permanent MAC address
>> wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed 
>> [id=0 id_str=]
>> ...
>>
>>
>>
>>  = Hotspot (rt2800usb) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> network={
>> ssid="WiFiRd"
>> key_mgmt=WPA-PSK
>> psk="**"
>> mode=2
>> }
>>
>>
>> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f 
>> wpasuplog.txt
>>
>>
>> # grep -i '4a:b1:d6:28:4c:90\|00:aa:bb:cc:dd:ee' wpasuplog.txt
>> nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=4a:b1:d6:28:4c:90 
>> bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-19 fc=0x40 seq_ctrl=0x3b20 
>> stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
>> nl80211: send_mlme - da= 4a:b1:d6:28:4c:90 noack=1 freq=0 no_cck=0 
>> offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
>> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=00:aa:bb:cc:dd:ee 
>> bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-19 fc=0x8b0 seq_ctrl=0x3b60 
>> stype=11 (WLAN_FC_STYPE_AUTH) len=30
>> ...
>> wlp2s2f7u2: AP-STA-CONNECTED 00:aa:bb:cc:dd:ee
>> ...
>>
>>
>> ~~~
>>
>>
>> Association / Connection random MAC address
>>
>>
>>  = Client (mt7601u) =
>>
>> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
>> ctrl_interface=/var/run/wpa_supplicant
>> ctrl_interface_group=wheel
>> mac_addr=1
>> network={
>> ssid="WiFiRd"
>> bssid=ee:dd:cc:bb:aa:00
>> key_mgmt=WPA-PSK
>> psk="**"
>> }
>>
>>
>> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f 
>> wpasuplog.txt
>>
>>
>> # grep -i 'mac\|rand\|connected' wpasuplog.txt
>> random: Trying to read entropy from /dev/random
>> mac_addr=1
>> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
>> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
>> EAPOL: SUPP_PAE entering state DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
>> random: Got 20/20 bytes from /dev/random
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> nl80211: set_mac_addr for wlp0s2f1u3 to 0e:5d:07:b0:73:a6
>> wlp0s2f1u3: Using random MAC address 0e:5d:07:b0:73:a6
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
>> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
>> wlp0s2f1u3: Request to deauthenticate - bssid=00:00:00:00:00:00 

Re: How to activate MAC address randomization?

[poma]

On 24.05.2016 13:22, poma wrote:
> 
> [...] NetworkManager [...]
> 
> WPA Supplicant comparative test
> - wpa_supplicant v2.6-devel git a26c9c2 2016-05-20
> - Linux 4.6
> - QEMU emulator version 2.6.0 (Hotspot)
> 
> 
> Pre-association / Scanning random MAC address
> 
>  = Client (mt7601u) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> preassoc_mac_addr=1
> network={
> ssid="WiFiRd"
> bssid=ee:dd:cc:bb:aa:00
> key_mgmt=WPA-PSK
> psk="**"
> }
> 
> 
> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i 'mac\|rand\|connected' wpasuplog.txt
> random: Trying to read entropy from /dev/random
> preassoc_mac_addr=1
> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
> EAPOL: SUPP_PAE entering state DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
> random: Got 20/20 bytes from /dev/random
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> nl80211: set_mac_addr for wlp0s2f1u3 to 4a:b1:d6:28:4c:90
> wlp0s2f1u3: Using random MAC address 4a:b1:d6:28:4c:90
> nl80211: set_mac_addr for wlp0s2f1u3 to 00:aa:bb:cc:dd:ee
> wlp0s2f1u3: Using permanent MAC address
> wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed 
> [id=0 id_str=]
> ...
> 
> 
> 
>  = Hotspot (rt2800usb) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> network={
> ssid="WiFiRd"
> key_mgmt=WPA-PSK
> psk="**"
> mode=2
> }
> 
> 
> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i '4a:b1:d6:28:4c:90\|00:aa:bb:cc:dd:ee' wpasuplog.txt
> nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=4a:b1:d6:28:4c:90 
> bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-19 fc=0x40 seq_ctrl=0x3b20 
> stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
> nl80211: send_mlme - da= 4a:b1:d6:28:4c:90 noack=1 freq=0 no_cck=0 
> offchanok=0 wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
> nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=00:aa:bb:cc:dd:ee 
> bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-19 fc=0x8b0 seq_ctrl=0x3b60 
> stype=11 (WLAN_FC_STYPE_AUTH) len=30
> ...
> wlp2s2f7u2: AP-STA-CONNECTED 00:aa:bb:cc:dd:ee
> ...
> 
> 
> ~~~
> 
> 
> Association / Connection random MAC address
> 
> 
>  = Client (mt7601u) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> mac_addr=1
> network={
> ssid="WiFiRd"
> bssid=ee:dd:cc:bb:aa:00
> key_mgmt=WPA-PSK
> psk="**"
> }
> 
> 
> # wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt
> 
> 
> # grep -i 'mac\|rand\|connected' wpasuplog.txt
> random: Trying to read entropy from /dev/random
> mac_addr=1
> wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
> wlp0s2f1u3: WPS: UUID based on MAC address: [...]
> EAPOL: SUPP_PAE entering state DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
> random: Got 20/20 bytes from /dev/random
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> nl80211: set_mac_addr for wlp0s2f1u3 to 0e:5d:07:b0:73:a6
> wlp0s2f1u3: Using random MAC address 0e:5d:07:b0:73:a6
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> SCANNING
> wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
> wlp0s2f1u3: Request to deauthenticate - bssid=00:00:00:00:00:00 
> pending_bssid=00:00:00:00:00:00 reason=3 state=DISCONNECTED
> wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
> 
> 
> 
>  = Hotspot (rt2800usb) =
> 
> # grep -v '^#\|^$' /etc/wpa_supplicant.conf 
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> network={
> ssid="WiFiRd"
> key_mgmt=WPA-PSK
> psk="**"
> mode=2
> }
> 
> 
> # wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.

Re: How to activate MAC address randomization?

[poma]

[...] NetworkManager [...]

WPA Supplicant comparative test
- wpa_supplicant v2.6-devel git a26c9c2 2016-05-20
- Linux 4.6
- QEMU emulator version 2.6.0 (Hotspot)


Pre-association / Scanning random MAC address

 = Client (mt7601u) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
preassoc_mac_addr=1
network={
ssid="WiFiRd"
bssid=ee:dd:cc:bb:aa:00
key_mgmt=WPA-PSK
psk="**"
}


# wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i 'mac\|rand\|connected' wpasuplog.txt
random: Trying to read entropy from /dev/random
preassoc_mac_addr=1
wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
wlp0s2f1u3: WPS: UUID based on MAC address: [...]
EAPOL: SUPP_PAE entering state DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
random: Got 20/20 bytes from /dev/random
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
nl80211: set_mac_addr for wlp0s2f1u3 to 4a:b1:d6:28:4c:90
wlp0s2f1u3: Using random MAC address 4a:b1:d6:28:4c:90
nl80211: set_mac_addr for wlp0s2f1u3 to 00:aa:bb:cc:dd:ee
wlp0s2f1u3: Using permanent MAC address
wlp0s2f1u3: CTRL-EVENT-CONNECTED - Connection to ee:dd:cc:bb:aa:00 completed 
[id=0 id_str=]
...



 = Hotspot (rt2800usb) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="WiFiRd"
key_mgmt=WPA-PSK
psk="**"
mode=2
}


# wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i '4a:b1:d6:28:4c:90\|00:aa:bb:cc:dd:ee' wpasuplog.txt
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=4a:b1:d6:28:4c:90 
bssid=ff:ff:ff:ff:ff:ff freq=2462 ssi_signal=-19 fc=0x40 seq_ctrl=0x3b20 
stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=83
nl80211: send_mlme - da= 4a:b1:d6:28:4c:90 noack=1 freq=0 no_cck=0 offchanok=0 
wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: RX frame da=ee:dd:cc:bb:aa:00 sa=00:aa:bb:cc:dd:ee 
bssid=ee:dd:cc:bb:aa:00 freq=2462 ssi_signal=-19 fc=0x8b0 seq_ctrl=0x3b60 
stype=11 (WLAN_FC_STYPE_AUTH) len=30
...
wlp2s2f7u2: AP-STA-CONNECTED 00:aa:bb:cc:dd:ee
...


~~~


Association / Connection random MAC address


 = Client (mt7601u) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
mac_addr=1
network={
ssid="WiFiRd"
bssid=ee:dd:cc:bb:aa:00
key_mgmt=WPA-PSK
psk="**"
}


# wpa_supplicant -i wlp0s2f1u3 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i 'mac\|rand\|connected' wpasuplog.txt
random: Trying to read entropy from /dev/random
mac_addr=1
wlp0s2f1u3: Own MAC address: 00:aa:bb:cc:dd:ee
wlp0s2f1u3: WPS: UUID based on MAC address: [...]
EAPOL: SUPP_PAE entering state DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED
random: Got 20/20 bytes from /dev/random
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
nl80211: set_mac_addr for wlp0s2f1u3 to 0e:5d:07:b0:73:a6
wlp0s2f1u3: Using random MAC address 0e:5d:07:b0:73:a6
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> SCANNING
wlp0s2f1u3: State: AUTHENTICATING -> DISCONNECTED
wlp0s2f1u3: Request to deauthenticate - bssid=00:00:00:00:00:00 
pending_bssid=00:00:00:00:00:00 reason=3 state=DISCONNECTED
wlp0s2f1u3: State: DISCONNECTED -> DISCONNECTED



 = Hotspot (rt2800usb) =

# grep -v '^#\|^$' /etc/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="WiFiRd"
key_mgmt=WPA-PSK
psk="**"
mode=2
}


# wpa_supplicant -i wlp2s2f7u2 -c /etc/wpa_supplicant.conf -d -f wpasuplog.txt


# grep -i acknowledge wpasuplog.txt
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge authentication 
response
hostapd_logger: STA 0e:5d:07:b0:73:a6 - did not acknowledge 

Re: GDM7240 - NULL pointer dereference

[poma]

On 03.04.2016 12:15, Alex wrote:
> Hello,
> [1.] System hang when connecting USB modem (LU150)
> [2.] I'm running 4.4.5 kernel (Arch Linux). When this modem is connected 
> I'm getting below trace in journal and system becomes unusable - lsusb, 
> logout and some other operations lead to a complete hang, the only way 
> out is hardware power off. This modem works perfectly on 4.1.20 kernel - 
> attaching all outputs for both kernels.
...

See if it is related to
http://thread.gmane.org/gmane.linux.usb.general/135626

if so, kernel >= 4.5
i.e.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/usb/cdc_ether.c?h=linux-4.5.y=29c6dd5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtl8xxxu 4.4.5(from f23): I get a panic adding a new device to the driver

[poma]

On 17.03.2016 19:02, Jes Sorensen wrote:
> Jes Sorensen  writes:
>> Xose Vazquez Perez  writes:
>>> Hi,
>>>
>>> If I do:
>>> # echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id
>>
>> Hi Xose,
>>
>> Yes please don't do that. The rtl8xxxu driver relies on the .driver_info
>> field in struct use_device_id to carry information for the different
>> types of devices. If you hot add a device like above, the driver will
>> fail because that field now contains a NULL pointer.
>>
>> I should probably add a check for it in the probe function, but it will
>> simply be there to spit out a warning that it doesn't work to hot add a
>> device like this.
>>
>> If you build it with CONFIG_RTL8XXXU_UNTESTED the 0bda:8176 should be
>> included in the device list.
>>
>> Cheers,
>> Jes
> 
> Hi Xose,
> 
> I added the following patch to my tree to avoid this.
> 
> Cheers,
> Jes
> 
> commit 9202f4947aac1d60084ee79c9b5294eb42ba59dc
> Author: Jes Sorensen 
> Date:   Thu Mar 17 13:53:48 2016 -0400
> 
> rtl8xxxu: Fix OOPS if user tries to add device via /sys
> 
> This driver relies on driver_info in struct usb_device_id, hence
> adding a device via  /sys/bus/usb/drivers/rtl8xxxu/new_id would result
> in a NULL pointer dereference.
> 
> Instead print a message and return -ENODEV
> 
> Reported-by: Xose Vazquez Perez 
> Signed-off-by: Jes Sorensen 
> 
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c 
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> index 8d893f4..55fc00e 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> @@ -9671,6 +9671,15 @@ static int rtl8xxxu_probe(struct usb_interface 
> *interface,
>  
>   udev = usb_get_dev(interface_to_usbdev(interface));
>  
> + if (!id->driver_info) {
> + dev_warn(>dev,
> +  "rtl8xxxu relies on driver_info in struct 
> usb_device_id.\n");
> + dev_warn(>dev,
> +  "Adding a device via 
> /sys/bus/usb/drivers/rtl8xxxu/new_id is not supported!\n");
> + ret = -ENODEV;
> + goto exit;
> + }
> +
>   switch (id->idVendor) {
>   case USB_VENDOR_ID_REALTEK:
>   switch(id->idProduct) {
>


Dynamic adding and removing a new device IDs to a USB device drivers
via /sys/bus/usb/drivers/.../[new_id|remove_id]
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-usb

is not supported only with rtl8xxxu?


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

[poma]

On 27.06.2015 22:45, poma wrote:
> 
> mt7601u landed in 'linux-next'
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/wireless/mediatek/mt7601u
> 
> the v4.2 kernel is predicted for Sunday, 2015-08-23
> http://phb-crystal-ball.org
> 
> For the firmware(mt7601u.bin) as part of the essential functionality of the 
> device
> it would be good to land in 'linux-firmware' *even* before the actual kernel 
> release v4.2
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree
> 
> 
> tempus fugit
> 


Add firmware for mt7601u. version 34.
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=9df5430

Thanks Hua Shao for the firmware,
and of course,
thanks Jakub Kiciński for the driver.

Oh yeah!


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8189ETV

[poma]

On 01.09.2015 10:43, Hans de Goede wrote:
> Hi,
> 
> On 31-08-15 22:31, poma wrote:
> 
>> Let's see if Hans knows what type of this device is RTL8189ETV.
> 
> Assuming you are talking about the wifi module of the Allwinner H3
> based Orangepi2 as shown here:
> 
> http://linux-sunxi.org/images/9/96/Xunlong_OrangePi2_front.jpg
> 
> Then we are talking about a realtek sdio wifi module, not usb but sdio!
> 

Care to share link to RTL8189ETV datasheet?

> These wifi modules are not supported at all by upstream kernels atm.
> 
> The path to getting these supported is:
> 
> 1) Find the latest out of tree code for them

I found nothing useful apropos rtl8189etv in "linux sdk source code" 
http://www.orangepi.org/downloadresources/

> 2) Get it to build and work with mainline
> 3) Get it added to staging
> 4) Clean it up, clean it up more, clean it up even more
> 5) Repeat 4
> 6) At one future point hopefully the driver can be moved from staging
> to drivers/net/wifi
> 

Yeah, let's see is Realtek R gonna realize points 2 - 6.
After all, it's their job, right.

> Good luck with this!

Good luck with this!

> 
> Regards,
> 
> Hans
> 
> 
> p.s.
> 
> I agree with Larry that the way you express yourself in your communications
> is not really helpful. Please remember to be excellent to each other.
> 

p.s.
You can agree with whoever you want man,
however I don't understand why you telling me, or what are you talking about in 
the first place.

p.p.s.
Although it did not help much, thanks for reply.


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8189ETV

[poma]

On 31.08.2015 23:25, Larry Finger wrote:
> On 08/31/2015 03:31 PM, poma wrote:
>> On 31.08.2015 19:51, Larry Finger wrote:
>>> On 08/31/2015 12:06 PM, poma wrote:
>>>> On 31.08.2015 18:00, poma wrote:
>>>>>
>>>>> Hi Fi,
>>>>>
>>>>> What is this device, is it supported by
>>>>> https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8189es
>>>>>
>>>>> $ modinfo rtl8189es
>>>>> modinfo: ERROR: Module rtl8189es not found.
>>>>>
>>>>
>>>> or is it supported by
>>>> https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8188eu
>>>> https://github.com/lwfinger/rtl8188eu
>>>> as RTL8188ETV is
>>>>
>>>> $ modinfo rtl8188eu
>>>> modinfo: ERROR: Module rtl8188eu not found.
>>>>
>>>>
>>>> However RTL8188ETV is USB 2.0 device,
>>>> eee not again!
>>>
>>> That last comment does not help.
>>>
>>> If rtl8188eu is not available, that is the fault of your distro, not 
>>> anything
>>> that driver maintainers can help. That driver is in the staging directory, 
>>> and
>>> some distros do not include any of those drivers in their kernels.
>>>
>>> eee not again! Someone posts about a USB device not found, 
>>> and
>>> they refuse/fail to provide the USB ID. Why, I do not know when the lsusb
>>> command provides this info so easily.
>>>
>>> Larry
>>>
>>>
>>
>>
>> What's the hurry, Larry.
>> Let's see if Hans knows what type of this device is RTL8189ETV.
>>
>> According to what is written here
>> http://linux-sunxi.org/Xunlong_Orange_Pi#Variants
>> http://www.orangepi.org/orangepi2
>> RTL8189ETV, whatever it is, is an integral part of some "O-Pi" variants.
>>
>> About rtl8188etv can be read here
>> http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread=25=wifi
>> but there is no mention of RTL8189ETV.
>>
>> WikiDevi also returns nothing
>> https://wikidevi.com/wiki/Main_Page
>>"Search results
>>...
>>There were no results matching the query.
>>
>>Create the page "RTL8189ETV" on this wiki!"
>>
>> I'm trying to determine in advance,
>> what components are supported,
>> what components are not supported,
>> what components will never be supported,
>> what components will never be supported in mainline kernel.
>>
>> Therefore, I can not show 'lsusb' output. :)
>>
>> "Distro" is not decisive in this matter, moreover dunno what are you 
>> referring with "your distro".
>>
>> ee not again!
> 
> Silly me. I thought you were trying to get help implemetiing that device.
> 
> 

Implemetiing!? :)
You must have me confused with someone else, man.


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RTL8189ETV

[poma]

Hi Fi,

What is this device, is it supported by
https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8189es

$ modinfo rtl8189es
modinfo: ERROR: Module rtl8189es not found.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8189ETV

[poma]

On 31.08.2015 18:00, poma wrote:
> 
> Hi Fi,
> 
> What is this device, is it supported by
> https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8189es
> 
> $ modinfo rtl8189es
> modinfo: ERROR: Module rtl8189es not found.
> 

or is it supported by
https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8188eu
https://github.com/lwfinger/rtl8188eu
as RTL8188ETV is

$ modinfo rtl8188eu
modinfo: ERROR: Module rtl8188eu not found.


However RTL8188ETV is USB 2.0 device,
eee not again!




--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8189ETV

[poma]

On 31.08.2015 19:51, Larry Finger wrote:
> On 08/31/2015 12:06 PM, poma wrote:
>> On 31.08.2015 18:00, poma wrote:
>>>
>>> Hi Fi,
>>>
>>> What is this device, is it supported by
>>> https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8189es
>>>
>>> $ modinfo rtl8189es
>>> modinfo: ERROR: Module rtl8189es not found.
>>>
>>
>> or is it supported by
>> https://github.com/orangepi-xunlong/linux-sunxi/tree/orangepi-3.4/drivers/net/wireless/rtl8188eu
>> https://github.com/lwfinger/rtl8188eu
>> as RTL8188ETV is
>>
>> $ modinfo rtl8188eu
>> modinfo: ERROR: Module rtl8188eu not found.
>>
>>
>> However RTL8188ETV is USB 2.0 device,
>> eee not again!
> 
> That last comment does not help.
> 
> If rtl8188eu is not available, that is the fault of your distro, not anything 
> that driver maintainers can help. That driver is in the staging directory, 
> and 
> some distros do not include any of those drivers in their kernels.
> 
> eee not again! Someone posts about a USB device not found, 
> and 
> they refuse/fail to provide the USB ID. Why, I do not know when the lsusb 
> command provides this info so easily.
> 
> Larry
> 
> 


What's the hurry, Larry.
Let's see if Hans knows what type of this device is RTL8189ETV.

According to what is written here
http://linux-sunxi.org/Xunlong_Orange_Pi#Variants
http://www.orangepi.org/orangepi2
RTL8189ETV, whatever it is, is an integral part of some "O-Pi" variants.

About rtl8188etv can be read here
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread=25=wifi
but there is no mention of RTL8189ETV.

WikiDevi also returns nothing
https://wikidevi.com/wiki/Main_Page
  "Search results
  ...
  There were no results matching the query.

  Create the page "RTL8189ETV" on this wiki!"

I'm trying to determine in advance,
what components are supported,
what components are not supported,
what components will never be supported,
what components will never be supported in mainline kernel.

Therefore, I can not show 'lsusb' output. :)

"Distro" is not decisive in this matter, moreover dunno what are you referring 
with "your distro".

ee not again!

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: CPU: 3 PID: 827 at lib/dma-debug.c:1169 check_for_stack+0x94/0xe0()

[poma]

[ cut here ]
WARNING: CPU: 3 PID: 827 at lib/dma-debug.c:1169 check_for_stack+0x94/0xe0()
ehci-pci :00:02.1: DMA-API: device driver maps memory from stack 
[addr=8800bc6dfa3c]
Modules linked in: ... mt7601u(+) mac80211 ... cfg80211 rfkill ...
CPU: 3 PID: 827 Comm: systemd-udevd Not tainted 
4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
...
Call Trace:
 [81868d8e] dump_stack+0x4c/0x65
 [810ab406] warn_slowpath_common+0x86/0xc0
 [810ab495] warn_slowpath_fmt+0x55/0x70
 [81871e26] ? _raw_spin_unlock_irqrestore+0x36/0x60
 [81450044] check_for_stack+0x94/0xe0
 [8145062b] debug_dma_map_page+0xfb/0x140
 [81614eb8] usb_hcd_map_urb_for_dma+0x608/0x760
 [8161548d] usb_hcd_submit_urb+0x1cd/0xab0
 [8110315f] ? save_trace+0x3f/0xc0
 [81106edd] ? mark_held_locks+0x7d/0xb0
 [8110ddd5] ? __raw_spin_lock_init+0x25/0x60
 [81103b73] ? lockdep_init_map+0x73/0x640
 [81107039] ? trace_hardirqs_on_caller+0x129/0x1b0
 [8161707c] usb_submit_urb+0x3fc/0x5a0
 [81617947] usb_start_wait_urb+0x77/0x180
 [8124a83e] ? __kmalloc+0x28e/0x360
 [81617b2c] usb_control_msg+0xdc/0x130
 [a0850510] mt7601u_vendor_request+0xf0/0x310 [mt7601u]
 [8186f4dc] ? __mutex_unlock_slowpath+0xbc/0x180
 [a08507b9] mt7601u_rr+0x59/0x280 [mt7601u]
 [8161b738] ? usb_autosuspend_device+0x28/0x30
 [a0857c93] mt7601u_wait_asic_ready+0x23/0x60 [mt7601u]
 [a0850ac0] mt7601u_probe+0xe0/0x220 [mt7601u]
 [8161c03b] usb_probe_interface+0x1bb/0x2e0
 [81579f26] driver_probe_device+0x1f6/0x450
 [8157a214] __driver_attach+0x94/0xa0
 [8157a180] ? driver_probe_device+0x450/0x450
 [815778f3] bus_for_each_dev+0x73/0xc0
 [815796fe] driver_attach+0x1e/0x20
 [8157922e] bus_add_driver+0x1ee/0x280
 [8157b0a0] driver_register+0x60/0xe0
 [8161a87d] usb_register_driver+0xad/0x160
 [a086e000] ? 0xa086e000
 [a086e01e] mt7601u_driver_init+0x1e/0x20 [mt7601u]
 [81002123] do_one_initcall+0xb3/0x200
 [8124ac65] ? kmem_cache_alloc_trace+0x355/0x380
 [81867c37] ? do_init_module+0x28/0x1e9
 [81867c6f] do_init_module+0x60/0x1e9
 [81154167] load_module+0x21f7/0x28d0
 [8114f600] ? m_show+0x1b0/0x1b0
 [81026d79] ? sched_clock+0x9/0x10
 [810e6ddc] ? local_clock+0x1c/0x20
 [811549b8] SyS_init_module+0x178/0x1c0
 [8187282e] entry_SYSCALL_64_fastpath+0x12/0x76
---[ end trace 0c0ff6cd25624338 ]---


Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1252336
https://bugzilla.kernel.org/show_bug.cgi?id=102661
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

[poma]

mt7601u landed in 'linux-next'
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/wireless/mediatek/mt7601u

the v4.2 kernel is predicted for Sunday, 2015-08-23
http://phb-crystal-ball.org

For the firmware(mt7601u.bin) as part of the essential functionality of the 
device
it would be good to land in 'linux-firmware' *even* before the actual kernel 
release v4.2
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree


tempus fugit

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

[poma]

On 20.05.2015 19:14, Jakub Kiciński wrote:
 On Wed, 20 May 2015 19:06:04 +0200, poma wrote:
 With the script 'mt7601u-fw-install' can be initiated the download and 
 installation of the required firmware,
 though it would be optimal to resolve it in the following manner:

 In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
 https://github.com/openwrt/mt76

 there is a license file together with firmwares:
 https://github.com/openwrt/mt76/blob/master/firmware


 Whether the same can be done with:
 mt7601u -  Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi 
 dongle
 https://github.com/kuba-moo/mt7601u
 ?
 
 I will ask MediaTek to send firmware to linux-firmware.git once the
 driver passes review and is accepted to mainline.
 

Yeah, the foundation is already there:
linux-firmware: Add firmware files for mtk mt7630/mt7650 chipsets
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=8267525

Good luck.


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

[poma]

On 18.05.2015 02:03, poma wrote:
 
 Preliminary test results
 
 - lsusb -d 148f:7601:
 Bus 001 Device 007: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless 
 Adapter
 
 
 - https://github.com/kuba-moo/mt7601u
 - git log -1:
 commit ad5474ecd9fd6efd4a7f03f4a8c71ea4bb57ca73
 Author: Jakub Kicinski kubak...@wp.pl
 Date:   Wed May 6 20:44:18 2015 +0200
 
 make sure .disconnect() doesn't cleanup the device if .resume() failed
 
 Signed-off-by: Jakub Kicinski kubak...@wp.pl
 
 
 - modinfo mt7601u:
 filename:   /lib/modules/4.0.3-202.fc21.x86_64/updates/mt7601u.ko
 license:GPL
 firmware:   mt7601u.bin
 alias:  usb:v7392p7710d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2A5Fp1000d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2955p1001d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2955p0001d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2717p4106d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v2001p3D04d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Dd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Cd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Bd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp760Ad*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v148Fp7601d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v13D3p3434d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v13D3p3431d*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v0E8Dp760Bd*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v0E8Dp760Ad*dc*dsc*dp*ic*isc*ip*in*
 alias:  usb:v0B05p17D3d*dc*dsc*dp*ic*isc*ip*in*
 depends:cfg80211,mac80211
 vermagic:   4.0.3-202.fc21.x86_64 SMP mod_unload 
 signer: Fedora kernel signing key
 sig_key:95:7D:C8:E5:9F:5D:E6:03:71:49:1A:D0:9A:C6:8F:85:16:6C:B3:94
 sig_hashalgo:   sha256
 
 
 - md5sum /lib/firmware/mt7601u.bin:
 696cedb8e76ecc0cda9f9b0d3972c64d  /lib/firmware/mt7601u.bin
 
 
 - NetworkManager --version:
 1.0.2-2.fc21
 
 
 plug in device:
 - dmesg:
 usb 1-4: new high-speed USB device number 6 using ehci-pci
 usb 1-4: New USB device found, idVendor=148f, idProduct=7601
 usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-4: Product: 802.11 n WLAN
 usb 1-4: Manufacturer: MediaTek
 usb 1-4: SerialNumber: 1.0
 cfg80211: ...
 ...
 usb 1-4: reset high-speed USB device number 6 using ehci-pci
 mt7601u 1-4:1.0: ASIC revision: 76010001 MAC revision: 76010500
 mt7601u 1-4:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 
 201302052146
 mt7601u 1-4:1.0: Warning: unsupported EEPROM version 0d
 mt7601u 1-4:1.0: EEPROM ver:0d fae:00
 ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
 usbcore: registered new interface driver mt7601u
 mt7601u 1-4:1.0 wlp0s2f1u4: renamed from wlan0
 ...
 cfg80211: ...
 ...
 wlp0s2f1u4: authenticate with BSSID
 wlp0s2f1u4: send auth to BSSID (try 1/3)
 wlp0s2f1u4: authenticated
 wlp0s2f1u4: associate with BSSID (try 1/3)
 wlp0s2f1u4: RX AssocResp from BSSID (capab=0x411 status=0 aid=1)
 wlp0s2f1u4: associated
 
 
 - iwconfig wlp0s2f1u4:
 wlp0s2f1u4  IEEE 802.11bgn  ESSID:AP  
   Mode:Managed  Frequency:2.422 GHz  Access Point: BSSID   
   Bit Rate=135 Mb/s   Tx-Power=20 dBm   
   Retry short limit:7   RTS thr:off   Fragment thr:off
   Encryption key:off
   Power Management:off
   Link Quality=67/70  Signal level=-43 dBm  
   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:873   Missed beacon:0
 
 
...

Can be tested with the test compilation I share with you bona fide:
http://goo.gl/Gm4ffO
ISO/Fedora-Live-Xfce-WiFi.iso

Runs on baremetal  QEMU/KVM/Libvirt/Virtual Machine Manager
http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest


With the script 'mt7601u-fw-install' can be initiated the download and 
installation of the required firmware,
though it would be optimal to resolve it in the following manner:

In OpenWrt repo - mt76 - mac80211 driver for MediaTek MT76x2 802.11ac chips
https://github.com/openwrt/mt76

there is a license file together with firmwares:
https://github.com/openwrt/mt76/blob/master/firmware


Whether the same can be done with:
mt7601u -  Linux mac80211-based driver for Mediatek MT7601U USB bgn WiFi dongle
https://github.com/kuba-moo/mt7601u
?


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

[poma]

On 06.02.2015 18:29, Jakub Kiciński wrote:
 Hello everyone!
 
 I put together a mac80211 driver for Mediatek MT7601U.  It's partially
 based on Felix's mt76, but I'm not sure if it will make sense to merge
 the two together.  MT7601U is a pretty old 1x1 bgn chip for USB dongles
 and mt76 now only supports the latest and greatest ac APs.
 
 I'm testing STA functionality right now and it seems to be working ok.
 The code is very much a work in progress but if anyone is interested you
 can get it here:
 
 https://github.com/kuba-moo/mt7601u
 
 Cheers,
 kuba
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

How many mt7601u module editions exists there? :)
- vendor's
- vendor's patched (how many forms of the same)
- your reinvented
- the one on which pán Gruszka allegedly works?
- any more?


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Realtek RTL8812AE 802.11ac

[poma]

On 31.01.2015 19:01, Larry Finger wrote:
 On 01/31/2015 12:19 AM, poma wrote:

 Salutem


 Is the combination with Bluetooth only essential difference between 
 RTL8821AE and RTL8812AE?

 *If* the undermentioned two devices are based on RTL8812AE chipset,
 whether they supported via 'rtl8821ae.ko'  'rtl8821aefw.bin'?

 PCIe RTL8812AE 802.11abgn+ac 2x2:2


 Amped Wireless PCI20E (FCC ID: ZTT-PCI20E)
https://wikidevi.com/wiki/Amped_Wireless_PCI20E

 - High Power AC1200 Wi-Fi PCI-E Adapter
PCI20E
http://www.ampedwireless.com/products/pci20e.html

 - http://www.amazon.com/Amped-Wireless-AC1200-Adapter-PCI20E/dp/B00I9AS1JA


 D-Link DWA-582 rev A1 (FCC ID: KA2WA582A1)
https://wikidevi.com/wiki/D-Link_DWA-582_rev_A1

 - Wireless AC1200 Dual Band PCIe Desktop Adapter
DWA-582

 http://www.dlink.com.au/home-solutions/wireless-ac1200-dual-band-pcie-desktop-adapter

 - http://www.amazon.com/WIRELESS-AC1200-EXPRESS-ADAPTER-DUAL/dp/B00PHVQV14
 
 Both RTL8812AE and RTL8821AE have wifi and Bluetooth. There is a difference 
 in 
 the radio structure. The 8812 has the potential to handle 867 Mbps - the 8821 
 only half that rate. In any case, driver rtl8821ae handles both devices, and 
 the 
 firmware is the same. One other difference is that I have not tested the 8812 
 as 
 I only have 8821 devices.
 
 One other difference is that the firmware can handle BT coexistence 
 internally 
 in the 8821, but not in the 8812. Realtek is still working on getting a 
 method 
 of handling that problem. None of the Realtek Bluetooth adaptors has a driver 
 in 
 the kernel. Fixing that issue is my current project.
 
 Larry
 

Sir, thanks a lot for response.


poma

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Realtek RTL8812AE 802.11ac

[poma]

Salutem


Is the combination with Bluetooth only essential difference between RTL8821AE 
and RTL8812AE?

*If* the undermentioned two devices are based on RTL8812AE chipset,
whether they supported via 'rtl8821ae.ko'  'rtl8821aefw.bin'?

PCIe RTL8812AE 802.11abgn+ac 2x2:2


Amped Wireless PCI20E (FCC ID: ZTT-PCI20E) 
  https://wikidevi.com/wiki/Amped_Wireless_PCI20E

- High Power AC1200 Wi-Fi PCI-E Adapter 
  PCI20E
  http://www.ampedwireless.com/products/pci20e.html

- http://www.amazon.com/Amped-Wireless-AC1200-Adapter-PCI20E/dp/B00I9AS1JA


D-Link DWA-582 rev A1 (FCC ID: KA2WA582A1) 
  https://wikidevi.com/wiki/D-Link_DWA-582_rev_A1

- Wireless AC1200 Dual Band PCIe Desktop Adapter
  DWA-582
  
http://www.dlink.com.au/home-solutions/wireless-ac1200-dual-band-pcie-desktop-adapter

- http://www.amazon.com/WIRELESS-AC1200-EXPRESS-ADAPTER-DUAL/dp/B00PHVQV14


/usr/src/kernels/3.18.3-201.fc21.x86_64/drivers/net/wireless/rtlwifi/Kconfig
...
config RTL8821AE
tristate Realtek RTL8821AE/RTL8812AE Wireless Network Adapter
depends on PCI
select RTLWIFI
select RTLWIFI_PCI
select RTLBTCOEXIST
---help---
This is the driver for Realtek RTL8i821AE/RTL8812AE 802.11av PCIe
wireless network adapters.

If you choose to build it as a module, it will be called rtl8821ae
...


$ modinfo rtl8821ae
filename:   
/lib/modules/3.18.3-201.fc21.x86_64/kernel/drivers/net/wireless/rtlwifi/rtl8821ae/rtl8821ae.ko.xz
firmware:   rtlwifi/rtl8821aefw.bin
description:Realtek 8821ae 802.11ac PCI wireless
license:GPL
author: Realtek WlanFAE wlan...@realtek.com
alias:  pci:v10ECd8821sv*sd*bc*sc*i*
alias:  pci:v10ECd8812sv*sd*bc*sc*i*
depends:rtlwifi,rtl_pci,btcoexist,mac80211
...


poma

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: moving the wiki

[poma]

On 10.02.2014 20:20, Johannes Berg wrote:
 Hi everyone,
 
 There has been kernel.org infrastructure for wikis for a long time,
 though IIRC it didn't exist back when we set up our current wiki.
 However, it seems like a good idea to convert the wiki to the kernel.org
 infrastructure. This has some obvious advantages (like https support)
 and gets us better support for it, with hopefully less downtime.
 
 As a consequence, we'll be doing the following:
  * Mark the current wiki read-only, to guarantee a stable conversion.
 This
shouldn't take all that long, but we'll have to see.
  * I'll keep the read-only wiki at http://wireless.sipsolutions.net/ for
 a while,
in case somebody needs history - you can also download page/history
 snapshots.
  * As we have a LOT of dead accounts, I've decided to NOT migrate them.
 You'll
have to sign up again, but I couldn't convert notifications etc.
 anyway, so
you'd have to touch those regardless.
  * We'll also drop page history, converting that is a bit more difficult
 and the
history isn't all that interesting for most pages.
  * For now, I won't be converting the style/skin. If anybody has (or
 knows
someone with) experience skinning mediawiki, help would be welcome.
 
 Obviously, another consequence is that the wiki markup will change
 somewhat. Moin and Mediawiki aren't too far from each other (except for
 table syntax), but there are some things that are different that you'll
 have to get used to when editing.
 
 I think/hope that all this can happen over the next few days. If there
 are any concerns (other than don't do it) let me know.
 
 Wish me luck ;-)
 
 johannes
 

https://wireless.wiki.kernel.org/en/users/devices
Supported devices
We try to maintain lists of supported hardware for each driver, so there's no 
combined information here.
TODO: add a list of driver device pages here? We no longer have a macro to 
collect it all into one big list as we used to have.
Looking for ...

If you do not have, WikiDevi has ;)

https://wikidevi.com/wiki/Main_Page
State of the Database
5223 wireless adapters...


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fw: rtl8192eu driver

[poma]

On 08.11.2014 08:51, Pomidora Belisima wrote:
 On Fri, Nov 7, 2014 at 10:30 PM, Bob Marcan bob.mar...@lnx.no-ip.org
 wrote:
 
 Obviously we should avoid this chip.
 BR, Bob

 Begin forwarded message:

 Date: Fri, 07 Nov 2014 11:21:40 -0600
 From: Larry Finger larry.fin...@lwfinger.net
 To: Bob Marcan bob.mar...@gmail.com
 Subject: Re: rtl8192eu driver


 On 11/07/2014 10:30 AM, Bob Marcan wrote:
 Hi.
 Driver for this chip is not (anymore?) available on the vendor site.
 At least not on the official download page.
 But it is available on the net.
 This is the one which i use on the Fedora 20:

 http://users.telenet.be/x86_64/RPMs/dkms-rtl8192eu-4.3.1.1-11320.20140505.src.rpm
 Does this chip can be included  in  the mainstream?

 I do not have any copies of a device with the RTL8192EU chip, thus I
 would not be able to test any driver. In addition, I have had much
 negative feedback from users, and little support from the Realtek USB
 group. For those reasons, I will never work on another Realtek USB
 driver that does not use mac80211.

 Perhaps someone else will take that driver, work for hundreds of hours
 to get it into a form that is acceptable for kernel inclusion, submit
 it, and then maintain it. I can assure you that I am not the person to
 do so.

 Larry



 
 At least it is good to know.
 

Also it is very unfortunate to know Realtek relates in such a manner toward its 
own devices in Linux environment. 
Realtek devices are good devices.

Larry thank you for your hard work so far.

BTW FYI Bob, here you can find my Realtek RTL8188SU review - follows all links
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2014-November/006714.html

In pursuit of perfect USB-WiFi device on Linux.


poma


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rt2x00-users] Ralink RT3070(rt2800usb) - The Tortoise and the Hare

[poma]

Performance with this firmware versions are even worse

ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 
'rt2870.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 
0.22

ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 
'rt2870.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 
0.233

ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 
'rt2870.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 
0.33



Haueu this is interesting, original module rt3070sta/rt5572sta achieves the 
same performance 
as the rt2800usb  Co. with firmware rt2870.bin version: 0.29, those with the 
beginning of the thread.


rt3070sta: module verification failed: signature and/or  required key missing - 
tainting kernel
rtusb init ---
usbcore: registered new interface driver rt2870
 rt28xx_init, Status=0


# iwconfig ra0 
ra0   Ralink STA  ESSID:AP1  Nickname:RT2870STA
  Mode:Managed  Frequency=2.437 GHz  Access Point: 00:01:02:03:04:05   
  Bit Rate=135 Mb/s   
  RTS thr:off   Fragment thr:off
  Encryption key:...-...-...-...-...-...-...-...
  Link Quality=100/100  Signal level:-17 dBm  Noise level:-83 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0


$ modinfo rt3070sta 
filename:   /lib/modules/3.17.2-200.fc20.x86_64/updates/rt3070sta.ko
version:2.3.0.4
license:GPL
description:RT2870 Wireless Lan Linux Driver
author: Paul Lin paul_...@ralinktech.com
srcversion: 0939A5C859E365CD0DC9707
alias:  usb:v177Fp0153d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v148Fp2070d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0789p0166d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07FAp7712d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v13D3p3321d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v13D3p3307d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v083ApA703d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v5A57p0282d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p821Ad*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p3821d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p822Ad*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p871Ad*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p3871d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p3822d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p6899d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p870Ad*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p3870d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0DB0p899Ad*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v203Dp14A9d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v0B05p1784d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v20B8pd*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v203Dp1480d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v04BBp0948d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v04BBp0947d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v04BBp0945d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v5A57p0283d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v5A57p5257d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1D4Dp000Ed*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1D4Dp000Cd*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07D1p3C17d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07D1p3C16d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07D1p3C0Fd*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07D1p3C0Ed*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07D1p3C0Dd*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07D1p3C0Ad*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1EDAp2310d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1A32p0304d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v7392p7711d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07B8p3072d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07B8p3071d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v07B8p3070d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v2019pAB25d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1044p800Dd*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v13D3p3305d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v13D3p3273d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1740p9709d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1740p9708d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1740p9707d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1740p9706d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1740p9705d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v1740p9703d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v083ApA702d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v083ApA701d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v083Ap7511d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v18C5p0012d*dc*dsc*dp*ic*isc*ip*in*
alias:  usb:v14B2p3C12d*dc*dsc*dp*ic*isc*ip*in*
alias:  

Re: [rt2x00-users] Ralink RT3070(rt2800usb) - The Tortoise and the Hare

[poma]

 number 3 using ehci-pci
usb 2-3: New USB device found, idVendor=0bda, idProduct=8171
usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-3: Product: RTL8188S WLAN Adapter 
usb 2-3: Manufacturer: Manufacturer Realtek 
usb 2-3: SerialNumber: 00e04c01
r8712u: module is from the staging directory, the quality is unknown, you have 
been warned.
r8712u: Staging version
r8712u: register rtl8712_netdev_ops to netdev_ops
usb 2-3: r8712u: USB_SPEED_HIGH with 4 endpoints
usb 2-3: r8712u: Boot from EFUSE: Autoload OK
usb 2-3: r8712u: CustomerID = 0x
usb 2-3: r8712u: MAC Address from efuse = 00:01:05:09:0b:0d
usb 2-3: r8712u: Loading firmware from rtlwifi/rtl8712u.bin
usbcore: registered new interface driver r8712u
r8712u 2-3:1.0 wlp0s4f1u3: renamed from wlan0
r8712u 2-3:1.0 wlp0s4f1u3: 1 RCR=0x153f00e
r8712u 2-3:1.0 wlp0s4f1u3: 2 RCR=0x553f00e

°°°
$ modinfo r8712u -n
/lib/modules/3.17.2-200.fc20.x86_64/kernel/drivers/staging/rtl8712/r8712u.ko.xz

°°°


However, it is important to note, 
despite the relatively low throughput

- 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
   rt2800usb.ko  Co. / rt2870.bin

is the combination full featured 

http://wireless.kernel.org/en/users/Drivers - rt2800usb

°°

On the other side, 
despite the great throughput

- 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter
   r8712u.ko / rtl8712u.bin

is the combination supports only managed i.e. Station (STA) infrastructure mode

Besides it needs some help with the suspend/resume cycle

Kernel module(r8712u) reload - suspend/resume - systemd
http://www.spinics.net/lists/linux-wireless/msg128666.html

http://wireless.kernel.org/en/users/Documentation/modes#Station_.28STA.29_infrastructure_mode
http://wireless.kernel.org/en/users/Drivers - r8712u
http://wireless.kernel.org/en/users/Drivers/rtl819x#staging_drivers - r8712u
http://wireless.kernel.org/en/users/Drivers/rtl819x#rtlwifi - rtl8192su

°°° °°°   

- 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter
   rtl8192su.ko / rtl8192sufw.bin

is the combination supports master i.e. AccessPoint (AP) infrastructure mode, 
and testing has proved, with the very low throughput, but still usable

RTL8188SU(rtl8192su)  rtl8192sufw-ap.bin
http://www.spinics.net/lists/linux-wireless/msg128031.html
http://goo.gl/3O3Tz4


poma


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ralink RT3070(rt2800usb) - The Tortoise and the Hare

[poma]

)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Supported commands:
 * new_interface
 * set_interface
 * new_key
 * start_ap
 * new_station
 * new_mpath
 * set_mesh_config
 * set_bss
 * authenticate
 * associate
 * deauthenticate
 * disassociate
 * join_ibss
 * join_mesh
 * set_tx_bitrate_mask
 * frame
 * frame_wait_cancel
 * set_wiphy_netns
 * set_channel
 * set_wds_peer
 * probe_client
 * set_noack_map
 * register_beacons
 * start_p2p_device
 * set_mcast_rate
 * Unknown command (104)
 * connect
 * disconnect
Supported TX frame types:
 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 
0xb0 0xc0 0xd0 0xe0 0xf0
 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 
0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 
0xb0 0xc0 0xd0 0xe0 0xf0
 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 
0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 
0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 
0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
 * IBSS: 0x40 0xb0 0xc0 0xd0
 * managed: 0x40 0xd0
 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
 * mesh point: 0xb0 0xc0 0xd0
 * P2P-client: 0x40 0xd0
 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
 * P2P-device: 0x40 0xd0
software interface modes (can always be added):
 * AP/VLAN
 * monitor
valid interface combinations:
 * #{ AP, mesh point } = 8,
   total = 8, #channels = 1
HT Capability overrides:
 * MCS: ff ff ff ff ff ff ff ff ff ff
 * maximum A-MSDU length
 * supported channel width
 * short GI for 40 MHz
 * max A-MPDU length exponent
 * min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports low priority scan.
Device supports scan flush.
Device supports AP scan.




poma

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel module(r8712u) reload - suspend/resume - systemd

[poma]

On 30.10.2014 09:52, Lubomir Rintel wrote:
 
 On Tue, 2014-10-28 at 00:43 +0100, poma wrote:
 On 28.10.2014 00:15, Lennart Poettering wrote:
 On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote:

 but is there a better way to do it?

 This appears to be a kernel driver bug. Please report this issue
 against the kernel driver in question, systemd is not the right place
 to work around that.

 Lennart


 It's not a bug, it's a feature, just as true for the systemd. :)
 Given the condition of the entire Linux Wireless LAN stack this can go 
 actually.
 
 Correct.
 
 Moreover the driver is actually only in the staging/ (crap) tree which
 means it has known serious quality issues and needs work. You may want
 to forward your original bug report to Larry  Florian. See [1].
 
 [1] https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8712/TODO
 
 Lastly, please do _NOT_ cross-post to multiple unrelated mailing lists.
 The discussion then gets disconnected.
 
 Regards,
 Lubo
 
 

Thanks Lubo.

[1]
TODO:
- merge Realtek's bugfixes and new features into the driver
- switch to use LIB80211
- switch to use MAC80211
- checkpatch.pl fixes - only a few remain
...

Guys, is it gonna happen?


poma

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rt2x00-users] MediaTek Inc. MT7601U Wireless Adapter

[poma]

On 08.10.2014 11:53, Stanislaw Gruszka wrote:
 On Tue, Oct 07, 2014 at 05:12:47PM +0200, poma wrote:
 BTW, pán Gruszka, when will these devices be supported as a part of the 
 upstream Linux kernel?
 
 I'm not an oracle :-)
 
 Larry declared to work on some mt76xx chip support, I'm cc him.
 
 I can also work on new chips for rt2x00, but wanted to finish some
 other work before.
 
 Stanislaw 
 

Even better pán Gruszka, MediaTek has spoken. :)
I hope that they really support further development here.


Toodooloo


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: Reason 7 periodic disconnect

[poma]

On 21.10.2014 10:35, Felix Fietkau wrote:
 On 2014-10-21 10:23, Laurențiu Nicola wrote:
 It's an ASUS RT-N66U running NEWD-2/K3X from r24160.
 This is a Broadcom based device, so it should behave in the same way as
 other APs/Routers running the Broadcom drivers.
 The driver should only send Reason 7 when receiving a PS-Poll, BlockAck,
 BlockAckReq or Action frame from a station that's not associated, so
 probably it has already kicked out your iwlwifi client earlier. Not sure
 why that doesn't show up in the log though.
 

Whether this might refer to the Station Control Block Timeout value

http://www.dd-wrt.com/wiki/index.php/Wl#scb_timeout
...
scb_timeout

AP only: inactivity timeout value for authenticated stas


poma


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8188SU(rtl8192su) rtl8192sufw-ap.bin

[poma]

On 15.10.2014 04:20, poma wrote:
 On 14.10.2014 22:22, Dan Williams wrote:
 On Tue, 2014-10-14 at 02:59 +0200, poma wrote:
 Realtek RTL8188SU/RTL8191SU/RTL8192SU driver
 https://github.com/chunkeey/rtl8192su
 
 RTL8188SU


 It looks like everything worked correctly here for AP mode, at least
 from the NM logs.  Is that correct?

 Dan

 
 If you don't hit something like this
 
 [   19.021232] rtlwifi: module verification failed: signature and/or  
 required key missing - tainting kernel
 [   19.304159] rtl8192s_common: Chip version 0x3
 [   19.472156] rtl_usb: rx_max_size 9100, rx_urb_num 8, in_ep 3
 [   19.472765] BUG: unable to handle kernel paging request at 8800c8f3a3cc
 [   19.473348] IP: [a0501d5e] rtl_usb_probe+0x64e/0x8f0 [rtl_usb]
 [   19.473937] PGD 202e067 PUD 12067 PMD c8f65063 PTE 8000c8f3a161
 [   19.474516] Oops: 0003 [#1] SMP 
 [   19.475083] Modules linked in: rtl8192su(OE+) rtl8192s_common(OE) 
 rtl_usb(OE) rtlwifi(OE) mac80211 cfg80211 rfkill ...
 [   19.478188] CPU: 0 PID: 470 Comm: systemd-udevd Tainted: G   OE  
 3.17.0-301.fc21.x86_64 #1
 [   19.479373] task: 8800c9313ae0 ti: 8800c9828000 task.ti: 
 8800c9828000
 [   19.479962] RIP: 0010:[a0501d5e]  [a0501d5e] 
 rtl_usb_probe+0x64e/0x8f0 [rtl_usb]
 [   19.480558] RSP: 0018:8800c982bb38  EFLAGS: 00010246
 [   19.481146] RAX: 8800c8f31a80 RBX: 8800c8f31a80 RCX: 
 
 [   19.481735] RDX: a05032e0 RSI: a05020c8 RDI: 
 8800c8f30680
 [   19.482317] RBP: 8800c982bb80 R08: 8800c8f36050 R09: 
 8800c8f35f18
 [   19.482897] R10: 8800c8f36058 R11: 03f6 R12: 
 8800c8f31a80
 [   19.483476] R13: 8800c8f30680 R14: 88007f53f800 R15: 
 
 [   19.484066] FS:  7fe3393cb880() GS:88012fc0() 
 knlGS:
 [   19.484662] CS:  0010 DS:  ES:  CR0: 8005003b
 [   19.485253] CR2: 8800c8f3a3cc CR3: c9ed2000 CR4: 
 07f0
 [   19.485843] Stack:
 [   19.486431]  8800c8f35f18 8800c8f36050 8800c8f36058 
 
 [   19.487032]  88007f53f890 88007f53f800 a050a068 
 8801297d3c30
 [   19.487633]  a050a100 8800c982bb90 a0507b55 
 8800c982bbd8
 [   19.488233] Call Trace:
 [   19.488835]  [a0507b55] rtl8192su_probe+0x15/0x20 [rtl8192su]
 [   19.489433]  [81524a0b] usb_probe_interface+0x1cb/0x340
 [   19.490022]  [81498233] driver_probe_device+0xa3/0x400
 [   19.490596]  [8149865b] __driver_attach+0x8b/0x90
 [   19.491171]  [814985d0] ? __device_attach+0x40/0x40
 [   19.491746]  [81495fd3] bus_for_each_dev+0x73/0xc0
 [   19.492303]  [81497cce] driver_attach+0x1e/0x20
 [   19.492859]  [814978a0] bus_add_driver+0x180/0x250
 [   19.493418]  [81498e24] driver_register+0x64/0xf0
 [   19.493971]  [81522fd2] usb_register_driver+0x82/0x160
 [   19.494523]  [a036b000] ? 0xa036b000
 [   19.495081]  [a036b01e] rtl92su_driver_init+0x1e/0x1000 
 [rtl8192su]
 [   19.495638]  [81002148] do_one_initcall+0xd8/0x210
 [   19.496201]  [811d1f52] ? __vunmap+0xa2/0x100
 [   19.496760]  [81116c4f] load_module+0x1ebf/0x2640
 [   19.497320]  [81112670] ? store_uevent+0x70/0x70
 [   19.497877]  [81211f37] ? kernel_read+0x57/0x90
 [   19.498433]  [81117596] SyS_finit_module+0xa6/0xe0
 [   19.498982]  [81743469] system_call_fastpath+0x16/0x1b
 [   19.499523] Code: af 39 00 00 03 c7 80 b0 08 00 00 64 00 00 00 c6 80 b4 08 
 00 00 00 c6 80 b5 08 00 00 00 c6 80 b7 08 00 00 07 c6 80 b6 08 00 00 03 c7 
 80 4c 89 00 00 02 00 00 00 c7 80 50 89 00 00 ff ff ff ff c7 
 [   19.500890] RIP  [a0501d5e] rtl_usb_probe+0x64e/0x8f0 [rtl_usb]
 [   19.501483]  RSP 8800c982bb38
 [   19.502064] CR2: 8800c8f3a3cc
 [   19.502651] ---[ end trace a2f95d6ce906062b ]---
 
 and if you don't take into account the measured bandwidth is relatively low 
 comparing the actual possible speed, 
 see http://goo.gl/3O3Tz4 (speedof.me/m), 
 you can say it is good to go.
 

BTW there is another firmware that provides full throughput, as well as the 
complete system crash.

https://wiki.debian.org/rtl819x#Drivers
https://packages.debian.org/firmware-realtek
https://packages.debian.org/sid/firmware-realtek
https://packages.debian.org/sid/all/firmware-realtek/download
http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-realtek_0.43_all.deb


 - lsusb

 Bus 002 Device 003: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 
 802.11n WLAN Adapter

 ~~

 - lsusb -t

 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
 ...
 |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=rtl8192su, 
 480M

 ~~~

 - ethtool -i wlp0s4f1u3

 driver: rtl8192su
 ...

 ~~~

 - /usr/lib

Re: [rt2x00-users] MediaTek Inc. MT7601U Wireless Adapter

[poma]

On 07.10.2014 16:59, poma wrote:
 On 07.10.2014 15:57, John W. Linville wrote:
 You probably shold be sending this to MediaTek.  The driver you are
 using is not part of the upstream Linux kernel.

 John

 
 No problemos!
 
 

BTW, pán Gruszka, when will these devices be supported as a part of the 
upstream Linux kernel?


poma


 On Tue, Oct 07, 2014 at 04:47:11AM +0200, poma wrote:

 BUG: unable to handle kernel paging request at c9000277c070
 IP: [8165272c] __netdev_watchdog_up+0xc/0x80
 PGD 12b01c067 PUD 12b01d067 PMD 1295e8067 PTE 0
 Oops:  [#1] SMP 
 CPU: 3 PID: 1497 Comm: wpa_supplicant Tainted: G   OE  
 3.17.0-1.fc21.x86_64 #1
 task: 88007ec44e80 ti: 8800beddc000 task.ti: 8800beddc000
 RIP: 0010:[8165272c]  [8165272c] 
 __netdev_watchdog_up+0xc/0x80
 RSP: 0018:8800beddfcd8  EFLAGS: 00010202
 RAX: c9000277c000 RBX: 8800caa3c000 RCX: 8800ca22a948
 RDX:  RSI: 0005 RDI: 8800caa3c000
 RBP: 8800beddfce8 R08:  R09: 0208
 R10: 0400 R11: 0010 R12: 
 R13: c9000277c000 R14:  R15: 0001
 FS:  7fce557aa800() GS:88012fcc() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: c9000277c070 CR3: 7eeed000 CR4: 07e0
 Stack:
  816527e8 8800caa3c000 8800beddfd20 a05e4655
  a05e4ab0 a05e4510 5abd5236 8800caa3c000
  1003 8800beddfd58 8163135e 8800caa3c000
 Call Trace:
  [816527e8] ? netif_carrier_on+0x48/0x50
  [a05e4655] MainVirtualIF_open+0x85/0xe0 [mt7601Usta]
  [a05e4ab0] ? RtmpOSIRQRequest+0x60/0x60 [mt7601Usta]
  [a05e4510] ? RT28xx_get_ether_stats+0x150/0x150 [mt7601Usta]
  [8163135e] __dev_open+0xce/0x150
  [8163168d] __dev_change_flags+0x9d/0x160
  [81631779] dev_change_flags+0x29/0x70
  [816a5bac] devinet_ioctl+0x63c/0x710
  [816a6d05] inet_ioctl+0x65/0x90
  [816105d5] sock_do_ioctl+0x25/0x50
  [81610b30] sock_ioctl+0x1f0/0x2c0
  [81220340] do_vfs_ioctl+0x2d0/0x4b0
  [812205a1] SyS_ioctl+0x81/0xa0
  [81135a16] ? __audit_syscall_exit+0x1f6/0x2a0
  [81743469] system_call_fastpath+0x16/0x1b
 Code: 9b 48 a4 ff c6 05 bd 12 6b 00 01 48 8b 45 d8 e9 09 ff ff ff 66 66 2e 
 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 87 e8 01 00 00 48 83 78 70 
 00 74 41 55 48 89 e5 53 48 63 87 c0 03 00 00 85 c0 
 RIP  [8165272c] __netdev_watchdog_up+0xc/0x80
  RSP 8800beddfcd8
 CR2: c9000277c070
 ---[ end trace 97a7adc75a3f40f8 ]---


 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


 

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8188SU(r8712u) - Unable to suspend/resume

[poma]

 is not ready
[ 6811.520143] IPv6: ADDRCONF(NETDEV_UP): wlp0s2f1u4: link is not ready
[ 6811.827149] IPv6: ADDRCONF(NETDEV_UP): wlp0s2f1u4: link is not ready
[ 6832.218387] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s2f1u4: link becomes ready
...


$ nmcli device 
DEVICE  TYPE  STATE  CONNECTION 
wlp0s2f1u4  wifi  connected  sunlight   


$ iwconfig wlp0s2f1u4 
wlp0s2f1u4  IEEE 802.11bgn  ESSID:ap  Nickname:rtl_wifi
  Mode:Managed  Frequency:2.457 GHz  Access Point: 00:11:33:55:77:99   
  Bit Rate:150 Mb/s   Sensitivity:0/0  
  Retry:off   RTS thr:off   Fragment thr:off
  Power Management:off
  Link Quality=90/100  Signal level=47/100  Noise level=0/100
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0


poma


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rt2x00-users] MediaTek Inc. MT7601U Wireless Adapter

[poma]

BUG: unable to handle kernel paging request at c9000277c070
IP: [8165272c] __netdev_watchdog_up+0xc/0x80
PGD 12b01c067 PUD 12b01d067 PMD 1295e8067 PTE 0
Oops:  [#1] SMP 
CPU: 3 PID: 1497 Comm: wpa_supplicant Tainted: G   OE  
3.17.0-1.fc21.x86_64 #1
task: 88007ec44e80 ti: 8800beddc000 task.ti: 8800beddc000
RIP: 0010:[8165272c]  [8165272c] 
__netdev_watchdog_up+0xc/0x80
RSP: 0018:8800beddfcd8  EFLAGS: 00010202
RAX: c9000277c000 RBX: 8800caa3c000 RCX: 8800ca22a948
RDX:  RSI: 0005 RDI: 8800caa3c000
RBP: 8800beddfce8 R08:  R09: 0208
R10: 0400 R11: 0010 R12: 
R13: c9000277c000 R14:  R15: 0001
FS:  7fce557aa800() GS:88012fcc() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: c9000277c070 CR3: 7eeed000 CR4: 07e0
Stack:
 816527e8 8800caa3c000 8800beddfd20 a05e4655
 a05e4ab0 a05e4510 5abd5236 8800caa3c000
 1003 8800beddfd58 8163135e 8800caa3c000
Call Trace:
 [816527e8] ? netif_carrier_on+0x48/0x50
 [a05e4655] MainVirtualIF_open+0x85/0xe0 [mt7601Usta]
 [a05e4ab0] ? RtmpOSIRQRequest+0x60/0x60 [mt7601Usta]
 [a05e4510] ? RT28xx_get_ether_stats+0x150/0x150 [mt7601Usta]
 [8163135e] __dev_open+0xce/0x150
 [8163168d] __dev_change_flags+0x9d/0x160
 [81631779] dev_change_flags+0x29/0x70
 [816a5bac] devinet_ioctl+0x63c/0x710
 [816a6d05] inet_ioctl+0x65/0x90
 [816105d5] sock_do_ioctl+0x25/0x50
 [81610b30] sock_ioctl+0x1f0/0x2c0
 [81220340] do_vfs_ioctl+0x2d0/0x4b0
 [812205a1] SyS_ioctl+0x81/0xa0
 [81135a16] ? __audit_syscall_exit+0x1f6/0x2a0
 [81743469] system_call_fastpath+0x16/0x1b
Code: 9b 48 a4 ff c6 05 bd 12 6b 00 01 48 8b 45 d8 e9 09 ff ff ff 66 66 2e 0f 
1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 87 e8 01 00 00 48 83 78 70 00 74 41 
55 48 89 e5 53 48 63 87 c0 03 00 00 85 c0 
RIP  [8165272c] __netdev_watchdog_up+0xc/0x80
 RSP 8800beddfcd8
CR2: c9000277c070
---[ end trace 97a7adc75a3f40f8 ]---


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTL8188SU(rtl8192su) - unavailable

[poma]

On 29.09.2014 21:46, Dan Williams wrote:
 On Mon, 2014-09-29 at 11:29 +0200, poma wrote:
 [platform/nm-platform.c:806] nm_platform_link_set_up(): link: setting up 
 'wlp0s4f1u1' (4)
 [platform/nm-linux-platform.c:2356] link_change_flags(): link: change 4: 
 flags set 'up' (1)
 [platform/nm-linux-platform.c:2250] link_change(): Netlink error changing 
 link 4:  UP mtu 0 (1) driver 'rtl8192su' udi 
 '/sys/devices/pci:00/:00:04.1/usb2/2-1/2-1:1.0/net/wlp0s4f1u1': No 
 such device
 (wlp0s4f1u1): preparing device
 
 This is likely the core problem, and it's also probably the cause of the
 wpa_supplicant failures too.  You can test this out without NM running
 by simply doing:
 
 ifconfig wlp0s4f1u1 up
 
 and see if it returns an error or not.  Does it?  Does anything show up
 in 'dmesg'?  If we can't get 'ifconfig up' working for the device,
 clearly NM won't work either...
 
 Dan
 

It's OK Dan, NM ain't problem.

WIP encore party

[ cut here ]
WARNING: CPU: 1 PID: 867 at /rtl8192su/rtlwifi/rtl8192s/phy_common.c:1313 
rtl92s_phy_chk_fwcmd_iodone+0x61/0x70 [rtl8192s_common]()
Modules linked in: ... rtl8192su(OE) rtl8192s_common(OE) rtl_usb(OE) 
rtlwifi(OE) mac80211 cfg80211 ...
CPU: 1 PID: 867 Comm: wpa_supplicant Tainted: G   OE  
3.17.0-0.rc7.git0.2.fc21.x86_64 #1
Call Trace:
 [8173c1f1] dump_stack+0x45/0x56
 [81096e9d] warn_slowpath_common+0x7d/0xa0
 [81096fca] warn_slowpath_null+0x1a/0x20
 [a05b3b71] rtl92s_phy_chk_fwcmd_iodone+0x61/0x70 [rtl8192s_common]
 [a05b5871] rtl92s_phy_set_fw_cmd+0x131/0x780 [rtl8192s_common]
 [a05b5efa] rtl92s_phy_scan_operation_backup+0x3a/0x40 
[rtl8192s_common]
 [a043054c] rtl_op_sw_scan_start+0x8c/0xe0 [rtlwifi]
 [a051b63f] __ieee80211_start_scan+0x34f/0x5d0 [mac80211]
 [a051c4a0] ieee80211_request_scan+0x30/0x50 [mac80211]
 [a052b838] ieee80211_scan+0x68/0xc0 [mac80211]
 [a04b7dab] nl80211_trigger_scan+0x5bb/0x640 [cfg80211]
 [816604ac] genl_family_rcv_msg+0x1bc/0x3e0
 [8161cc7b] ? __alloc_skb+0x5b/0x200
 [816606d0] ? genl_family_rcv_msg+0x3e0/0x3e0
 [81660749] genl_rcv_msg+0x79/0xc0
 [8165fd59] netlink_rcv_skb+0xa9/0xd0
 [816602d8] genl_rcv+0x28/0x40
 [8165f37a] netlink_unicast+0x12a/0x1a0
 [8165f741] netlink_sendmsg+0x351/0x7b0
 [8130f9f2] ? sock_has_perm+0x72/0x90
 [816132fe] sock_sendmsg+0x9e/0xe0
 [81612fce] ? move_addr_to_kernel.part.20+0x1e/0x70
 [81613ed1] ? move_addr_to_kernel+0x21/0x30
 [81613768] ___sys_sendmsg+0x3c8/0x3e0
 [810a5e86] ? __set_current_blocked+0x36/0x60
 [8101f67e] ? fpu_finit+0x1e/0x30
 [8101f8e1] ? init_fpu+0x51/0xb0
 [81020b58] ? __restore_xstate_sig+0x268/0x660
 [81013745] ? do_signal+0x1a5/0x6f0
 [81614681] __sys_sendmsg+0x51/0x90
 [816146d2] SyS_sendmsg+0x12/0x20
 [81743369] system_call_fastpath+0x16/0x1b
---[ end trace 561080c39bcc6e50 ]---
[ cut here ]
WARNING: CPU: 2 PID: 81 at /rtl8192su/rtlwifi/rtl8192s/phy_common.c:1313 
rtl92s_phy_chk_fwcmd_iodone+0x61/0x70 [rtl8192s_common]()
CPU: 2 PID: 81 Comm: kworker/u8:6 Tainted: GW  OE  
3.17.0-0.rc7.git0.2.fc21.x86_64 #1
Workqueue: phy0 ieee80211_scan_work [mac80211]
Call Trace:
 [8173c1f1] dump_stack+0x45/0x56
 [81096e9d] warn_slowpath_common+0x7d/0xa0
 [81096fca] warn_slowpath_null+0x1a/0x20
 [a05b3b71] rtl92s_phy_chk_fwcmd_iodone+0x61/0x70 [rtl8192s_common]
 [a05b5871] rtl92s_phy_set_fw_cmd+0x131/0x780 [rtl8192s_common]
 [a05b5eeb] rtl92s_phy_scan_operation_backup+0x2b/0x40 
[rtl8192s_common]
 [a042fd9b] rtl_op_sw_scan_complete+0x6b/0xa0 [rtlwifi]
 [a051b1ba] __ieee80211_scan_completed+0x1ea/0x320 [mac80211]
 [81012691] ? __switch_to+0x191/0x5f0
 [a051c06d] ieee80211_scan_work+0xdd/0x4e0 [mac80211]
 [810af67d] process_one_work+0x14d/0x400
 [810b000b] worker_thread+0x6b/0x4a0
 [810affa0] ? rescuer_thread+0x2a0/0x2a0
 [810b50ea] kthread+0xea/0x100
 [810b5000] ? kthread_create_on_node+0x1a0/0x1a0
 [817432bc] ret_from_fork+0x7c/0xb0
 [810b5000] ? kthread_create_on_node+0x1a0/0x1a0
---[ end trace 561080c39bcc6e51 ]---
[ cut here ]
WARNING: CPU: 2 PID: 867 at /rtl8192su/rtlwifi/rtl8192s/phy_common.c:1313 
rtl92s_phy_chk_fwcmd_iodone+0x61/0x70 [rtl8192s_common]()
CPU: 2 PID: 867 Comm: wpa_supplicant Tainted: GW  OE  
3.17.0-0.rc7.git0.2.fc21.x86_64 #1
Call Trace:
 [8173c1f1] dump_stack+0x45/0x56
 [81096e9d] warn_slowpath_common+0x7d/0xa0
 [81096fca] warn_slowpath_null+0x1a/0x20
 [a05b3b71] rtl92s_phy_chk_fwcmd_iodone+0x61/0x70 [rtl8192s_common]
 [a05b5871] rtl92s_phy_set_fw_cmd+0x131/0x780 [rtl8192s_common]
 [a05b5efa] rtl92s_phy_scan_operation_backup+0x3a/0x40

RTL8188SU(r8712u) - drivers/usb/core/urb.c:339 usb_submit_urb+0x11d/0x5f0()

[poma]

0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter

r8712u: module is from the staging directory, the quality is unknown, you have 
been warned.
r8712u: Staging version
r8712u: register rtl8712_netdev_ops to netdev_ops
usb 2-1: r8712u: USB_SPEED_HIGH with 4 endpoints
usb 2-1: r8712u: Boot from EFUSE: Autoload OK
usb 2-1: r8712u: CustomerID = 0x
usb 2-1: r8712u: MAC Address from efuse = 00:e0:4c:87:00:00
usb 2-1: r8712u: Loading firmware from rtlwifi/rtl8712u.bin
usbcore: registered new interface driver r8712u
r8712u 2-1:1.0 wlp0s4f1u1: renamed from wlan0
systemd-udevd[394]: renamed network interface wlan0 to wlp0s4f1u1

[ cut here ]
WARNING: CPU: 3 PID: 679 at drivers/usb/core/urb.c:339 
usb_submit_urb+0x11d/0x5f0()
URB 8800cb25eb40 submitted while active
Modules linked in: r8712u(C) 
CPU: 3 PID: 679 Comm: NetworkManager Tainted: G C 
3.17.0-0.rc6.git2.1.fc22.x86_64 #1
Call Trace:
 [8173c341] dump_stack+0x45/0x56
 [81096eed] warn_slowpath_common+0x7d/0xa0
 [81096f6c] warn_slowpath_fmt+0x5c/0x80
 [817414f6] ? __down_interruptible+0xa6/0xf0
 [8151f51d] usb_submit_urb+0x11d/0x5f0
 [a047f7f5] r8712_usb_write_mem+0xa5/0xc0 [r8712u]
 [a04801ba] r8712_write_mem+0x1a/0x20 [r8712u]
 [a047de64] rtl8712_hal_init+0x274/0x7e0 [r8712u]
 [a047e510] rtl871x_hal_init+0x40/0x60 [r8712u]
 [a048f91e] netdev_open+0xfe/0x260 [r8712u]
 [8163140e] __dev_open+0xce/0x150
 [8163173d] __dev_change_flags+0x9d/0x160
 [81631829] dev_change_flags+0x29/0x70
 [8163f2b9] do_setlink+0x409/0xb80
 [812027ab] ? mem_cgroup_bad_page_check+0x1b/0x30
 [810cf673] ? find_busiest_group+0x143/0x910
 [813aa7e2] ? nla_parse+0x32/0x120
 [81641a4d] rtnl_newlink+0x61d/0x780
 [8130c748] ? security_capable+0x18/0x20
 [8109f09b] ? ns_capable+0x2b/0x60
 [8163dea1] rtnetlink_rcv_msg+0xa1/0x260
 [811f] ? __kmalloc_node_track_caller+0x191/0x2e0
 [81394fd6] ? rhashtable_lookup_compare+0x36/0x70
 [8163de00] ? rtnetlink_rcv+0x30/0x30
 [8165fea9] netlink_rcv_skb+0xa9/0xd0
 [8163ddf8] rtnetlink_rcv+0x28/0x30
 [8165f4ca] netlink_unicast+0x12a/0x1a0
 [8165f891] netlink_sendmsg+0x351/0x7b0
 [8161344e] sock_sendmsg+0x9e/0xe0
 [8161311e] ? move_addr_to_kernel.part.20+0x1e/0x70
 [81614021] ? move_addr_to_kernel+0x21/0x30
 [816138b8] ___sys_sendmsg+0x3c8/0x3e0
 [8122a685] ? __fget_light+0x25/0x70
 [81613a4d] ? SYSC_sendto+0x17d/0x1c0
 [8122a685] ? __fget_light+0x25/0x70
 [816147d1] __sys_sendmsg+0x51/0x90
 [81614822] SyS_sendmsg+0x12/0x20
 [817434a9] system_call_fastpath+0x16/0x1b
---[ end trace c3332f64cf535dba ]---


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html