I, too, have a LANCity. I finally just had to plug in my Cox IP address
statically. Perhaps they'll finally change it out.
Jeffrey Pyne wrote:
>
> 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
> ________________________________________________
> See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't post to the list quickly and you use Netscape to write mail.
>
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)