Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DHCP client not working with Comcast Cable

I have an ASG box that was working fine for better than a year on AT&T DSL, but when I moved I had to switch to Comcast cable.  The same box immediately had trouble with its DHCP client on the WAN port.  It would obtain a lease at boot, but then if for any reason the link bounces (happens especially in the rain), ASG is unable to renew the lease without a reboot, and sometimes not even then.

I've tried it both with ARP cache enabled and disabled...sometimes it works one way and sometimes the other, but either way the WAN port seems stuck on the same IP it already had, and the "Renew" button does not refresh the DHCP.

In these situations, invariably if I plug my Windows PC directly into the cable modem it obtains a lease immediately and tests out with a fast, stable connection, so the problem is clearly in the ASG box and not in the modem or the account.  I've already tried swapping out the NIC and that has not changed the situation.  I also upgraded to 8.0 (now 8.03) and this has not changed the problem at all.

I can't find anything in the logs, but I may not know where to look.  I've also found no way to renew the lease manually from the command line; everything I google turns out to be a command that's not available in the ASG bash shell.  Any suggestions?


This thread was automatically locked due to age.
Parents
  • fwiw, losing connection during or after rain may be a sign that you have leaks in the coax cable fittings outside your house. This is especially likely if Comcast re-used cabling that was already there.

    There are indoor coax connectors, and outdoor coax connectors. I had a condo where DISH had installed everything with indoor connectors, and when TimeWarner reused the cables, it was horribly unreliable after rain, and kept getting worse. It took many service calls before I was able to get TW to replace even SOME of the connectors, and later, the cabling.

    Once water gets in the cable, it starts to rust the conductors, and replacing the connectors may not be enough.

    Barry
Reply
  • fwiw, losing connection during or after rain may be a sign that you have leaks in the coax cable fittings outside your house. This is especially likely if Comcast re-used cabling that was already there.

    There are indoor coax connectors, and outdoor coax connectors. I had a condo where DISH had installed everything with indoor connectors, and when TimeWarner reused the cables, it was horribly unreliable after rain, and kept getting worse. It took many service calls before I was able to get TW to replace even SOME of the connectors, and later, the cabling.

    Once water gets in the cable, it starts to rust the conductors, and replacing the connectors may not be enough.

    Barry
