Chris Richmond <tomnykds@???> wrote:

> Aug 4 18:33:15 teton dhclient[3755]: Listening on LPF/eth1/00:1c:c0:e1:d0:ff
> Aug 4 18:33:15 teton dhclient[3755]: Sending on LPF/eth1/00:1c:c0:e1:d0:ff
> Aug 4 18:33:15 teton dhclient[3755]: Sending on Socket/fallback
> Aug 4 18:33:15 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
> Aug 4 18:33:20 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
> Aug 4 18:33:26 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
> Aug 4 18:33:40 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 13
> Aug 4 18:33:53 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
> Aug 4 18:34:00 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
> Aug 4 18:34:08 teton dhclient[3755]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
> Aug 4 18:34:16 teton dhclient[3755]: No DHCPOFFERS received.

Right, that gives a pointer to where the problem lies - but unfortunately there are maaaany reasons this situation can occur.

It would be useful to run a packet capture (tshark, etc) and see if any replies are actually received from the ISP ? If they are, then that rules out one class of problems - it means that the DHCP packets are getting to the ISP and being answered.
If you see no replies, then the the DHCP packets either aren't getting out, or the replies aren't getting back.

Then it's a case of looking for differences in the environment - in particular, interface state and any filters applied. Specifically, has anything changed in the filtering setup between the two kernels ?
IIRC there are changes happening to deprecate/remove netfilter and replace it with something else - but I don't know when that has happened/is happening in terms of kernel version numbers.