Re: PXE-compliant boot server request?

Hi Marty!

On 6 Feb 2006, at 15:57, Marty Connor wrote:

> On Feb 5, 2006, at 3:28 PM, Roland Kuhn wrote:
>> Hi!
>> I'm struggling with the automatic network installation setup at  
>> our institute, which requires more PXE-compliance than currently  
>> offered by etherboot. To be specific, it requires the  
>> PXE_BOOT_ITEM selection to be present in the DHCPREQUEST, and it  
>> requests via DHCP_DISCOVERY_CONTROL that neither broadcast nor  
>> multicast be used for that packet. I'm thinking about adding that  
>> functionality, but there are two ways: hard-coding the specifics  
>> for this setup or handling the involved protocol. What do you  
>> think? Does this have a chance of inclusion?
>> Ciao,
>>                     Roland
>
> Improved PXE compatibility is certainly one of our goals, and if  
> your changes work toward that end, they are likely to be included.
> Handling the protocol would be more likely to be included, of  
> course (as I am sure you would do).
>
> Thanks for writing, and we look forward to seeing what you come up  
> with.
>
Okay, it took some more time that I had hoped, but I think I managed  
some steps in the right direction. The problem is that the system I'm  
testing this on has a network card which is not completely supported:  
The UDP checksum of the received answers from the server are messed  
up because bytes are missing here and there throughout the packets.  
At first I thought that somehow my code for parsing the boot menu was  
buggered, but when I dumped the raw bytes it became obvious that e.g.  
the third octet from an IP address was missing and some characters in  
the boot menu strings were simply not there.

The card in question is a 3com996B-T with the bcm5701 chipset, lspci - 
vvvnxx output is

00:08.0 Class 0200: 14e4:1645 (rev 15)
         Subsystem: 10b7:1006
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr+ Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (16000ns min), cache line size 10
         Interrupt: pin A routed to IRQ 11
         Region 0: Memory at f4800000 (64-bit, non-prefetchable)  
[size=64K]
         Capabilities: [40] PCI-X non-bridge device.
                 Command: DPERE- ERO- RBC=0 OST=0
                 Status: Bus=255 Dev=31 Func=1 64bit+ 133MHz+ SCD-  
USC-, DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM-
         Capabilities: [48] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME 
(D0-,D1-,D2-,D3hot+,D3cold+)
                 Status: D0 PME-Enable- DSel=0 DScale=1 PME-
         Capabilities: [50] Vital Product Data
         Capabilities: [58] Message Signalled Interrupts: 64bit+  
Queue=0/3 Enable-
                 Address: 64d30400de1e7900  Data: 0388
00: e4 14 45 16 46 01 b0 02 15 00 00 02 10 40 00 00
10: 04 00 80 f4 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 06 10
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 40 00
40: 07 48 00 00 f9 ff 03 00 01 50 02 c0 00 20 00 64
50: 03 58 fc 80 00 00 00 78 05 00 86 00 00 79 1e de
60: 00 04 d3 64 88 03 00 00 98 00 05 01 0f 08 ff 76
70: 86 10 00 00 3f 00 00 80 50 00 00 00 00 00 00 00
80: 03 58 fc 80 44 56 34 11 34 00 11 24 82 00 00 00
90: 09 06 00 01 00 00 00 00 00 00 00 00 bf 01 00 00
a0: 00 00 00 00 f7 00 00 00 00 00 00 00 d6 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I have tried to make some additions to bring tg3.c a bit closer to  
the current linux kernel version, but without success. I'm hunting in  
the dark here... If anybody has an idea I'd be glad to hear it.  
Meanwhile I'll try if I can make that card running at 100MBit only to  
see if that makes it any better (though I also have no idea how to  
achieve that, either).

Ciao,
                     Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
	-Doug Gwyn
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------