0

I have a system that run 24/7 on raspberry. Eventually, I have to change the raspberry and the OS (Operational System, the rpi Image, um fact) of it. My last update was to change the OS to the last raspbian buster. Since then, sometimes it's stay unreachable for some devices in my network. From my computer, that I use configure it frequently, I can connect to it normally. But if a device (my cellphone, for example) goes out for 1 day without access it, the raspberry became unreachable from the device.

Some of behaviors of the problem:

  • If I ping the device from raspberry, it's get back to work (only the device, other devices still cannot connect). If I ping the raspberry from device, it get "Address unreachable".
  • If I reboot the rpi, it's get back to work to all devices in network.
  • The problem only occurs in wifi. In Ethernet it's works fine.

I know it's seens like a network problem, but I didn't have this problem before the OS update. I already disabled the power management for wifi and ran "sudo apt-get upgrate" to try to solve it, but it's keep happening.

So, anything changed in the wifi driver in this last raspbian? Can I do anything to avoid this error? Is I making something wrong?

Update with info from a comment:
I downloaded the image from the raspbery site, but I do an apt-get upgrade recently. I have an web server on it, and a program (written in C) that do some extra stuffs. And It have some circuit with It, with a 433 mhz radio. I use a RPI 3B+ now ( before, I used a RPI 3B, and I didnt have this issue).

Edit

Output From ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:2a:fc:80 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:7f:a9:d5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.199/24 brd 192.168.0.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 2804:14c:5989:96aa::1001/128 scope global dynamic noprefixroute 
       valid_lft 85891sec preferred_lft 85891sec
    inet6 2804:14c:5989:96aa:b90b:dbe1:70b7:f25c/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86397sec preferred_lft 71997sec
    inet6 fe80::10b5:7385:8d56:50b7/64 scope link 
       valid_lft forever preferred_lft forever

Output from ip route

default via 192.168.0.1 dev wlan0 src 192.168.0.199 metric 303 
192.168.0.0/24 dev wlan0 proto dhcp scope link src 192.168.0.199 metric 303 
  • What is SO? "My last update was to change the SO to the last raspbian buster": what does it mean? Did you installed Buster from scratch from its image, or did you do an apt full-upgrade from Raspbian Stretch? Your problem is seen with incomplete arp resolution but the reason is unclear so far. – Ingo Dec 18 '19 at 8:47
  • Did you just enabled WiFi from the default image or are there other interfaces, connections, server, etc. installed? What Raspberry Pi model do you use? An RPi 4B? – Ingo Dec 18 '19 at 8:54
  • SO means for OS, it's a typo, sorry. I downloaded the image from the raspbery site, but I do an apt-get upgrade recently. I have an web server on it, and a program (written in C) that do some extra stuffs. And It have some circuit with It, with a 433 mhz radio. I use a RPI 3B+ now ( before, I used a RPI 3B, and I didnt have this issue) – Thiago Trindade Dec 19 '19 at 9:49
  • Hm... just to get a bit more overview: can you please edit your question and add the output from ip addr and ip route to it? There is an important difference between RPi 3B and 3B+. The latter has another WiFi on-board chip supporting the 5 GHz band now. If you ping the device from the RasPi, then you can "backping" the RasPi from the device. If you wait a bit more than 5 min (e.g. 6 min) then the RasPi does not response. Can you please verify this timeout of 5 min? – Ingo Dec 19 '19 at 21:13
  • Edited. The timeout for the pi don't respond is bigger, usually a couple of hours – Thiago Trindade Dec 20 '19 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.