Solved

AT&T @Home DHCP and Linux config?

Posted on 2001-06-16
7
263 Views
Last Modified: 2010-03-18

AT&T @Home has screwed me and switched over to DHCP -- my "static" IP addresses are apparently useless now.

So how do I set up RedHat 7.1 (out of the box) to deal with DHCP? The web searches I've done so far haven't been very helpful. Can it all be done through Network Config or do I need to run dhcpcd, or what? TIA
0
Comment
Question by:barrett
  • 4
  • 3
7 Comments
 
LVL 40

Expert Comment

by:jlevie
ID: 6198919
All you should need to do is to remove the static IP, default route, and possibly the nameserver specifications and enable DHCP for the interface. You can do that with linuxconf or with netcfg. The reboot the box and see if it gets an IP (ifconfig -a). Also check for a default route with "netstat -rn". Some DHCP servers seem not to properly set up the DNS data (check /etc/resolv.conf) and you might have to manually configure that.
0
 

Author Comment

by:barrett
ID: 6199011
You'll have to bear with me on this --

Did just as you suggested: in the Network Conguration app, I removed the IP address from interface eth0, as well as the default route and the nameservers. I enabled DHCP on eth0, saved and rebooted.

During boot, the "bringing up interface eth0" part takes a long time. When I try to ping out, I get "Network is unreachable." Network Configuration reports that eth0 is "inactive" with proto "dhcp". When I try to activate it, it waits a very long time, then finally declares that eth0 is "active," but I still get "Network is unreachable" when I ping.

There are no entries in /etc/resolv.conf, just
"nameserver
search bbox.com"

"ifconfig -a" reports no IP address for eth0.


0
 
LVL 40

Accepted Solution

by:
jlevie earned 200 total points
ID: 6199818
Are you certain that the change was to DHCP and not to PPPoE? Did your provider have any specific instructions about how DHCP is supposed to be set up?

It seems obvious that the DHCP negotiation is failing. Some providers require you to furnish them with the MAC from your ethernet card, and I've encountered others that require a specific host name to be in the DHCP request. And @Home is notorious for using a DHCP server that is not exactly right per the RFC's. It works with windows, which itself takes extreme liberties with the RFC's, but can be a problem with Linux, *BSD, Solaris, etc.

The default DHCP client on RedHat is pump and I know earlier versions of that had problems. In some cases you could switch to dhcpcd and it would work with @Home where pump didn't. I thought that thoes problems had all been resolved in 7.0, so maybe there's something else going on here.

Did this box run an earlier version of Linux (is, which one)? Did you have the box on the network before the switch to DHCP? If this is a "new install" it is possible that you have a problem with your NIC card, like a resource conflict. That occurs when two or more devices try to use the same IRQ. You can check for a resource conflict with "dmesg | grep -i irq" and examination of /proc/interrupts and /proc/pci. Another possibility would be a driver problem. What NIC (make/model) do you have in the system?
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 

Author Comment

by:barrett
ID: 6200026

Box was connected before the DHCP switch, so I think the NIC is OK. AT&T makes it sound like it's really DHCP, but they're absolutely no help.  Guess I'll have to go back to searching the web for a clue. Thanks anyway!
0
 
LVL 40

Expert Comment

by:jlevie
ID: 6200056
Was it running 7.1 then? If you were running an older version of Redhat, things changed with respect to IRQ allocation. Notably, a 7.1 box will enable USB if it finds the hardware where 6.2 would have ignored any USB controllers because it didn't have drivers.

Let's see if we can find out what is happening. Boot the box and kill pump with "killall pump". Then start a tcpdump (install it from the 1st CD if needed) with "tcpdump -n" and in another window or virtual console execute "/sbin/pump --lookup-hostname -i eth0". The tcpdump trace will let you see if you are sending requests and whether the remote server is responding. If there is an IRQ or NIC driver problem you'll see the outgoing requests and their replies, but the negotiation will fail. I you don't see the replies, that might imply some problem with the cable or the modem.