Children
  • fwiw, losing connection during or after rain may be a sign that you have leaks in the coax cable fittings outside your house. This is especially likely if Comcast re-used cabling that was already there.

    There are indoor coax connectors, and outdoor coax connectors. I had a condo where DISH had installed everything with indoor connectors, and when TimeWarner reused the cables, it was horribly unreliable after rain, and kept getting worse. It took many service calls before I was able to get TW to replace even SOME of the connectors, and later, the cabling.

    Once water gets in the cable, it starts to rust the conductors, and replacing the connectors may not be enough.

    Barry

    I'm aware of this, Barry.  Trouble is, I can't get Comcast to take me seriously if every time I try to call them, their first diagnostic is "unplug your firewall and plug your computer in direct" and every time I do that it works flawlessly.  Not to say that if I *did* get the FW issue resolved, they would be any more helpful... [8-)]
  • Update:

    I set the MTU to 1492, reset DHCP and reset the modem, and my download speed dropped to 6MBPS.  Reset the modem again in case it had not "taken" (whatever) and DHCP couldn't get a lease at all--log filled up with entries like this:
    2010:12:02-17:15:34 djwall dhcpc-sh: DHCP client is running
    
    2010:12:02-17:16:05 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0xdb109398 as it's not ours (0x6f9e06d8)
    2010:12:02-17:16:05 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x6f9e06d8
    2010:12:02-17:16:05 djwall dhcpcd[12524]: eth1: waiting for 101764 seconds
    2010:12:02-17:16:06 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0x8b27c03c as it's not ours (0x6f9e06d8)
    2010:12:02-17:16:06 djwall dhcpcd[12524]: eth1: waiting for 101763 seconds
    2010:12:02-17:16:07 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0x59b3d7cc as it's not ours (0x6f9e06d8)
    2010:12:02-17:16:07 djwall dhcpcd[12524]: eth1: waiting for 101762 seconds
    2010:12:02-17:16:10 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x6f9e06d8
    2010:12:02-17:16:14 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0x1ad58578 as it's not ours (0x6f9e06d8)
    2010:12:02-17:16:14 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x6f9e06d8
    2010:12:02-17:16:14 djwall dhcpcd[12524]: eth1: waiting for 101755 seconds
    2010:12:02-17:16:14 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0xb2e2cf86 as it's not ours (0x6f9e06d8)
    2010:12:02-17:16:14 djwall dhcpcd[12524]: eth1: waiting for 101755 seconds
    2010:12:02-17:16:15 djwall dhcpcd[12524]: eth1: received SIGALRM, renewing lease
    2010:12:02-17:16:15 djwall dhcpcd[12524]: eth1: renewing lease of X.X.X.X
    2010:12:02-17:16:15 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x1d798f55
    2010:12:02-17:16:15 djwall dhcpcd[12524]: eth1: waiting for 101853 seconds
    2010:12:02-17:16:17 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0x6c5bef1c as it's not ours (0x1d798f55)
    2010:12:02-17:16:17 djwall dhcpcd[12524]: eth1: waiting for 101851 seconds
    2010:12:02-17:16:20 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x1d798f55
    2010:12:02-17:16:22 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0xfada10a as it's not ours (0x1d798f55)
    2010:12:02-17:16:22 djwall dhcpcd[12524]: eth1: waiting for 101846 seconds
    2010:12:02-17:16:25 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x1d798f55
    2010:12:02-17:16:30 djwall dhcpcd[12524]: eth1: ignoring packet with xid 0xec09d097 as it's not ours (0x1d798f55)
    2010:12:02-17:16:30 djwall dhcpcd[12524]: eth1: sending DHCP_REQUEST with xid 0x1d798f55 


    Note the line in red above--the IP that I obfuscated is the prior IP of the connection--and the one that ASG seems to insist on getting, refusing all other subnets.  By this I mean Windows connections get a different IP depending on when I renew it; ASG always gets this one IF it works at all.

    Anyhow, I re-set the MTU to 1500 and reset the modem again, and the renewed IP got downloads of 21MBPS.  Pretty substantial difference IMO.  Here's the log from the (now successful) renew.  I still wish someone would tell me how to find what is different about the successful and failed attempts.
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: broadcasting for a lease
    
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: sending DHCP_DISCOVER with xid 0x47e06d77
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: waiting for 20 seconds
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: got a packet with xid 0x47e06d77
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: offered X.X.X.X from Y.Y.Y.Y
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: sending DHCP_REQUEST with xid 0x47e06d77
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: waiting for 20 seconds
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: got a packet with xid 0x47e06d77
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: checking X.X.X.X is available on attached networks
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: sending ARP probe #1
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: sending ARP probe #2
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: sending ARP probe #3
    2010:12:02-17:19:10 djwall dhcpcd[12954]: eth1: sending ARP claim #1
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: sending ARP claim #2
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: leased X.X.X.X for 271329 seconds
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: renew in 135664 seconds
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: rebind in 237412 seconds
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: setting MTU to 576
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: adding IP address X.X.X.X/23
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: no dns information to write
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: writing /var/lib/dhcpcd/dhcpcd-eth1.info
    2010:12:02-17:19:11 djwall dhcpcd[12954]: eth1: exec "/usr/sbin/eth1" "/var/lib/dhcpcd/dhcpcd-eth1.info" "new"
    2010:12:02-17:19:13 djwall ntpd[5469]: Listen normally on 10 eth1 X.X.X.X UDP 123
    2010:12:02-17:19:13 djwall ntpd[5469]: new interface(s) found: waking up resolver
    2010:12:02-17:19:17 djwall dhcpcd[12954]: eth1: waiting for 135664 seconds
    2010:12:02-17:19:35 djwall dhcpc-sh: DHCP client is running