Hi! Some general question + Wifi USB Realtek RTL8191S

[fvdw]

can you give a summary from what now still is the problem. I am a little lost

[fvdw]

I finally found out why the staging driver in the linux kernel did not load. It needs a script and rule for udev to insert the firmware.
I have got that working now and the driver as present in the linux kernel now loads and runs. So we can try that also on your system

Code: Select all

[  527.056802] Register Driver 'r8712u'
[  527.060555] r8712u: Staging version
[  527.065792] r8712u: register rtl8712_netdev_ops to netdev_ops
[  527.071538] usb 1-1: r8712u: USB_SPEED_HIGH with 4 endpoints
[  527.078059] usb 1-1: r8712u: Boot from EFUSE: Autoload OK
[  527.877687] usb 1-1: r8712u: CustomerID = 0x0000
[  527.882322] usb 1-1: r8712u: MAC Address from efuse = 64:d1:a3:18:e5:cd
[  527.888912] usb 1-1: r8712u: Loading firmware from "rtl8712u.bin"
[  527.895020] rc=0
[  527.905638] usbcore: registered new interface driver r8712u
[  592.407695] r8712u 1-1:1.0 wlan0: 1 RCR=0x153f00e
[  592.413180] r8712u 1-1:1.0 wlan0: 2 RCR=0x553f00e
[  592.527511] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  864.849026] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready


:mrgreen:

need to write things together

[matzi]

The summary is:
wlan0 and eth0 properly receive IPs and both show connectivity when the webinterface is called through the IPs. Scanning the IPs by external port scanner shows both IP and suitable open ports on both IPs. Surprisingly both IPs show the same MAC Adresses - the one of the eth0 interface. As soon as the LAN cable is disconnected the situation changes: eth0 loses IP obviously, scanning externally wlan0 shows it still has its IP but all ports on this IP are closed. MAC is the expected MAC of the wireless interface. The webinterface cannot be opened through the wlan0 IP.

For unknown reason this the behavior on my device nwsp2 even with two different kinds of wlan dongles, while it is different on your two devices 5big2 and nwsp2.

:thumbup Great you found an issue with the staging driver. What can I do to try it?

[fvdw]

Hi Matzi

Case 1
I executed your procedure on my nwsp2 and indeed when having lan cable connected the nmap scan gives the same mac for both ip's, the one of eth0
But both ip's work and give access to the web interface.
nmap scan on both ip's give mac of eth0 and a list of open port as it should.
Now when unplugging the LAN cable I loose connection via wlan ip, and nmap scan shows the mac address of wlan0 but indeed no open ports. In this situation I cannot connect via wlan0 ip to the webinterface. If I restore the lan cable connection I can connect again on eth0 and wlan0 ip.
So same as your behavior

Case 2
But when doing a boot with the LAN cable disconnected the wlan0 interface comes up fine and I can connect via webinterface using the wlan ip.
ps it takes a while before the login prompt appears.
Now the nmap scan gives the mac of the wlan dongle and shows all the active ports
when I plug in the lan cable in this situation I can connect to the webinterface using ip of eth0, but it takes a while to open (longer then in case 1, similar to wlan0 in this case..). nmap scan of ip eth0 gives mac of eth0. Scanning ip of wlan0 now gives also mac address of eth0 for wlan0 ip.
Now disconnection lan cable again. I now can still connect to wlan0 ip (takes a while before it connects). nmap scan gives now mac of wlan0 and all available ports

So it seems to be related to which mac makes contact to the router first. I don't know if this is normal behavior. You would expect that if one adpater fails that the other takes over. But it seems Linux requires some extra setup to use two adapters at same time.
Anyhow when using only a wlan dongle and case 2, the wlan connection works fine

[Jocko]

Hi both,

As writing previously, for the case 1, we need to update the route table...

Case 2 works fine because wlan0 is bring up and route table uses the wireless NIC...

@fvdw
Case 1 before unplugging the network cable what is the route table value.
For testing, you can try to make a shell script to update the table (remove lines with eth0) and use cron to perform it after unplugging the network cable.

[fvdw]

this is routing table for case 1

Code: Select all

root@nwsp2-lite:/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0


for case 2 it is this

Code: Select all

root@nwsp2-lite:/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
root@nwsp2-lite:/ #

but after plugging in the LAN cable it becomes this

Code: Select all

root@nwsp2-lite:/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
root@nwsp2-lite:/ #


(notice that order of eth0 and wlan0 is different compared with case 1)

[Jocko]

Unplug the network cable doesn't bring down eth0, and so eth0 routes are falsely available.

(notice that order of eth0 and wlan0 is different compared with case 1)

it's why in this case 2 (after plugging the network cable), it still works fine because from your lan, the both local routes (192.168.1.0/24) are available.

in the case 1 (after unplugging the network cable), the first local routes is no longer available and the system doesn't select the 2d route because eth0 seems always available (not bring down).

[matzi]

Is there possibility to react to "Hot Unplugging" by a script? Like If eth0=unplugged then iwconfig eth0 down, and vice versa.

[Jocko]

Yes, you can do this.

I did this with my USB lan adapter by using a udev rule (see my previous posts) :whistle

So create a file 70-udev.rules in the folder /etc/udev/rules.d (save your file because it will be deleted after each firmware upgrading)
add these two rules

Code: Select all

BUS=="usb", SUBSYSTEM=="net", KERNEL=="wlan0", ACTION=="add", RUN="/fullpath-to/shellscript-bringupwlan0.sh"
BUS=="usb", SUBSYSTEM=="net", KERNEL=="wlan0", ACTION=="remove", RUN="/fullpath-to/shellscript-bringdownlan0.sh"

these rules will be run when the NAS start if your wlan adapter is already plug (cold-plug) or when you plug or unplug the adapter (hot-plug)

So write now your shell scripts where :
- shellscript-bringupwlan0.sh bring down eth0 if wlan0 is rightly configured (and if you want, it also can set the wlan0 interface at booting)
- shellscript-bringdownlan0.sh bring down wlan0 and bring up eth0.

Note: when you bring up again eth0, the default route will be missing and so you must add it

Code: Select all

/sbin/route add default gw 192.168.1.1 dev eth0

(if 192.168.1.1 is your gateway)
Note2: in your shell script, you must use the command with their full path (e.g. /sbin/route) because the PATH environment variable is not available.

This trick doesn't handle the unplug/plug network cable events but only unplug/plug wireless adapter events

[matzi]

Is there a package with udevadm ?
From what I read, it seems possible to catch also events on eth0.