User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Loosing IP - no way to connect

Wed Aug 10, 2016 6:43 am

Hi again!

Have here 6 raspi 1B, 2B with identical raspian jessie installations (cloned cards with Windiskimager) normally doing fine, but after some weeks 2 of these might loose there IP (DHCP IPv4 from router with static ARP entries for these MAC adresses). If this happens I loose contact, no VNC no SSH possible (all raspis running headless, so no way at all to enter, I have to pull the power plug to access them again).

Unplugging the ethernet cable does not result in the request of an IP, I checked that in the protocol of the DHCPD running on the router.

Any ideas how to debug this? Any log files in jessie to check?

Maybe the easiest was will be to prepare a new SD-card?

Many thanks in advance!

anazazi
Kind regards

anazazi

User avatar
RaTTuS
Posts: 10498
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 7:24 am

yes leave the offending one with a screen / keyboard attached so you can see what the problem is when it dies /.
the system may have crashed
depends what is running on it
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 7:44 am

Hi!

Thanks for your reply! I don't think that the system crashes completely, e.g. one of these raspis is blinking some LEDs and writing some output to a small LCD display, which works fine even when the IP get's lost.

The raspis are not accessing the network for a longer time, so they don't need the IP for a longer time. Might it be that they "forget" to refresh the lease at some point in time? Is there a (persistent) log for the DHCP daemon on the raspi to see if it "falls asleep" after some time not using the network?
Kind regards

anazazi

User avatar
B.Goode
Posts: 8987
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 8:54 am

pi-anazazi wrote:after some weeks 2 of these might loose there IP (DHCP IPv4 from router with static ARP entries for these MAC adresses).
So which is it - DHCP IPv4 from router OR static ARP entries ?

If you are setting self-assigned static addresses on the RPi, could it be that your router is at some stage assigning those same addresses to some other device? (That would account for your RPi apparently still running but being unavailable over the network.)

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 9:00 am

The raspi is set to DHCP for IPv4, but has a staticARP/reserved IP based on its MAC address at the ROUTER (!) DHCPD configured. IPv6 is completely deactivated on the router, btw.
Kind regards

anazazi

User avatar
B.Goode
Posts: 8987
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 9:03 am

pi-anazazi wrote:The raspi is set to DHCP for IPv4, but has a staticARP/reserved IP based on its MAC address at the ROUTER (!) DHCPD configured. IPv6 is completely deactivated on the router, btw.
Thanks for clarifying: that's the way I like to manage my IP address assignments too.

So could it be that the router is expiring the timeout on the lease of those addresses?

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 9:29 am

With a static ARP entry this should not happen, or?

I see no requests for an IP in the DHCP log on the router, the raspi should request an IP after the lease time is over, or?

Normally I see

Code: Select all

Aug 10 11:11:48	 dhcpd		 DHCPACK on 10.2.3.19 to b8:27:eb:aa:bb:cc via em1
Aug 10 11:11:48	 dhcpd		 DHCPREQUEST for 10.2.3.19 from b8:27:eb:aa:bb:cc via em1
(only after fresh start of clients I see DCHPDISCOVER in the DHCPD log on the router)

According to the router: "The default lease time is 7200 seconds." I have not changed this.
Last edited by pi-anazazi on Wed Aug 10, 2016 9:53 am, edited 2 times in total.
Kind regards

anazazi

User avatar
RaTTuS
Posts: 10498
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 9:37 am

does the DHCP server [router?] give out these static addresses are have you set the static address on the RPI
if the latter then make it static via the router
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 9:51 am

...static via router
Kind regards

anazazi

User avatar
RaTTuS
Posts: 10498
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 11:49 am

attach a screen to the offending device and see what it says when it breaks ...
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 1:13 pm

...means I loose a display for some weeks/months... not so amused...

Maybe some log file for DHCP on the raspi which survived the reboot yesterday? Systemd is not my friend (yet)...
Kind regards

anazazi

User avatar
RaTTuS
Posts: 10498
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 1:33 pm

OK make sure that you can plug a monitor + keyboard in after they have booted and get a response
then unplug and leave the running
then when it fails plug it back in and see.
or look at the logs in /var/log/syslog and see if anything comes to light
it may not be a DHCP issue but may be something else - after a few weeks it is anyones guess - [probably an OOM error in your code but HK]
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Aug 10, 2016 1:38 pm

The second raspi loosing IP does not run any custom code, just pilight and motion with a raspicam. Other raspis with identical SD-cards doing fine...
Kind regards

anazazi

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 2:51 am

Wondering what happened with this case. I'm having a similar problem, 2 pi 3's, one a clone of the other, and they keep dropping/not renewing their DHCP lease for WiFi after a few hours. One also has a wired ethernet connection and that's fine. The inet6 seems to stay on (but I don't use that):

Code: Select all

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:3f:f1:6f
          inet6 addr: fe80::ba27:ebff:fe3f:f16f/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:182435 errors:0 dropped:2 overruns:0 frame:0
          TX packets:203593 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:50488108 (48.1 MiB)  TX bytes:49877790 (47.5 MiB)
When it works there's also a line like:

Code: Select all

inet addr:192.168.43.219  Bcast:192.168.43.255  Mask:255.255.255.0
just above the inet6 line.

I removed wicd (from Synaptic so hopefully properly) because I've had trouble with it on other machines in the past. I just have an interfaces file that looks like:

Code: Select all

auto wlan0
iface wlan0 inet dhcp
  wireless-essid Moto_lte
  allow-hotplug wlan0

[eth0 omitted here]
When I tried doing a dhclient to renew the lease it hung until it timed out, but then I discovered there wasn't any /etc/dhclient.conf file as installed. I'm not sure how it normally gets renewed (I mostly use OpenBSD). I'm connected to an unrooted Android phone so I have little control over what the DHCP server does. I did try keeping another DHCP client machine offline and it still happens, so it isn't running out of leases.

I'll try keeping better records, like grabbing /var/lib/dhcp/dhclient.wlan0.leases after it isn't working any more to see how the timing relates to the lease expiration time. It looks like the expire times are set about 4-5 hours in the future. That's about the time it takes things to not work anymore. Hmm, could be a clock issue but NTP seems to be working.
Last edited by ab1jx on Fri Aug 26, 2016 2:15 pm, edited 2 times in total.

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 5:58 am

Hi!

Currently waiting for the problem to re-occur... ;-)

Note: I only have problems with Raspi 1/2 and LAN. No wifi involved.
Kind regards

anazazi

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 2:38 pm

OK, so it's a DHCP thing probably.

Next morning I checked it at 9:43 and the lease had expired at 8:30. No internet. And a manual dhclient didn't work even with a config file which I think should work (basically which fields to request). The other Pi3 that I cloned this from was still working. I haven't rebooted the non-working machine yet so I can poke around on it.

The problem almost seems related to letting the machine sit idle for a certain length of time, like maybe it goes into some sleep level at which the lease doesn't get renewed? The one that went offline is upstairs, I hadn't touched it in most of 24 hours. This one that's still working I have a VNC connection to over wired ethernet (static IP) and I was on that last night. But it seems like if I didn't use it for a day then I had to reboot it to get the WiFi to work to get it online. My LAN is only local, no gateway.

I'm using 2016-03-18-raspbian-jessie.zip which I last did apt-get update and upgrade on about 2 weeks ago. I find it hard to believe it's been broken all along, I don't have any old versions around to test. I have some 2012 debs from my model B but I don't see an image. Probably wouldn't work on Pi 3 hardware anyway.
Last edited by ab1jx on Fri Aug 26, 2016 2:53 pm, edited 1 time in total.

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 2:44 pm

As I use cloned SDcards for a number of pis (and problem appears only on 2 of them) I had the idea that it might be a problem with the cards.

Maybe try a new card or re-image the card. Best guess... ;-)
Kind regards

anazazi

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 2:59 pm

Ah, a bad SD card socket is what killed my original Pi model B, it was unreliable for years and I was chasing power supply problems trying to find it. But that was with the bigger SD cards, the micro ones seem more reliable.

