Jump to content

wlan0 only works when eth0 plugged in

drscheme

By drscheme
in Beginners

 Share

Recommended Posts

drscheme

drscheme

Posted
Posted

I am having a problem with my network settings. The machine has an internal NIC and a USB-WiFi stick. When the NIC is plugged in, both interfaces receive an IP via DHCP. When the NIC is unplugged, the WiFi stick does not receive an IP address. 

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto wlan0
iface wlan0 inet dhcp
wpa-ssid <name>
wpa-psk <password>

How can I solve this issue?

 

Regards!

Link to comment
Share on other sites
wildcat_paris

wildcat_paris

Posted
Posted

Armbian provides an example with bridge interface for lan/wlan like

auto br0
iface br0 inet static
        bridge_ports eth0 wlan0
        address 192.168.0.254
        netmask 255.255.0.0
        network 192.168.0.0

I guess you can do

auto br0
iface br0 inet dhcp
        bridge_ports eth0 wlan0

br0 takes the MAC adress of the first PHY declared in the bridge_ports (in this example eth0 MAC) for DHCP

I hope it may help

Link to comment
Share on other sites
wildcat_paris

wildcat_paris

Posted
Posted

well... ???

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.x
netmask 255.255.0.0
network 192.168.0.0

auto wlan0
iface wlan0 inet static
wpa-ssid <name>
wpa-psk <password>
address 192.168.0.x
netmask 255.255.0.0
network 192.168.0.0
Link to comment
Share on other sites
liderbug

liderbug

Posted
Posted

I've been fighting wifi on my OPi PC for days now and I've got it working - but only if eth0 if plugged in and I discovered:

On my desktop: 

>arp -a | grep sg5[78]
 sg57 (192.168.0.57) at 12:c8:16:2e:a2:a5 [ether] on p32p1
 sg58 (192.168.0.58) at 12:c8:16:2e:a2:a5 [ether] on p32p1
 

But on my OPiPc ifconfig returns:

eth0      Link encap:Ethernet  HWaddr 12:c8:16:2e:a2:a5  
wlan5     Link encap:Ethernet  HWaddr 00:11:7f:8c:0d:e5  

 

And the Device table on my router shows only the sg57 eth0 mac.  wlan5 is nowhere to be found.

My /etc/network/interface:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.57
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.1
hwaddr 12:c8:16:2e:a2:a5

auto wlan5
iface wlan5 inet static
wep-ssid <ssid>
wep-psk <wep-key>
address 192.168.0.58
netmask 255.255.255.0
network 192.168.0.0
hwaddr 00:11:7f:8c:0d:e5

 

I've even added "hwaddr" to the interface - there's 2 min I'll never get back...

 

Thoughts?

Thanks

bug

Link to comment
Share on other sites
RagnerBG

RagnerBG

Posted
Posted

I also tried to put eth and wlan interfaces in bridge, but this doesn't work, as mentioned. There is not very good solution, but it's something - just comment eth0 sections in etc/network/interfaces and leave only wlan0 active. If you don't plan to use cable connections this is the cleanest solution. Other solution is, if you use Desktop image and have Wicd, to use it to manage wlan interface, instead of if. This way wlan is working separate from eth also, but not very stable.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

I also tried to put eth and wlan interfaces in bridge, but this doesn't work, as mentioned.

 

Sorry, a 'bridge' is implemented on network layer 2. What liderbug is trying to achieve is something different and something I fail to understand. What's the purpose of 2 network interfaces being connected to the same network and only one with an assigned default gateway? Why should Linux send a single packet through wlan5 in this situation?

 

The above is not about bridging, that's just a weird TCP/IP configuration. If liderbug would elaborate on what he's trying to achieve then we might be able to help him.

Link to comment
Share on other sites
liderbug

liderbug

Posted
Posted

Bottom line:  remote wireless webcam (pwr avail but not cat5)

 

My interfaces file says nothing about bridge/bf0 but I get a bridge connection - like it or not.  I just logged on commented out the eth0 section and rebooted.  Now 10 min later ... Unreachable. 

 

When I run: nmap -sU -p 67 --script=broadcast-dhcp-discover <router ip>

I get an IP offered, but when I run dhclient it goes for 255.255.255.255 and times out.  If I run the nmap using 255x4 it times out.  Now I've never been into the dhclient code and this is the first time trying to get wifi working on a OPi PC. 

 

