Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 38 replies
  • Subscribers 2 subscribers
  • Views 21164 views
  • Users 0 members are here
Options
Suggested
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

dwmtractor
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.
  • 0 in reply to BarryG
    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-)]
  • 0 in reply to dwmtractor
    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 
  • 0
    After resetting the modem and getting Astaro reconnected, did the IP change?

    I'm guessing that Astaro is trying to renew the old IP, and for some reason Comcast is not allowing that IP to be renewed.

    Barry
  • 0 in reply to BarryG
    After resetting the modem and getting Astaro reconnected, did the IP change?

    I'm guessing that Astaro is trying to renew the old IP, and for some reason Comcast is not allowing that IP to be renewed.

    Barry


    The IP did NOT change, Barry.  My guess is exactly the same as yours.  It appears that ASG caches the IP address somewhere and is trying to insist on that same IP.  When the Comcast system tries to supply an ip that's not only different, but on an entirely different subnet, ASG chokes.  This is what I've been trying to convey from the beginning.

    I believe there must be some place that ASG stores the DHCP lease information, including IP, source server, TTL, etc.  That information should be flushed on a DHCP renewal, and this is not happening.  Trouble is, I don't know where to look for this.  If someone can help me find it, I'll try manually deleting the info next time this drops, and if that works, we can file a bug with Astaro to make sure that this flush is made part of the DHCP renewal process.
  • 0
    I have a supermicro dual core atom box I use for testing firewall software.  When I was using Kerio Control I could NOT get an IP from the Comcast modem at all.  Same Supermicro box, running PFSense and Astaro were both fine, just with one distro I could NOT get an IP.  I'm now running ASG Home license on that box and it's running fine to a Motorola SB6120 modem.

    I'm new to ASG, but is there a way to change the MAC address on your WAN port to force a different IP?
  • 0 in reply to rugby
    I have a supermicro dual core atom box I use for testing firewall software.  When I was using Kerio Control I could NOT get an IP from the Comcast modem at all.  Same Supermicro box, running PFSense and Astaro were both fine, just with one distro I could NOT get an IP.  I'm now running ASG Home license on that box and it's running fine to a Motorola SB6120 modem.

    I'm new to ASG, but is there a way to change the MAC address on your WAN port to force a different IP?


    The MAC address is hard-coded onto the network card, Rugby.  There are special software and adaptor combinations that can "spoof" a MAC, but that's not something you're going to be able to change in ASG.
  • 0 in reply to dwmtractor
    Is there any hope at all that someone from Astaro technical would take a look at this and let me know more about the ASG back-end?  I've tried to get help through Astaro Support, but even though I'm an authorized partner with multiple paid licenses that I support, they won't give me the time of day on my personal at-home license.  [:@]
  • 0
    Does an authorized reseller get a partner license?  There is support for that.

    Cheers - Bob
  • 0 in reply to dwmtractor
    The MAC address is hard-coded onto the network card, Rugby.  There are special software and adaptor combinations that can "spoof" a MAC, but that's not something you're going to be able to change in ASG.


    That kind of stinks, well, what if you swapped the LAN and WAN ports to get a different address from the Comcast line?
  • 0 in reply to rugby
    That kind of stinks, well, what if you swapped the LAN and WAN ports to get a different address from the Comcast line? 

    That can be done, and certainly you'd be throwing a different MAC at ComCast if you did so.  The only trick is that ASG won't let you re-define a port to nothing (i.e. delete it before you re-create it) while you have rules in your packet filter and other places, that use those rules.  So if you wanted to swap ports, you could only do it if you had a vacant, unused port you could direct the definition to.  At least that's been my experience in the past.