I'm not going to throw out a card, but since they're cloned I could swap them and see what that does. These are both 128 GB Sandisks. And the newer 3B is where the problem is, it's not over a month old.

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 3:11 pm

...wouldn't throw away anything, just re-image or switch :-)
Kind regards

anazazi

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: Loosing IP - no way to connect

Fri Aug 26, 2016 4:28 pm

Hmm, I just tried dhclient wlan0 on the machine that's working and got the error "RTNETLINK answers: File exists". When I tried that on the one that's not working it just hung for about a minute and then timed out apparently, silently dropped back to a command prompt.

I wanted to explore the possibility of changing the lease duration to see if that also affects how long it has to sit to cause the problem. But I'm more used to BSD, which would probably just reuse the old address if it couldn't get a new lease.

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: Loosing IP - no way to connect

Sat Aug 27, 2016 1:48 pm

OK, I looked at it a bit while it was down. It seems to be maybe lower level than DHCP? I'm used to ifconfig and wlan0's ipv4 entry dropped out of what shows in ifconfig. So I ifconfiged it back to the IP it normally gets assigned by DHCP and tried to ping the DHCP server's IP address, nothing. But I'm connected through the same DHCP server (wifi AP) from another machine to send this.

Code: Select all

Manually did ifconfig to set wlan0 to its usual IP

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:3f:f1:6f  
          inet addr:192.168.43.219  Bcast:192.168.43.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:fe3f:f16f/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:67228 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26937 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:53716924 (51.2 MiB)  TX bytes:3377837 (3.2 MiB)

[email protected]:/usr# ifconfig wlan0 up
[email protected]:/usr# ping 192.168.43.1   [my DHCP server]
PING 192.168.43.1 (192.168.43.1) 56(84) bytes of data.
From 192.168.43.219 icmp_seq=1 Destination Host Unreachable
From 192.168.43.219 icmp_seq=2 Destination Host Unreachable
From 192.168.43.219 icmp_seq=3 Destination Host Unreachable
^C

rfkill list:
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
I didn't think to look at the routing table. The leases file, on 8/27, looks like it hasn't gotten a lease since 8/26:

Code: Select all

lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1635;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2985;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 08:30:01;
  rebind 5 2016/08/26 08:58:01;
  expire 5 2016/08/26 09:08:16;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1604;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2954;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 08:53:26;
  rebind 5 2016/08/26 09:19:15;
  expire 5 2016/08/26 09:30:01;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1651;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 3001;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 09:18:18;
  rebind 5 2016/08/26 09:43:27;
  expire 5 2016/08/26 09:53:26;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1683;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 3033;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 09:44:15;
  rebind 5 2016/08/26 10:08:51;
  expire 5 2016/08/26 10:18:18;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1643;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2993;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 10:09:50;
  rebind 5 2016/08/26 10:34:08;
  expire 5 2016/08/26 10:44:15;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1668;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 3018;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 10:31:15;
  rebind 5 2016/08/26 11:00:08;
  expire 5 2016/08/26 11:09:50;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1599;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2949;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 10:54:21;
  rebind 5 2016/08/26 11:20:24;
  expire 5 2016/08/26 11:31:15;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1629;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2979;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 11:19:45;
  rebind 5 2016/08/26 11:44:00;
  expire 5 2016/08/26 11:54:21;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1585;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2935;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 11:39:54;
  rebind 5 2016/08/26 12:08:40;
  expire 5 2016/08/26 12:19:45;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1655;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 3005;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 12:06:18;
  rebind 5 2016/08/26 12:29:59;
  expire 5 2016/08/26 12:39:54;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1668;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 3018;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 12:31:54;
  rebind 5 2016/08/26 12:56:36;
  expire 5 2016/08/26 13:06:18;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1578;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2928;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 12:56:40;
  rebind 5 2016/08/26 13:20:42;
  expire 5 2016/08/26 13:31:54;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1735;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 3085;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 13:21:09;
  rebind 5 2016/08/26 13:48:05;
  expire 5 2016/08/26 13:56:40;
}
lease {
  interface "wlan0";
  fixed-address 192.168.43.219;
  option subnet-mask 255.255.255.0;
  option routers 192.168.43.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.43.1;
  option dhcp-server-identifier 192.168.43.1;
  option dhcp-renewal-time 1632;
  option broadcast-address 192.168.43.255;
  option dhcp-rebinding-time 2982;
  option vendor-encapsulated-options "ANDROID_METERED";
  option host-name "raspberrypi2";
  renew 5 2016/08/26 13:44:53;
  rebind 5 2016/08/26 14:10:51;
  expire 5 2016/08/26 14:21:09;
}
iw list shows probably standard stuff:

