Looking for an ASUS motherboard that net boots...

[Lennart Sorensen]

On Wed, Aug 20, 2008 at 10:42:35AM -0400, Colin McGregor wrote:
> On 8/15/08, Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> > On Fri, Aug 15, 2008 at 10:51:31AM -0400, Colin McGregor wrote:
> >> The board has the MAC address : db:b3:db:60:1d:00 . This is a
> >> broadcast MAC address.
> >
> > So it has address 00:1d:60:db:b3:db when not read in reverse.  That
> > would make sense.
> >
> > So you actually see the reversed address in the logs from the network
> > boot server?
> 
> Yes.
> 
> So, to sum up what seems to happen is this:
> 
> - Script is run on the server telling it to expect a new diskless client.
> - Diskless client is booted sends out a bootp request, with the
> broadcast MAC address, which the server responds to.
> - Kernel is downloaded by diskless client and run.
> - Kernel sees the MAC address is invalid, and changes MAC address to a
> randomly selected valid MAC address.
> - Diskless client requests an IP address from DHCP server (running on
> little router box), and gets a different IP address each time (because
> the MAC address keeps changing).
> - Things get weird... If I run the set-up script, the server will
> continue to set-up a profile for the diskless client, based on the IP
> number (which will not be the same on the next boot). If I don't run
> the set-up script here, things will fail because the IP number has not
> been configured.
> 
> If I restrict the number of available dhcp numbers to a small value
> (say 4) then I will just run out of available IP numbers and
> EVERYTHING breaks...
> 
> Kernel in all of this is 2.6.18 (not the latest ... and I am loath to
> change because I have a solid reliable server there...).

Well certainly 2.6.18 IS too old to work correctly with that chipset for
ethernet.  It will always reverse it as far as I can tell looking at the
git logs.  I think around 2.6.22 or 2.6.23 is when things were finally
starting to work.

As for PXE, it sounds like they simply screwed up and used old PXE code
that doesn't know that the newer chips should not be reversed anymore.
That Asus should be able to fix.

> Any event, the motherboard ASUS M2N-MX SE Plus motherboard was shipped
> back to ASUS on Monday by FedEX Air and was delivered Tuesday morning
> to the ASUS office in Indiana (the tab for the FedEx bill being picked
> up by ASUS). So, what should be a 10 minute job is more more like a 10
> week job and I have a motherboard that is collecting a lot more
> frequent flyer points than me :-( ... This motherboard is now a
> financial and good will loss for ASUS. I am annoyed and frustrated...
> A no win situation all around... Sigh...

Well Asus should update the BIOS to fix the PXE bug.  You should update
the kernel to fix the forcedeth bug.

I don't think they actually got the MAC address backwards on the board,
although I guess that could be the case since it would explain both PXE
and the kernel seeing a reversed MAC but it doesn't match with the
kernel changes made since 2.6.18 as far as I can tell.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists