[SOLVED] Obtaining a new IP address from my ISP

taylorkh · 04-27-2018, 03:00 PM

I have a DSL account with a dynamic IP address. For several years I ran my DSL modem in transparent bridging mode and picked up my Internet IP address on an ancient Netgear router. Using the web interface to the router I could issue release and renew commands to the ISP's DHCP server and obtain a new address. (Why I did this every day is an interesting story but beyond the scope of this post.)

For no apparent reason, and nothing which the ISP's "support" folks could explain, this quit working. I had to do a release and then reboot the router. That gave me a new address.

For my next trick I replaced the ancient router with a CentOS 7 box with two NICs. One for the Internet side and the other "shared to other computers" for the LAN side. I setup a firewall, dhcpd (which was somewhat superfluous), a shared vpn etc. Works great. I could get a new Internet IP by executing this script

Code:

#!/bin/bash
sudo dhclient -v -r p1p2
sudo ifdown p1p2
sudo ifup p1p2

That worked for a while and then mysteriously quit working. I could not loose the old address.

Earlier this week I spent more than an hour on the phone with "support." They could not explain it but "second level support" eventually disconnected the old IP address from me. What they did they would not tell first level support so I have no idea. I am now stuck with the new address which I obtained after the earlier one was manually separated from me.

I have now replaced the CentOS box with a Raspberry Pi runing Ubuntu Mate 16.04. It performs the same functions. Again I cannot obtain a new address by issuing a release and then cycling the interface down and up. However...

Considering the fact that I had to reboot the router after the release, I tried the same thing with the Pi. Presto - a new address

I run the Pi headless with no gui so it only takes seconds to ssh to it and issue my new_ip.sh script. The Pi reboots quickly so my "problem" is mitigated. Still, I want to understand what is going on.

It seems to me that the Pi or the CentOS box or the Netgear router somehow remembered the Internet IP address and would not forget it until a reboot. On the other hand, if I spoofed the MAC address on the device and performed the release/renew I DID get a new address. This would seem to point to the DHCP server remembering me even after I told it to release the address and give it to someone else.

Does anyone have any ideas what is going on???

TIA,

Ken

frankbell · 04-27-2018, 08:24 PM

Many ISP's use "sticky" ip addresses. That may be what's happening here.

taylorkh · 04-27-2018, 08:50 PM

Thanks frankbell,

If I power off or otherwise disconnect the device which has the IP address I would expect the same address upon re-conection provided I was within the lease period. And I do. If I read this correctly

Code:

ken@taylor23:~$ ip addr show enxb827ebd88666
2: enxb827ebd88666: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:d8:86:66 brd ff:ff:ff:ff:ff:ff
    inet 71.48.4.120/21 brd 71.48.7.255 scope global dynamic enxb827ebd88666
       valid_lft 858sec preferred_lft 858sec
    inet6 fe80::7a6b:8a52:a2b4:2f9/64 scope link 
       valid_lft forever preferred_lft forever

the IPV4 lease time is ~ 15 minutes. During one experiment I issued a release and then went off to do something else. I came back about a half hour later and cycled the interface. I received the same address.

Something is stuck. Not sure if it is intentional or a misconfiguration somewhere. I think that release should RELEASE. I may call the ISP and ask what they think the lease time should be.

Ken

rknichols · 04-28-2018, 10:38 AM

Try deleting the .leases file in /var/lib/dhclient. That's where your box is remembering the old address and may be requesting that same address for the new connection. Your ISP may also be remembering the last IP address assigned to your device's MAC address, so you might have to spoof a new MAC address and delete the lease file to get a new address.

taylorkh · 04-28-2018, 12:32 PM

Thanks rknichols,

Unfortunately NetworkManager is in the middle of all this and nothing seems to be in its normal place. I found one .leases file

Code:

ken@taylor23:/var/lib/NetworkManager$ cat dhclient-acbadb58-4f3b-37a1-a526-3fba92e35693-enxb827ebb4a62e.lease
lease {
  interface "enxb827ebb4a62e";
  fixed-address 192.168.0.102;
  option subnet-mask 255.255.255.0;
  option dhcp-lease-time 86400;
  option routers 192.168.0.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.0.1;
  option domain-name-servers 192.168.0.1;
  renew 2 2018/04/17 12:39:24;
  rebind 2 2018/04/17 22:54:18;
  expire 3 2018/04/18 01:54:18;
}
lease {
  interface "enxb827ebb4a62e";
  fixed-address 192.168.0.102;
  option subnet-mask 255.255.255.0;
  option routers 192.168.0.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.0.1;
  option dhcp-server-identifier 192.168.0.1;
  renew 2 2018/04/17 12:48:50;
  rebind 2 2018/04/17 22:59:45;
  expire 3 2018/04/18 01:59:45;

This is an artifact from testing where my old router assigned 192.168...addresses.

I deleted th and it made no difference (I think). On the other hand I cannot get rid of the LOCAL "rememberence" of the Internet address. "sudo dhclient -r enxb827ebd88666" does NOTHING. ifconfig still shows the address on my Internet facing NIC. Time to re-image the "hard drive" (micro SD card) in the Pi and try again

Ken

jefro · 04-28-2018, 12:51 PM

Some of those modes have some very good technical information in them if you can access it. May need to have phone company bring out their TDR (actually usually a very competent device that the service techs know nothing about) and sweep the line.

Guess you could go outside and disconnect the entire phone line from house for a few hours. Supposed to reset their line.

Could be the upstream dslam.

taylorkh · 04-28-2018, 01:40 PM

Thanks jefro,

I am not sure what you are referring to as "modes"?

As far as getting the phone co. involved... The connection does work and the throughput is decent (well at least it would be in NORTH Korea)

Honestly it does measure close to its "nominal" rating. I am reluctant to get them involved as they can't find anything wrong and do not even comprehend the concern. Better to leave well enough alone.

My dhclient -r and then reboot script worked a couple of times yesterday when I tested it. I did do some package updates to the Pi. Not sure if anything there caused a change. I did find that I could not launch Vivaldi nor Chromium-browser. I removed and reinstalled the packages - still could not. I launched Chromium and waited and waited and after several minutes it came up. Now it and Vivaldi load in the normal time.

Worse comes to worse I will put my CentOS micro server back in place. I CAN have it come up with a random MAC each time the interface is cycled. That DOES get me a new Internet address.

Ken

michaelk · 04-28-2018, 02:22 PM

Quote:

This would seem to point to the DHCP server remembering me even after I told it to release the address and give it to someone else.

From what little I know that is how the current ISC DHCP server works. The server will reassign the same address if there is a still a valid lease or if your old address previously assigned is still available. Changing your MAC would cause neither to be true.

https://www.isc.org/wp-content/uploa...on-20-4-10.pdf

taylorkh · 04-28-2018, 07:02 PM

Thanks to all for their input. The blame seems to be with Ubuntu. I fired up a CentOS 6 virtual machine (was going to use a CentOS 7 VM but I snagged the 6 by mistake - been messing with this for too long) and did some release/renew experimenting. I observed this after issuing the dhclient -r command

Code:

[root@localhost Desktop]# dhclient -v
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:50:56:3f:89:60
Sending on   LPF/eth1/00:50:56:3f:89:60
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 (xid=0x6238e13b)
DHCPOFFER from 10.42.0.1
DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x6238e13b)
DHCPACK from 10.42.0.1 (xid=0x6238e13b)
bound to 10.42.0.29 -- renewal in 1704 seconds.

The VM had the address 10.42.0.124 before the release. The dhcp server (dnsmasq on the Pi in fact) offered 10.42.0.29 and it was accepted and bound to the interface - as it should have. I then tried this on an Ubuntu 16.04 VM. After releasing the address I observed

Code:

root@ubuntu:/home/moe/Desktop# dhclient -v
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/ens33/00:0c:29:84:94:24
Sending on   LPF/ens33/00:0c:29:84:94:24
Sending on   Socket/fallback
DHCPDISCOVER on ens33 to 255.255.255.255 port 67 interval 3 (xid=0xee4aca5f)
DHCPREQUEST of 10.42.0.223 on ens33 to 255.255.255.255 port 67 (xid=0x5fca4aee)
DHCPOFFER of 10.42.0.223 from 10.42.0.1
DHCPACK of 10.42.0.223 from 10.42.0.1
RTNETLINK answers: File exists
bound to 10.42.0.223 -- renewal in 1595 seconds.

The offending line seems to be:

DHCPREQUEST of 10.42.0.223 on ens33 to 255.255.255.255 port 67 (xid=0x5fca4aee)

It seems that the client is requesting its old address. Not what I want to do. I then moved to the Pi and found the same behavior. I searched for the Pi's old address and found it here

Code:

grep -R '71.48.5.144' /var/ *.lease
/var/lib/NetworkManager/dhclient-f49cc2d3-e9cf-3771-b94d-d41a4856d20a-enxb827ebd88666.lease:  fixed-address 71.48.5.144;
/var/lib/NetworkManager/dhclient-f49cc2d3-e9cf-3771-b94d-d41a4856d20a-enxb827ebd88666.lease:  fixed-address 71.48.5.144;

grep -R '71.48.5.144' /var/ *.leases
/var/lib/dhcp/dhclient.leases:  fixed-address 71.48.5.144;
/var/lib/dhcp/dhclient.leases:  fixed-address 71.48.5.144;

I then whacked the offending files with a big hammer

Code:

rm /var/lib/NetworkManager/dhclient*.lease
rm /var/lib/dhcp/dhclient.leases

I then asked for a new address

Code:

root@taylor23:/home/ken# dhclient -v  enxb827ebd886666
enxb827ebd886666: interface name too long (is 16)

If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging..

exiting.

Which is BS

Code:

root@taylor23:/home/ken# nmcli dev status
DEVICE           TYPE      STATE      CONNECTION         
enx0050b61c0065  ethernet  connected  Wired connection 2 
enxb827ebd88666  ethernet  connected  Wired connection 1 
lo               loopback  unmanaged  --

But this is Ubuntu so I omitted the interface name.

Code:

root@taylor23:/home/ken# dhclient -v
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enx0050b61c0065/00:50:b6:1c:00:65
Sending on   LPF/enx0050b61c0065/00:50:b6:1c:00:65
Listening on LPF/enxb827ebd88666/b8:27:eb:d8:86:66
Sending on   LPF/enxb827ebd88666/b8:27:eb:d8:86:66
Sending on   Socket/fallback
DHCPREQUEST of 10.42.0.224 on enx0050b61c0065 to 255.255.255.255 port 67 (xid=0x7f3003bf)
DHCPREQUEST of 71.48.5.152 on enxb827ebd88666 to 255.255.255.255 port 67 (xid=0x59791fdf)
DHCPACK of 10.42.0.224 from 10.42.0.16
RTNETLINK answers: File exists
bound to 10.42.0.224 -- renewal in 32593 seconds.

Low and behold I had a new IP address

Unfortunately this also reset the LAN side interface (which has a manually set address) and I lost connection with the Pi. My new reset script looks like

Code:

#!/bin/bash
sudo dhclient -r enxb827ebd88666
sudo rm /var/lib/NetworkManager/dhclient*.lease
sudo rm /var/lib/dhcp/dhclient.leases
sudo shutdown -r now

Not sure why the dhclient -v -r works with the long winded interface name and dhclient -v does not. Something to look into another time. Bottom line I can now change my Internet IP address at will. Now if only I could remember why I wanted to do so

Ken

taylorkh · 04-30-2018, 10:53 AM

I tried my script again this morning - the IP address from the ISP did NOT change. The Pi has been fired. My CentOS server is back in its place. With the MAC address on the Internet facing NIC set to "random" I get a new address when I reboot the server. I had done that a couple of times getting the server configured as I wanted it. I have not tried my new_ip.sh script. It seems the ISP's DHCP server gets a little upset being hit with multiple MACs from the same DSL connection. The last time I tried to grab a new one it stalled for about 5 minutes or so. I will leave things alone for a while and try again this evening just for the heck of it.

Ken