DHCPCD Problems with Cox's new network

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Jeffrey Pyne
Date:  
New-Topics: DHCP Solutions
Subject: DHCPCD Problems with Cox's new network
I've been having trouble, as well. I thought I had it all figured out, but
apparently not. I did spend almost 2 hours on hold Saturday morning
(listening to Tori Amos or Enya or whomever-- I requested AT LEAST two songs
for the hold music, and the tech support guy replied that many other people
had requested the same thing).

Anyway, I found something interesting: I had been having trouble getting a
DHCP lease for the past week. Sometimes I would not get a DHCP_ACK from
their server. Other times I would get one and I would get my old @Home IP
address, but then I wouldn't be able to ping my default gateway or connect
to anything on the Internet. When I finally spoke to someone Saturday, I
told him that I was getting an IP address of 24.x.y.z, but that I couldn't
connect to anything on the Internet. He said, "Hmmmm, that's an @Home
address; you should be getting an IP address that starts with 68."
Interesting. He wanted me to look at my "Workgroup" setting, so I quickly
connected my Win98 box to my cable modem and reconfigured it and rebooted.
He had me change the Workgroup to "@COX.NET" and reboot. But while I was
futzing around with this, he said a supervisor had just told him that their
"provisioning server" was down and that I would not be able to get an IP
address from DHCP until it was back up (oh, and there was no E.T.A.). After
I expressed my displeasure and hung up, I tried rebooting the Win98 box just
for fun. When I did, I immediately got an IP address and could connect to
resources on the Internet. Bizarre. I connected my firewall back up and
ran 'dhclient ne0' and I got my old IP address again (even after deleting
/var/lib/dhcp.leases, which is an OpenBSD thing)). I tried manually
assigning the values I received on my Windows box to my firewall, and then I
could connect. So are they using some DHCP server that only hands out IP
addresses for computers in the same "Workgroup?" If so, what about Macs
(which they support)? I'm confused....

Also, a guy at work said that he was told this weekend that the old LANCity
modems don't work with the new network (or rather, they work, but only
intermittently). (And indeed, http://status.cox.net/view.asp shows that
this is an issue.) My co-worker is trading in his modem at a Cox office
today. I have a LANCity modem, too. I think I'll trade it in just for the
hell of it. What kind of modem do you have?

~Frustrated in Phoenix

On Sunday, January 27, 2002 Steve Ellis wrote:

> As many of you may know, @home is going under and Cox Cable has built it

own
> network and is transitioning its customers. My Linux firewall quit

working
> the other nite and after many hours I have determined the problem - for

some
> reason the Cox network is not responding to my DHCP client. My system is
> an old Pentium 166 and has two ethernet cards installed - eth0 connects to
> the cable modem; eth1 connects to my home network. I'm running a DHCP
> server on the home network side (eth1 - static IP address 192.168.1.1) and

a
> DHCP client on eth0. I am running Red Hat Linux 6.1 and using the dhcpcd
> (ver 1.3) client. I have tried to run both dhcpcd and pump from the

command
> line and both timeout. I have also tried dhcpcd with and without the -h
> <HOSTNAME> option. Cox technical support says that their DHCP server does
> not require a hostname to be provided to their new DHCP servers. The
> network traffic is extremely heavy as customers are logging into the Cox
> servers to establish new mail accounts, move data on webservers, etc.
>
> I am logging dhcpcd messages to a separate log and it shows the following
> sequence of events:
>
>      DHCP_REQUEST for an old IP address
>      Timeout waiting for DHCP_ACK
>      broadcast of DHCP_DISCOVER
>      Timeout waiting for response from valid DHCP server

>
> It appears that dhcpcd was working up until the other nite. The

information
> in dhcp-eth0.info shows an IP address in the new range (68.3.xxx.xxx), new
> domain name (ph.cox.net), etc. I cleared the info in dhcp-eth0.info and
> have verified that dhcpcd is not updating the information.
>
> In the interim I have replaced the Linux box with a Linksys

router/firewall.
> It runs some kind of DHCP client and is able to talk to the Cox DHCP

server
> and get information. It works fine, but provides little protection.
> Unfortunately, I can't observe the traffic between the cable modem and the
> router.
>
> The problem may have something to do with the need for dhcpcd to send a

MAC
> address as part of the DHCP request. I had to configure the Linksys

router
> of a friend of mine to clone the MAC address of the adapter card in his PC
> after connecting the router. This would imply that Cox has sniffed MAC
> addresses of PCs on its network and will only respond to requests from

known
> LAN cards. In my case, I thought that Cox may have sniffed the MAC

address
> of the router and would only accept requests from it. To test this, I

tried
> invoking DHCP from the command line using:
>
>      /sbin/dhcpcd -d -h<old @home hostname> -I <router's MAC address>

eth0.
>
> I assumed the MAC address format is xx:xx:xx:xx:xx:xx. The man page for
> dhcpcd doesn't document the format. Anyway, this didn't work either.
>
> Any insight or suggestions would be most appreciated.
>
> Thanks in advance,
>
> Steve Ellis