You could also try dhcpcd. To do that you'll need to kill pump as above and invoke dhcpcd as "dhcpcd eth0". If you keep the tcpdump running you can see what happens.

Try that and let me know what happens.
0
 

Author Comment

by:barrett
ID: 6200150

[rolling up sleeves]

This is a fresh 7.1 installation, so no worries there. Just followed the first procedure, and here's the kind of output I received:

11:26:36:351706 eth0 > 0.0.0.0.bootpc > 255.255.255.255.bootpc: xid:0x8fa3fb8b ether 0:50:4:74:48:f1 [ lbootp ] (DF)

11:26:36:351706 eth0 > 0.0.0.0.bootpc > 255.255.255.255.bootpc: xid:0x8fa3fb8b secs:1024 ether 0:50:4:74:48:f1 [ lbootp ] (DF) ...

11:26:36:541706  eth0 B arp who-has 24.255.123.205 tell 24.255.120.1

5 packets received by filter.

The "Activity" and "PC-Link" lights blink while this is happening.

The second procedure gives me:

11:28:28:691706 eth0 > 0:0:0:0:0:0 null > 0:50:4:74:48:f1 sap 45 I (s=1,r=32,C) len 572
          f6c2 0000 4011 81eb 0000 0000 ffff ffff
          0044 0043 022c f1b9 0101 0600 f8e2 3a0e
          0003 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0050 0474 48f1 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000
11:28:28:481706 eth0 B arp who-has 24.255.123.205 tell 24.255.120.1
11:28:28:251706 eth0 B arp who-has 24.255.123.205 tell 24.255.120.1
11:28:28:421706 eth0 B arp who-has 24.255.123.205 tell 24.255.120.1
11.28.44.741706 eth0 > 0:0:0:0:0:0 null > 0:50:4:74:48:f1 sap 45 I (s=1,r=32,C) len 572
          f6c2 0000 4011 81eb 0000 0000 ffff ffff
          0044 0043 022c f1b9 0101 0600 f8e2 3a0e
          0003 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0050 0474 48f1 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000 0000 0000
          0000 0000 0000 0000 0000 0000
11:28:28:821706 eth0 B arp who-has 24.255.123.205 tell 24.255.120.1
11:28:28:701706 eth0 B arp who-has 24.255.123.205 tell 24.255.120.1
11:28:28:891706 eth0 B arp who-has 24.255.123.205 tell 24.255.120.1

The lights blinked a few times, so it seems like I'm at least trying to have a conversation with their server.




0
 

Author Comment

by:barrett
ID: 6204850
This works:

http://sdb.suse.de/en/sdb/html/leah_all_dhcp_with_at_home.html

Configuring DHCP For AT&T's @home Cable Network    

Support knowledgebase (leah_all_dhcp_with_at_home)
Problem:
You are trying to configure your cable modem to work with AT&T's @Home network using DHCP, but all DHCP requests time out.
Cause:
Sometimes this is caused because @Home requires that the hostname be used to authenticate the DHCP request.
Solution:
The solution to this problem is simple.
Configure your Network card first using YaST 1 or YaST 2. Do _not_ activate the networking device, however. Refer to the manual for help doing this.
Edit the file /sbin/init.d/boot.local so that it looks like this:
     dhcpcd -h <hostname> <device>

For example:
     dhcpcd -h c113@blah eth0

Upon rebooting the machine, your network should be started correctly. The line entered in the /sbin/init.d/boot.local file can be entered directly to the command line as well.

--------------------------------------------------------------------------------
Keywords: @HOME, DHCP, CABLE, AT&T, NETWORK

--------------------------------------------------------------------------------
Categories: DHCP

--------------------------------------------------------------------------------

SDB-leah_all_dhcp_with_at_home, Copyright SuSE GmbH, Nurnberg, Germany - Version: 06. Nov 2000
SuSE GmbH - Last generated: 29. May 2001 by leah (sdb_gen 1.30.0)
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
This video discusses moving either the default database or any database to a new volume.
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now