lkml.org 
[lkml]   [2000]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDifficulties with DHCP and 3c90x network cards
  Hello all,

I'd like to get some machines containing recent 3Com cards (3c905B and
3c905C, mostly) to autoconfigure their network addresses via DHCP, and I've
encountered some strange problems that look like possible driver bugs and/or
bad interactions between the 3c59x driver and DHCP.

Before I describe what doesn't work, though, there are a couple of other
cases which do work (and convince me that I'm not simply doing something wrong,
or using a bad network card):

-> I have another machine with an ne2k-pci card which boots perfectly using
DHCP autoconfiguration, and
-> The GRUB bootloader can obtain a DHCP lease and use it to transfer
kernels and so on over the network on the same machine that Linux fails on.

The system in question is a Dell Dimension XPS with a Pentium III/Coppermine
processor. I've tried kernel versions 2.2.16 and the 2.2.17-pre series, as
well as the 3c59x drivers from 3Com and 2.2.15 with 2.2.17.

With that out of the way, here are my symptoms:

-> The simplest thing to do is to use DHCP autoconfiguration on boot. I have
done this. It fails miserably. Not only does autoconfiguration fail, but
tcpdump run on another computer shows that NO packets are broadcast from the
computer in question.
-> Booting off an initrd with basic network-setup tools, I can try the
following things (using pump as an example, all of the dhcp clients seem to
act about the same, though:
* Run pump immediately. This fails in the same way as the on-boot DHCP;
the packets vanish silently into the void.
* Ifconfig eth0 up, then run pump. This time, I see DHCP request packets
come off the system in question, and replies go back from the dhcp server.
The tcpdump output (with ethernet-addresses turned on) is:
14:08:59.337542 0:10:5a:a7:33:8c Broadcast ip 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x9ae5c661 [|bootp]
14:08:59.337576 0:10:5a:a7:33:8c Broadcast ip 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x9ae5c661 [|bootp]
14:08:59.337930 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 376: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x9ae5c661 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]
14:08:59.338115 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 376: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x9ae5c661 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]

The expected DHCPDISCOVER/DHCPOFFER pairs also appear in syslog.
* Assign an IP address to eth0, then run pump. No change from simply
bringing it up.
* Bring eth0 up, then add the following route:
route add -net 128.118.59.128 netmask 255.255.255.192
When this is done, pump immediately completes successfully. tcpdump
reports:
14:14:41.565778 0:10:5a:a7:33:8c Broadcast ip 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x37e7c661 [|bootp]
14:14:41.566101 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 376: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x37e7c661 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]
14:14:41.571011 0:10:5a:a7:33:8c Broadcast ip 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x37e7c661 [|bootp]
14:14:41.571256 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 343: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x37e7c661 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]
14:14:41.575545 0:10:5a:a7:33:8c Broadcast ip 590: 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x37e7c661 [|bootp]
14:14:41.575803 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 343: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x37e7c661 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]

I've noticed that this is somewhat different from what it reports when GRUB
performs a DHCP request. For reference, here's what is displayed in that
case, although I'm not sure if it'll help anyone.. :)

14:18:06.302938 0:10:5a:a7:33:8c Broadcast ip 590: 0.0.0.0.0 > 255.255.255.255.bootps: (request) xid:0x6e4e1200 [|bootp]
14:18:06.303306 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 342: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x6e4e1200 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]
14:18:06.303732 0:10:5a:a7:33:8c Broadcast ip 590: 128.118.59.169.0 > 255.255.255.255.bootps: (request) xid:0x6e4e1200 [|bootp]
14:18:06.304122 0:50:da:6a:ac:ff 0:10:5a:a7:33:8c ip 342: extra98.swift.psu.edu.bootps > 128.118.59.169.bootpc: xid:0x6e4e1200 Y:128.118.59.169 S:extra98.swift.psu.edu [|bootp] [tos 0x10]

Does this cause a solution to jump out at someone -- or will I have to stick
with an inelegant initrd setup?

Thanks,
Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.135 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site