Question:  Is my wlan5 section above correct?  Is something mis-worded?  Should my wep key be in quotes?

 

Thanks

bug

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

My interfaces file says nothing about bridge/bf0 but I get a bridge connection - like it or not. ...  Should my wep key be in quotes?

 

 

WEP in 2016? And bridging claims where everything happens on layer 3? Really?

 

If you've both interfaces enabled can you please post the full output of

traceroute -i wlan5 192.168.0.1
ifconfig
netstat -rn
Link to comment
Share on other sites
liderbug

liderbug

Posted
Posted

traceroute -i wlan5 192.168.0.1

   1 * * *

   ...

  30 * * *

-------------------------------------

ifconfig

eth0      Link encap:Ethernet  HWaddr 12:c8:16:2e:a2:a5
          inet addr:192.168.0.57  Bcast:255.255.0.255  Mask:255.255.255.0
          inet6 addr: fe80::10c8:16ff:fe2e:a2a5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:723 errors:0 dropped:7 overruns:0 frame:0
          TX packets:527 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:65028 (63.5 KiB)  TX bytes:58573 (57.2 KiB)
          Interrupt:114

wlan5     Link encap:Ethernet  HWaddr 00:11:7f:8c:0d:e5
          inet addr:192.168.0.58  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

---------------------------------------------

netstat -rn

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan5

--------------------------------------------

The above if I have wlan5 set to static.  If set to dhcp then no connection

Oh and changed to wpa2-psk

 

<headache>

Link to comment
Share on other sites
RagnerBG

RagnerBG

Posted
Posted

Bottom line:  remote wireless webcam (pwr avail but not cat5)

 

My interfaces file says nothing about bridge/bf0 but I get a bridge connection - like it or not.  I just logged on commented out the eth0 section and rebooted.  Now 10 min later ... Unreachable. 

 

When I run: nmap -sU -p 67 --script=broadcast-dhcp-discover <router ip>

I get an IP offered, but when I run dhclient it goes for 255.255.255.255 and times out.  If I run the nmap using 255x4 it times out.  Now I've never been into the dhclient code and this is the first time trying to get wifi working on a OPi PC. 

 

Question:  Is my wlan5 section above correct?  Is something mis-worded?  Should my wep key be in quotes?

 

Thanks

bug

For what i see, you need gateway in wlan5 section, if you comment eth0 and DNS-es probably. And i doubt you use wep encryption, it's probably wpa/wpa2. For wpa you need to put wpa_passphrase key, instead of plan text key (wpa_passphrase youssid yourpass). I use almost the same config in OPI PC and it's rock stable.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

wlan5     Link encap:Ethernet  HWaddr 00:11:7f:8c:0d:e5

          inet addr:192.168.0.58  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

 

Zero packets received/transmitted since you have two NICs configured to be connected to the same subnet and the kernel preferring the first one. That's not bridging (layer 2) but routing instead (layer 3 and not using wlan5 at all but routing packets through eth0 instead, that's why you see the 'wrong' MAC address using arp).

 

If you comment out the eth0 stuff in 'interfaces' think about adding the gateway address _if_ this board should be able to access the internet (otherwise it's not necessary). Regarding WiFi setup I've no idea but if you get authentication to work and disable eth0 (and therefore solve the routing problem) then it should just work. There's not that much magic involved :)

Link to comment
Share on other sites
liderbug

liderbug

Posted
Posted

OK, here's what I've tried/done.  I was testing via eth0 ssh'ed from my desktop.  I'd try something, my OPi would lock up, I'd have to pull the card, mount to my desktop, edit interfaces or what ever file I had tweeked and reboot - then I notices that last time and in interfaces I had wlan5 and now ifconfig shows wlan9 - no 5.  I do something and reboot and now wlan2  @(*&@#$  So I moved to my TV in the family room - HDMI, booted up, no eth0.  I can run" iwlist scan" and I see every WIFI card in the house, router 1, r2 (bridge in garage), 2 Rokus, my wife's tablet, the refer & microwave in the kitchen - (well maybe that last is a stretch)  But with only the wifi dongle "Cell1" right essid, right chan(6) and tons of other info.  So the dongle is working, it sees my router.  I've tried dhcp and network restart - nada.  I've tried static - nada.  Is it my rtl8192cus and the module has a bug?  Question to someone who has a Orange Pi PC with wireless working - what dongle are you using? 

 

Thanks

 

PS  ADDRCONF(NETDEV_UP): wlan6: link is not ready
 

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

I was testing via eth0 ssh'ed from my desktop.

 

Well, this is something that can't work unless you know exactly how the specific kernel you use deals with routes/interfaces. Since you get a nearly 100% chance to lock yourself out when you change network interface configuration. This is something the serial console or display+keyboard are necessary for.

 

Then regarding 'recommended' WiFi dongles. I've no experiences made on my own (since I would not expect that any of this cheap crap will work reliably and since here in the area 2.4GHz band is so overcrowded that it's absolutely useless to even try it) but people reported that both AR9271 and RT5370 should work (for the former we needed additional firmware and probably a firmware loader patch -- added around ~5.04). No guarantees though.

 

