OctoPi WiFi/network connection troubleshooting megatopic

troubleshooting
wifi

#202

Interesting. So is this a Raspberry Pi 3B+ (emphasis on the plus)? Maybe this is the standard freeze-up.

If so, I think I'd recommend to update the Raspbian firmware:

sudo apt-get update
sudo apt-get -y upgrade
# Brew some tea

It's possible that the wifi adapter is trying to save energy and to go to sleep. Since the Raspberry Pi's computer-on-a-chip includes the Broadcom variety of networking and this is known to have ugly state-management for sleep modes, the firmware upgrade might help if this is the cause.


#203

Correct yes it is a 3B+

This actually sounds like exactly what may be happening. I'll give this a try as well as assigning an IP. Thank you - I'll update you when I know more.


#204

Hey @OutsourcedGuru.

Tried both.. looks like unsuccessful. Wifi still went into this "sleep" like mode somewhere between 3.5 - 5 hours into the first print...


#205

cat /sys/module/8192cu/parameters/rtw_power_mgnt
...should tell you how the wifi sleep is currently set. I think that a value of one means that it's on. In theory, any Raspbian version that's new should have power management for the embedded wifi turned off from what I understand.

It's supposed to be zero but from what you've suggested, it might be one.

Read this


#206

Hmm.. I'm getting a "No such file or directory" error there..


#207

I suppose it's changed with the plus version. So I guess find it...

sudo find /sys -name rtw_power_mgnt 2> /dev/null

#208

@OutsourcedGuru -

There was no results. At least - a new line was just made, no details were given on if successful/location or if there was no result.


#209

Well that was unexpected. If it were me, I'd search for just -name *power* this time and see if they renamed it.


#210

So looking in modules to lessen that list I do see:
/sys/module/workqueue/parameters/power_efficient

Running cat - the value is set to "N" is this expected/should I toggle?


#211

Nope. Color me "clueless" on this then. You'd think that they would keep the device tree and such somewhat consistent. If you upgraded the firmware then this isn't supposed to sleep on the network side of things; I'm stumped.


#212

Well rip. lol.

Thanks for the many tries though - I'll keep looking around. Sounds like we at least discovered it's probably not the octo side of things, so maybe I'll navigate over to the pi boards and see what someone may know over there.


#213

Keep looking within the configuration space of your wifi card going to sleep. Look at work-arounds like plugging it into Ethernet or swapping it out for a Raspberry Pi 3B.


#214

Help! Going crazy here! I'm able to connect to wifi ONLY if I'm connecting through the ethernet port.
Using RB Pi B+ with octopi 0.15.1.
I can see my network (connecting via PUTTY):

   Cell 06 - Address: E4:71:85:30:4B:45
                    Channel:9
                    Frequency:2.452 GHz (Channel 9)
                    Quality=70/70  Signal level=-11 dBm
                    Encryption key:on
                    ESSID:"MY WIFI"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s
                    Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=0000000000000000
                    Extra: Last beacon: 0ms ago
                    IE: Unknown: 000B73616C616D65726F313137
                    IE: Unknown: 010882848B960C121824
                    IE: Unknown: 030109
                    IE: Unknown: 050400010000
                    IE: Unknown: 0706555320010B1E
                    IE: Unknown: 2A0100
                    IE: Unknown: 32043048606C
                    IE: Unknown: 2D1AAD011BFFFFFF0000000000000000000100000000040                                                                                                                                                             6E6470D00
                    IE: Unknown: 3D160908040000000000000000000000000000000000000                                                                                                                                                             0
                    IE: Unknown: 4A0E14000A002C01C800140005001900
                    IE: Unknown: 7F080100000000000040
                    IE: Unknown: DD180050F2020101800003A4000027A4000042435E00623                                                                                                                                                             22F00
                    IE: Unknown: DD0900037F01010000FF7F
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK

When a run ifconfig I get:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.101  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::ce9a:3397:c048:217a  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8f:6b:77  txqueuelen 1000  (Ethernet)
        RX packets 117931  bytes 29482189 (28.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32747  bytes 11676160 (11.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 66594  bytes 15632225 (14.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 66594  bytes 15632225 (14.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.139  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::aae:54ea:be8a:d3df  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:da:3e:22  txqueuelen 1000  (Ethernet)
        RX packets 137257  bytes 36061032 (34.3 MiB)
        RX errors 0  dropped 33  overruns 0  frame 0
        TX packets 27422  bytes 8421929 (8.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I can connect to my pi using both the ethernet & wifi ip addresses (10.10.10.101 & 10.10.10.139). The moment I unplug the ethernet cable, it all goes away! Confirmed using Angry IP. Don't know what else to do. HELP PLEASE!


#215

I took the liberty of editing your post to mark the code sections. It's that button which looks like this </> in case you're wondering.

Both your eth0 and wlan0 devices include a RUNNING flag as well as an IPv4 IP address. Looks like both fall into the 10.10.10.x/24 network space.

If you can PuTTY to either bound IP address but you can't connect to the 10.10.10.139 when the Ethernet cable is unplugged then I'd guess that there's no default route in that case; the Pi doesn't know where to send the packets back to you.

Here on my Raspi3B, I'm running a route command without an Ethernet adapter connected. The "G" flag indicates that this is a default route for me and it will go via the device which is bound to wlan0 and is directed to my router at 10.20.30.1 in this case.

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.20.30.1      0.0.0.0         UG    303    0        0 wlan0
10.20.30.0      0.0.0.0         255.255.255.0   U     303    0        0 wlan0

I now plug in an Ethernet cable and run route again. Let's see how it's different this time.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.20.30.1      0.0.0.0         UG    202    0        0 eth0
default         10.20.30.1      0.0.0.0         UG    303    0        0 wlan0
10.20.30.0      0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.20.30.0      0.0.0.0         255.255.255.0   U     303    0        0 wlan0

It now has two default routes, one for each device. It's important to note that each has a metric which means that the Ethernet adapter in my case will get priority over the wi-fi card.

If your Pi behaves differently then it's probably something to do with your configuration or how your router is setup. Note that you can plug in a keyboard/mouse/monitor to the Pi temporarily to see what's going on.


#216

Hi OutsourcedGuru,

I ran the route command and get something very similar to what you have:


Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         admin.lan       0.0.0.0         UG    202    0        0 eth0
default         admin.lan       0.0.0.0         UG    303    0        0 wlan0
10.10.10.0      0.0.0.0         255.255.255.0   U     202    0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     303    0        0 wlan0


#217

Okay, so now the big question is "What is admin.lan?" because that's not in your routing table.


#218

Right so I scanned with ANGRY Scanner and admin.lan has a different ip address (ending in .254) so I tried to connect to it using PUTTY. Got through the log in request but did not accept my password (access denied). Checked my router DHCP leases and that ip address is NOT listed.


#219

In theory, 10.10.10.254 represents both inward-facing network adapters in your router. Hopefully the same IP address is bound to your router's wi-fi and Ethernet devices for this setup, otherwise it's not configured correctly.


#220

I'm a new to all this so I really need some direction on what to. 10.10.10.254 is my router's ip address. Don't know what to do. Please help!


#221

Plug a keyboard/monitor/mouse into your Raspberry Pi. Disconnect the Ethernet cable. Boot it up and login.

Run ifconfig. Run route. Run ping 10.10.10.254 and note what you see in each case.

  1. The output from the first command should include the flag RUNNING if it has successfully connected to your wi-fi zone. That's a good sign. You should also see an IPv4 IP address that's something like 10.10.10.139 or similar. At this point, from your own workstation you would, in this case, run ping 10.10.10.139 to see if you can reach it.
  2. The output from that second command above tells you if the routing table is happy. The Raspberry Pi needs a "default gateway" (the place to send packets if the Pi doesn't otherwise recognize the IP address as being nearby). That gateway should be your router's IP address.
  3. The output from that third command should tell you if the Pi can see the default gateway (your router). It's good if that works.