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 > > 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 -I > 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