problem with dhcpcd-1.3.18-pl3 daemon, 3c59x driver and 3com905c card

[Dusan Vujosevic]

> >  I have a problem with dhcpcd-1.3.18-pl3 daemon (by Sergei Viznyuk),
3c59x
> > driver (by Donald Becker, obtained in March from
> > http://cesdis.gsfc.nasa.gov/pub/linux/drivers/3c59x.c) and 3com 905c
> > card. When the dhcpcd asks for an IP from a Windows 2000 server (retail
> > version) it reports the MAC address (hardware address, station address
> > ... whatever you want to call it) of eth0 as 00:00:00:00:00:00. The
> > servers gives it an IP.
>
> Hmmm, exactly what is reporting this address?

The Windows 2000 Server DHCP administration tool (the window is titled just
'DHCP'). It doesn't have any problems with a 3com 905b as I already
mentioned (or an Intel EEPro ...).

> My first guess is that dhcpcd is the problem.  I've never met a DHCP
client
> that worked reliably on Linux.

I have to agree there :-( although I had least problems with dhcpcd.

>We *really* want one for cluster work, so
> we have looked.  In part the problem that the kernel has changed the
> interface several times -- see the 'bootp' references on
>   http://cesdis.gsfc.nasa.gov/linux/index.html
> But there must be something about writing DHCP clients that causes
otherwise
> sane programmers to write programs that want to control every aspect of
the
> machine, for all time, and to use 100% of the CPU doing it.
>
> I've been burnt (almost literally, my laptop gets hot when 'pump' runs
amok)
> so many time in the past year by this...
>
> > The  driver provided by 3com (patch for kernel 2.2.5) behaves in the
exact
> > same way.
>
> That's completely different code, from scratch, so that really points to a
> non-driver bug.
>
> > Donald Becker's driver also gives a checksum error on load but loads
> > OK (shown in dmesg below).
>
> This is harmless, as long as it happens on the new 3c905C cards.  It
exists
> because 3Com continues to stuff more info into the EEPROM.  Rather than
> computing a checksum over the whole EEPROM, or having a
backwards-compatible
> subset and retaining the old checksum location, they keep moving the
> checksum word a few bytes at a time.
>
> The "solution" in the updated drivers is to just omit the warning with new
> cards.  I've never seen a report of EEPROM that became spontaneously
> corrupted.

I figured that but it feels so much better when you say it :-). I wasn't too
worried about this.

> > VFS: Disk change detected on device ide1(22,0)
> > protocol 0400 is buggy, dev eth0
> > protocol 0400 is buggy, dev eth0
>
> Hmmm, very curious.  I don't know what is generating this message, but
it's
> not from the driver.

I believe that Appletalk stack is doing it. I could stand corrected on this.
I'm sure it is unrelated to this dhcpcd problem.

> A final note: it's the protocol software layer that stuffs the Ethernet
> station address into the packet, not the hardware.  The hardware only
cares
> for filtering Rx packets.

Thanks a lot for clearing all this out. I guess it's Sergei's turn now or
someone (I, any volunteers?) should just try to look at dhcpcd and where is
it getting the station address.

Thanks all,
Dusan

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-bug-request@beowulf.org