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.
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.
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...
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
Hmm.. I'm getting a "No such file or directory" error there..
I suppose it's changed with the plus version. So I guess find it...
sudo find /sys -name rtw_power_mgnt 2> /dev/null
@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.
Well that was unexpected. If it were me, I'd search for just -name *power* this time and see if they renamed it.
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?
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.
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.
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.
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!
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.
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
Okay, so now the big question is "What is admin.lan?" because that's not in your routing table.
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.
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.
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!
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.
- 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.
- 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.
- 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.