Code: Select all

Wiphy phy0
	max # scan SSIDs: 10
	max scan IEs length: 2048 bytes
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports roaming.
	Device supports T-DLS.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP (00-0f-ac:4)
		* CMAC (00-0f-ac:6)
	Available Antennas: TX 0 RX 0
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * P2P-client
		 * P2P-GO
		 * P2P-device
	Band 1:
		Capabilities: 0x1020
			HT20
			Static SM Power Save
			RX HT20 SGI
			No RX STBC
			Max AMSDU length: 3839 bytes
			DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: 16 usec (0x07)
		HT TX/RX MCS rate indexes supported: 0-7
		Bitrates (non-HT):
			* 1.0 Mbps
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (disabled)
			* 2472 MHz [13] (disabled)
			* 2484 MHz [14] (disabled)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * join_ibss
		 * set_pmksa
		 * del_pmksa
		 * flush_pmksa
		 * remain_on_channel
		 * frame
		 * set_channel
		 * tdls_oper
		 * start_sched_scan
		 * start_p2p_device
		 * crit_protocol_start
		 * crit_protocol_stop
		 * connect
		 * disconnect
	Supported TX frame types:
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * managed: 0x40 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	software interface modes (can always be added):
	valid interface combinations:
		 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
		   total <= 3, #channels <= 2
		 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
		   total <= 4, #channels <= 1
	Device supports scan flush.
I'm not used to iw, OpenBSD does everything through ifconfig, Linux network stuff is "weird" in other ways too, especially concerning wifi. So I rebooted, tarred up my notes, and sent them off to another machine over the wifi that wasn't working until the reboot.

Trying to renew the lease using dhclient or dhcpcd just showed that they couldn't connect to anything. Manually assigning an IP address and trying to ping the DHCP server should have worked, it's almost like the wlan0 device gets disabled somehow. And it seems related to how long it's been since it was used, like something's putting it to sleep to save power maybe. Yet I can list its capabilities with iw list and still have it not work afterward.

I got to thinking, this is almost the sort of timeframe (some number of hours of no user interaction) when you might want things to happen like spinning down hard drive motors if there were any. What if something's getting put to sleep but the hook to wake it back up is broken or missing? So I was wondering how many APM/ACPI states there are. But typing apm shows the kernel was compiled without APM support, which could be good or bad. I can understand leaving it out because there's no battery but if something somewhere makes the assumption that it's enabled that could be bad.

I was trying to get my monitor backlight to turn off so I was xsetting some DPMS stuff in my xinitrc. Didn't work but I hadn't taken it back out until now, which confuses things so I need to wait X hours again. But I did notice at the end of my dmesg after it fails there's a section that's not in the dmesg when it first boots about WiFi. I don't know what the numbers on the left side of the line are, timestamps by the looks. What happens at boot ends by 50.0, the 5000+ is more recent, maybe in the timeframe of the problem. I don't see much happening, but something's trying to reinitialize the WiFi 94 minutes after boot and it evidently fails because the WiFi doesn't work. There's a similar block at about 5.078043 which works.

Code: Select all

[   19.578563] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   19.578576] Bluetooth: BNEP filters: protocol multicast
[   19.578590] Bluetooth: BNEP socket layer initialized
[   48.139123] Bluetooth: RFCOMM TTY layer initialized
[   48.139154] Bluetooth: RFCOMM socket layer initialized
[   48.139171] Bluetooth: RFCOMM ver 1.11
[ 5650.926288] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[ 5650.926309] cfg80211: World regulatory domain updated:
[ 5650.926314] cfg80211:  DFS Master region: unset
[ 5650.926320] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gai
[ 5650.926328] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 m
[ 5650.926334] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 m
[ 5650.926340] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 m
[ 5650.926348] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AU
[ 5650.926355] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AU
[ 5650.926362] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000
[ 5650.926368] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 m
[ 5650.926374] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0
So, anazazi, what's the uptime on your problem machines now? I'd use static IPs, I'm only using DHCP because I can't change that in Android 5.02. 4.4 I think you could but that phone died.

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Sep 07, 2016 10:30 am

Hi again!

Some days ago one of my raspi 1A with raspian jessie (light with desktop)) lost its IP again. Made a strange IP request at the routers DHCP server, obtained its reserved IP (based on MAC), but later on never refreshed the lease and became unresponsive. However, phyton scripts on the machin were up and running.

As I plugged the HDMI into the monitor and connected the keyboard/mouse, the raspi rebooted automagically and came back with his refreshed IP address.

So apparently I can not find any reason for this strange behavior, as the machine won't let me examine any data in this strange, IP-less mode it switches to from time to time...
Kind regards

anazazi

swampdog
Posts: 266
Joined: Fri Dec 04, 2015 11:22 am

Re: Loosing IP - no way to connect

Wed Sep 07, 2016 12:43 pm

You might want to get one of those usb serial cables.

User avatar
pi-anazazi
Posts: 559
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Loosing IP - no way to connect

Wed Sep 07, 2016 4:14 pm

...bought one just some days ago, will have to install and get it up and running ;-)

In the meantime I cloned the SDcard to see if something get's better.
Kind regards

anazazi

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: Loosing IP - no way to connect

Wed Sep 14, 2016 9:38 pm

Mine hasn't fixed itself either. I wish I knew what to check but Linux networking is, um, unique for lack of a more polite word. Rebooted it this morning, now I can't ping it again. I've seen it happen a couple times on the Pi I cloned this one from, but much less often. That machine also has a wired ethernet connection which I use a few times a day, like I mostly keep a VNC session open to it, but that's static, not DHCP (and always works). It's almost like having the wired one keeps the leases refreshing somehow. And I still don't know if not renewing leases is the problem or a symptom, like it can't renew because it loses connection. And it looks to only affect IPv4, which is what I use.

From my notes this morning on it:
Haven't been on here in a few days, rfkill isn't the problem.

Date is the 14th, lease file (in /var/lib/dhcp) is dated the 10th, the rebind
and expire times are just after midnight (the 11th).

ifquery wlan0
wireless-essid: Moto_lte

ifup wlan0
ifup: interface wlan0 already configured

ifconfig shows it's up:

wlan0 Link encap:Ethernet HWaddr b8:27:eb:3f:f1:6f
inet6 addr: fe80::ba27:ebff:fe3f:f16f/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:36270 errors:0 dropped:1 overruns:0 frame:0
TX packets:13626 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17128429 (16.3 MiB) TX bytes:2670097 (2.5 MiB)

But it only seems to have an inet6 lease

arp -v -i wlan0
Entries: 0 Skipped: 0 Found: 0
arp: in 0 entries no match found.
[didn't RTFM on arp much]
It's not related to my trying to make the monitor go to sleep, I took that back out. Maybe I'll try putting a cron job on it that pings something once a minute (-c 1) as a keep-alive. Nope, that didn't do any good (assuming it was working), about 2 hours later I can't ping it again.

What's a USB-serial got to do with it? I have a couple (Prolific) around, not using one on either Pi.

This thread seems related: viewtopic.php?t=72282&p=521088
about the only thing I can do along those lines is add
send dhcp-lease-time (n seconds);
to my /etc/dhclient.conf

I did "officially" switch from dhcpcd to dhclient using update alternatives. They both have the same problem.

I Googled
debian "lease not renewing"
and it's not just Pis, but I haven't figured out how the renewal is supposed to work. I've got an OpenBSD machine, an Android phone, and a couple of Kindles running off the same DHCP server (an Android phone) but I only see problems on the Pis. But actually a flaky laptop running amd64 Debian can't get a lease at all, which I think is a different problem.

Return to “Troubleshooting”