I only dealt once with WiFi in Linux. That happened with Crapboard R1 using crappy onboard RTL8192CU. Maximum distance for successful connections was probably 2 m and the board locked up when WiFi was active over longer time. For me RTL8192CU is the definition of 'can not work' and I really don't get why people expect the opposite.

Link to comment
Share on other sites
rufik

rufik

Posted
Posted

I was also suprised with this eth and wlan dependency on my OPI 2. I started with eth0 auto, then configured wlan0, rebooted without LAN cable and it worked. Wlan is working this way, even with eth0 configured to auto.

But after I plugged in and out cable, I lost wifi until rebooted.

 

I was surprised because I had never such issue on my Alix with Ubuntu 12.04. It looks like Ubuntu is automatically preferring (and setting up) eth over wlan until cable is pulled off.

It would be nice to have same behavior on Armbian. Maybe it could be done using some events listener and scripts?

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

I was surprised because I had never such issue on my Alix with Ubuntu 12.04.

 

That has a simple reason: Ubuntu tries to be a Linux for Desktop users and therefore they added auto configuration stuff that deals with lost links and adjusting automagically things like the default gateway (the same way it's done on other Desktop oriented OSes like OS X or Windows). If you disconnect one link then Ubuntu ignores the stuff the 'admin' has configured, looks for other available links and adjusts the routes on its own.

 

A 'plain Debian' only relies on what has been configured by the admin since the focus is different. So unlike Ubuntu when using Wheezy/Jessie you have to take care what you write into /etc/network/interfaces since this is all that's taken into account. And if you unplug your Ethernet cable and configured two links somewhat strange (pointing to the same and not different subnets) you simply lock out yourself if you disconnect the interface that has been listed with higher priority before.

 

That's one of the reasons we use a separate administration network at customers using a different address range. So even when they use 'el cheapo' servers missing iLOM or the like (to be able to access the OS even if you totally f*cked up networking -- it's some sort of a remote console) you won't lock yourself out.

 

I don't know which component in Ubuntu is responsible (I would suspect it's network-manager) since I still regard 'Linux on Desktop' horribly and especially the brain-dead way to deal with different interfaces is PITA (especially when you compare to OS X where this works flawlessly since 15 years due to configd dealing with this stuff). BTW: No need to discuss Linux behaviour in general. Just read through Debian's/Ubuntu's 'documentation' for interfaces settings: auto vs. allow-hotplug.

Link to comment
Share on other sites
liderbug

liderbug

Posted
Posted

WOOPEEEE! I was pointed to a post

   http://forum.armbian.com/index.php/topic/749-orange-pi-pc-wireless-module-8192cu/

 

and this:

cd /usr/src/linux-headers-3.4.110-sun8i/
make scripts # this you will skip in the future when we fix the building process
cd
git clone https://github.com/pvaret/rtl8192cu-fixes
cd rtl8192cu-fixes
make ARCH=arm
# when done

modprobe -r <any 81xxx entries>
insmod 8192cu.ko
# dmesg
usbcore: registered new interface driver rtl8192cu

and

/etc/udev/rules.d/70-persistent-net.rules gets  "8192cu"

 

Some playing around - hair pulling - dhcp works - and my static 192...58 is there. I'm logged in.

Hey, Igor, Thanks

1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept