After I was connected to another network somewhere in September 2008 my system was always connecting to my own router with IP 192.168.1.102.
Even after I replaced my router with another one (same brand slightly different model) it stayed 192.168.1.102.
Only a few months ago when I was trying to manually connect to my AP using dhclient I lost the “fixed DHCP” functionality to connect with IP 192.168.1.102.
I was connecting to 192.168.1.4 from than on. Before this I made a copy of /var/state/dhcp/dhclient.leases and /etc/dhcpc/dhcpcd-ra0.info.
I just upgraded to a later Slackware release (12.2) and due to not being able to connect with the kernel build-in rt2500 drivers I compiled a new kernel without Ralink driver support and used the Legacy rt2500-cvs-2009041204 driver again. Today I looked again at the DHCP behavior and decided to try to get the IP address back to 192.168.1.102. I first copied the backup /var/state/dhcp/dhclient.leases and /etc/dhcpc/dhcpcd-ra0.info back to its original place, turned of the system and rebooted my router (with the DHCP server), turned on my system and …… yes it is 192.168.1.102 again. Even after a number of reboots.
My lease time is 24 hours so I’m not sure if this behavior will change after I have been offline for more than 24 hours.
But now I’m wondering how this “Fixed DHCP” behavior is working.
/usr/share/apps/rutilt/set_ip.sh is still default.
dhclient.conf is default.
man dhclient only specifies that the /var/state/dhcp/dhclient.leases file is used as a last resort, until a DHCP server is available.
Is this behavior part of Rutilt?
this definitely has nothing to do with RutilT.
This could possibly be a feature of your AP, or normal dhcp protocol behavior, I'm not sure.
Thanks for your reply.
For sure (unfortunately) my AP doesn't support fixed/reserved dhcp.
I did some tests
1) Waited for longer than 24 hours (lease time configured on my AP), reconnected an ..yes still 192.168.1.102
2) Waited again for longer than 24 hours AND rebooted my AP to clear the dhcp database. Still after reconnecting the assigned IP address is 192.168.1.102.
I’m happy with this behavior. I was hoping to understand this behavior so I could replicate this with my other system.
If I have some more time I will look with Wireshark how the discover/offer packets look like.