etherboot-developers — Discussion of developer issues

[Etherboot-developers] Re: [Etherboot-users] NetGear FA310TX autonegotiation problems?

[Marty C. <md...@th...>]

On 10/6/2001 5:00 PM Fred Gray fe...@np... wrote:
>On Sat, Oct 06, 2001 at 09:14:42AM -0400, Marty Connor wrote:
>> The routine that will be needed to fix this, I'm pretty sure is in 
>> /usr/src/linux/drivers/net/tulip/pnic.c, and is called 
>> pnic_check_duplex().  It will need to be modified a little for Etherboot, 
>> but a call to it before returning from the reset routine will probably 
>> help.  I'll have to look at it more closely.

>Excellent!  I went ahead and implemented this (patch attached), and it works
>for me.  I don't know how this particular patch will affect other tulip-like
>cards, though.  I suspect that I'm calling tulip_check_duplex from the wrong
>place in general.

Fred, great job!  I've been wanting to fix this bug for a long time, but 
since I couldn't reproduce the problem, I never got seriously into it.  I 
know there are a lot of folks with Netgear FA310TX cards and certain 
picky switches that will surely appreciate this!

Your patch looks and compiles fine.  Since this seems to be a peculiar 
case, somewhat specific to certain cards, I've conditionalized the call 
like this:

     if (tp->chip_id == LC82C168)
        tulip_check_duplex(nic);

Since the complete patch is small, I'll attach it for anyone who wants to 
try it by hand.  I'll also update the rom-o-matic.net site with a test 
version for people who get their ROM images that way.

Will anyone with an FA310TX or other LC82C168/169 board test the 
"5.0.4-mc1" release on rom-o-matic.net?  I don't think the patch should 
affect anything that works currently in 5.0.x, but better to test now.  

>Thanks very much for your help,

And many thanks very much for yours!  It's folks like you that make 
Etherboot such a rewarding project.  

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] Mknbi 1.2-5 (production) released

[<ke...@us...>]

I have released mknbi 1.2-5 at http://etherboot.sourceforge.net/

This is mainly a maintenance release and the changes affect very few
people.

+ Renamed do_printf to vsprintf because that's the standard function it
has the same signature as.

+ Moved include of linux-asm-string.h into string.h in anticipation of
using string.h for other standalone binaries. Added signatures for more
string functions. Introduced stddef.h which contains minimal definitions
to port hosted programs. Current target: lua.

+ Daniel Wagner sent in patches to the Makefile so that distinct
intermediate files are used for the various first* images, otherwise
there will be problems with parallel makes (-j).

+ Implemented --noharddisk option to disable hard disk access. No, make
that --disableharddisk. In Perl Getopt --noharddisk is automatically the
inverse of --harddisk.

+ first-linux.S had the right parenthesis in the wrong place for the
initialisation of vmagic.

+ Print warning if zImage kernels are large enough to extend into
Etherboot area.

Re: [Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[Ian D. <ie...@ma...>]

In message <200...@ke...>, ke...@us...
.net writes:
>>However, it would be nicer to just interpret RFC2132 in the way that
>>is most likely to work with all servers :-)
>
>But then there would be no incentive to fix bugs. :-)

True - but the problem is more the ambiguity of the RFC and the
fact that there are broken bootp servers out there. FreeBSD's bootpd
is fixed now, but I still think that Etherboot should choose the
most conservative interpretation of an ambiguous definition... How
about something like this:

	/* Bah, RFC2132 is ambiguous about the size to which the "Maximum
	 * DHCP Message size" refers. It almost certainly means the MTU,
	 * but choose our maximum conservatively in case the server
	 * interprets it as a maximum UDP payload length. */
	#define MAX_BOOTP_MSGLEN	(ETH_MAX_MTU-sizeof(struct iphdr) \
					 -sizeof(struct udphdr))

However, it's not a problem for me any more so I'll leave you and
the rest of the mailing list in peace :-) Thanks for the quick
responses to my questions!

Ian

[Etherboot-developers] patch for MTU/FreeBSD bootpd and lance bugs in 5.0.4 and earlier

[<ke...@us...>]

I have posted a patch to the MTU/FreeBSD bootpd and lance struct
alignment bugs reported recently. You can find it under the Patch
Manager at http://sourceforge.net/projects/etherboot

Re: [Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[<ke...@us...>]

>Etherboot's definition and use of MAX_BOOTP_EXTLEN is actually
>quite confusing; it is used to determine the size of the
>bootp_extension[] array in struct bootpd_t yet its value includes
>the size of the IP and UDP headers. These certainly aren't part of
>bootp_extension[]. I have included a patch below that changes
>MAX_BOOTP_EXTLEN to actually mean the maximum bootp extension
>length.

Ah ok, I see what you mean. I've done it this way.

diff -u ../../etherboot-5.0.4/src/etherboot.h ./etherboot.h
--- ../../etherboot-5.0.4/src/etherboot.h	Thu Aug  2 10:15:20 2001
+++ ./etherboot.h	Mon Sep 24 15:29:20 2001
@@ -76,7 +76,7 @@
 #ifdef	BOOTP_DATA_AT_0x93C00
 #define MAX_BOOTP_EXTLEN	(1024-sizeof(struct bootp_t))
 #else
-#define MAX_BOOTP_EXTLEN	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct bootp_t))
+#define MAX_BOOTP_EXTLEN	(ETH_MAX_MTU-sizeof(struct bootpip_t))
 #endif
 
 #ifndef	MAX_ARP_RETRIES
@@ -117,6 +117,7 @@
 /*#define ETH_MIN_PACKET		64*/
 #define	ETH_FRAME_LEN		1514	/* Maximum packet */
 /*#define ETH_MAX_PACKET		1518*/
+#define	ETH_MAX_MTU		(ETH_FRAME_LEN-ETH_HLEN)
 
 #define ARP_CLIENT	0
 #define ARP_SERVER	1
diff -u ../../etherboot-5.0.4/src/main.c ./main.c
--- ../../etherboot-5.0.4/src/main.c	Thu Aug  9 23:09:38 2001
+++ ./main.c	Mon Sep 24 15:30:25 2001
@@ -67,7 +67,7 @@
 static const unsigned char dhcpdiscover[] = {
 	RFC2132_MSG_TYPE,1,DHCPDISCOVER,
 	RFC2132_MAX_SIZE,2,	/* request as much as we can */
-	sizeof(struct bootpd_t) / 256, sizeof(struct bootpd_t) % 256,
+	ETH_MAX_MTU / 256, ETH_MAX_MTU % 256,
 	RFC2132_VENDOR_CLASS_ID,13,'E','t','h','e','r','b','o','o','t',
 	'-',VERSION_MAJOR+'0','.',VERSION_MINOR+'0',
 	RFC2132_PARAM_LIST,4,RFC1533_NETMASK,RFC1533_GATEWAY,
@@ -78,7 +78,7 @@
 	RFC2132_SRV_ID,4,0,0,0,0,
 	RFC2132_REQ_ADDR,4,0,0,0,0,
 	RFC2132_MAX_SIZE,2,	/* request as much as we can */
-	sizeof(struct bootpd_t) / 256, sizeof(struct bootpd_t) % 256,
+	ETH_MAX_MTU / 256, ETH_MAX_MTU % 256,
 	RFC2132_VENDOR_CLASS_ID,13,'E','t','h','e','r','b','o','o','t',
 	'-',VERSION_MAJOR+'0','.',VERSION_MINOR+'0',
 	/* request parameters */

>However, it would be nicer to just interpret RFC2132 in the way that
>is most likely to work with all servers :-)

But then there would be no incentive to fix bugs. :-)

>>Just curious, why is bootpd sending the maximum packet all the time? Is
>>it padding the packet with nulls? Surely the clever thing to do would be
>>to send only as big a packet as needed.
>
>I'm not sure, but I would guess that it dates back to before the
>Maximum DHCP Message Size option existed. The bootpd code in FreeBSD
>hasn't changed much since 1994 anyway. It looks as if the old
>(probably unofficial) way for a bootp client to specify that it
>could handle a long bootp reply was for it to send a request packet
>that was as long as the maximum reply it would accept. The bootpd
>code just changed the request into a reply and resent it without
>changing the length. I guess when support for the DHCP max message
>size was added, this mechanism was still used.

Sounds like they were too lazy to trim the message size down and to
check the size against the interface's MTU. :-(

Re: [Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[Ian D. <ie...@ma...>]

In message <200...@ke...>, ke...@us...
.net writes:
>
>Which leaves us a bit unsure, but that stipulation that the minimum
>should be 576 (a familiar constant) suggests strongly that this is a MTU
>(datagram length) and not a payload length. Therefore it seems that
>FreeBSD bootpd is wrong. Anybody know better?

Yes, the wording is certainly unclear. isc-dhcpd takes the safe
option, and ensures that the whole packet, including the ethernet
header, fits into the client-specified maximum length. FreeBSD's
bootpd should probably do the same.

>However if you wish, you may send me a patch that puts the code you
>suggest inside an #ifdef BROKEN_MTU_IN_BOOTPD.

Etherboot's definition and use of MAX_BOOTP_EXTLEN is actually
quite confusing; it is used to determine the size of the
bootp_extension[] array in struct bootpd_t yet its value includes
the size of the IP and UDP headers. These certainly aren't part of
bootp_extension[]. I have included a patch below that changes
MAX_BOOTP_EXTLEN to actually mean the maximum bootp extension
length.

This patch obviously has the side-effect of avoiding the problem
I reported, but I guess if you want to stick to the one interpretation
of RFC2132 you could use sizeof(struct bootpip_t) instead of
sizeof(struct bootpd_t) when setting up the RFC2132_MAX_SIZE tag:

	RFC2132_MAX_SIZE,2,     /* request as much as we can */
	sizeof(struct bootpip_t) / 256, sizeof(struct bootpip_t) % 256,

However, it would be nicer to just interpret RFC2132 in the way that
is most likely to work with all servers :-)

>Just curious, why is bootpd sending the maximum packet all the time? Is
>it padding the packet with nulls? Surely the clever thing to do would be
>to send only as big a packet as needed.

I'm not sure, but I would guess that it dates back to before the
Maximum DHCP Message Size option existed. The bootpd code in FreeBSD
hasn't changed much since 1994 anyway. It looks as if the old
(probably unofficial) way for a bootp client to specify that it
could handle a long bootp reply was for it to send a request packet
that was as long as the maximum reply it would accept. The bootpd
code just changed the request into a reply and resent it without
changing the length. I guess when support for the DHCP max message
size was added, this mechanism was still used.

Ian

--- etherboot.h.orig	Mon Sep 24 00:54:31 2001
+++ etherboot.h	Mon Sep 24 00:58:11 2001
@@ -76,7 +76,8 @@
 #ifdef	BOOTP_DATA_AT_0x93C00
 #define MAX_BOOTP_EXTLEN	(1024-sizeof(struct bootp_t))
 #else
-#define MAX_BOOTP_EXTLEN	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct bootp_t))
+#define MAX_BOOTP_EXTLEN	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct iphdr)- \
+				 sizeof(struct udphdr)-sizeof(struct bootp_t))
 #endif
 
 #ifndef	MAX_ARP_RETRIES

Re: [Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[<ke...@us...>]

>To get Etherboot 5.0.3 working with FreeBSD 4.4's bootpd, I had to
>change the definition of MAX_BOOTP_EXTLEN from
>
>	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct bootp_t))
>to
>	(ETH_FRAME_LEN-ETH_HLEN-28-sizeof(struct bootp_t))
>
>where the 28 refers to the length of the IP and UDP headers (probably
>better written as "sizeof(struct iphdr) + sizeof(struct udphdr)").
>Without this, the RFC2132_MAX_SIZE field in the bootp request was
>being set to 1500, which is bigger than the largest bootp request
>that can fit in a single ethernet packet. FreeBSD's bootpd (for
>whatever reason) always sends a reply that is as large as the
>specified maximum size, so it gets fragmented on transmision. This
>causes the
>
>	ALERT: got a fragmented packet - reconfigure your server
>
>diagnostic to be triggered and the replies are dropped.
>
>Is this a bug in FreeBSD's bootpd or in Etherboot? I don't know what
>the precise meaning of the RFC2132_MAX_SIZE parameter to tell if
>Etherboot should be subtracting off the ip/udp header length.

Thanks for the report.

I had a look and the option that's being set in the DHCP packets is
Maximum DHCP Message Size (57). RFC2132 says:

<quote>

This option specifies the maximum length DHCP message that it is willing
to accept.  The length is specified as an unsigned 16-bit integer.  A
client may use the maximum DHCP message size option in DHCPDISCOVER or
DHCPREQUEST messages, but should not use the option in DHCPDECLINE
messages.

The code for this option is 57, and its length is 2.  The minimum legal
value is 576 octets.

</quote>

Which leaves us a bit unsure, but that stipulation that the minimum
should be 576 (a familiar constant) suggests strongly that this is a MTU
(datagram length) and not a payload length. Therefore it seems that
FreeBSD bootpd is wrong. Anybody know better?

However if you wish, you may send me a patch that puts the code you
suggest inside an #ifdef BROKEN_MTU_IN_BOOTPD.

Just curious, why is bootpd sending the maximum packet all the time? Is
it padding the packet with nulls? Surely the clever thing to do would be
to send only as big a packet as needed.

[Etherboot-developers] MAX_BOOTP_EXTLEN in Etherboot 5.0.3

[Ian D. <ie...@ma...>]

Hi,

To get Etherboot 5.0.3 working with FreeBSD 4.4's bootpd, I had to
change the definition of MAX_BOOTP_EXTLEN from

	(ETH_FRAME_LEN-ETH_HLEN-sizeof(struct bootp_t))
to
	(ETH_FRAME_LEN-ETH_HLEN-28-sizeof(struct bootp_t))

where the 28 refers to the length of the IP and UDP headers (probably
better written as "sizeof(struct iphdr) + sizeof(struct udphdr)").
Without this, the RFC2132_MAX_SIZE field in the bootp request was
being set to 1500, which is bigger than the largest bootp request
that can fit in a single ethernet packet. FreeBSD's bootpd (for
whatever reason) always sends a reply that is as large as the
specified maximum size, so it gets fragmented on transmision. This
causes the

	ALERT: got a fragmented packet - reconfigure your server

diagnostic to be triggered and the replies are dropped.

Is this a bug in FreeBSD's bootpd or in Etherboot? I don't know what
the precise meaning of the RFC2132_MAX_SIZE parameter to tell if
Etherboot should be subtracting off the ip/udp header length.

Thanks,

Ian

Re: [Etherboot-developers] Problem with mknbi-linux-1.2-4

[<ebi...@ln...>]

Jim McQuillan <ja...@mc...> writes:

> I'm having a problem with using the latest mknbi-linux, version 1.2-4.
> 
> 
> The new development versions of LTSP are using an initrd tacked onto
> the end of a 2.4 kernel.
> 
> During the download, via TFTP, it downloads almost all of it, then
> fails with '(NBI)... Unable to load file'
> Then, it repeats.
> 
> If I use mknbi 1.2-2, it works great.
> 
> I think I remember Eric B. sending a message at least a month ago, about
> mknbi and initrd images, but I don't have that message anymore.
> 
> Anybody remember this problem ?

There are issues on machines with large amounts of memory 1GB+
mknbi was putting the ramdisk too high in memory.  When 2.4.10
comes out it should be safe to load an initrd anywhere above
the kernels initial page table.  So 8MB+

Eric

Re: [Etherboot-developers] Problem with mknbi-linux-1.2-4

[<ke...@us...>]

>  mknbi-linux --output=vmlinuz.ltsp  \
>                 --append="init=/linuxrc "   \
>                 --rootdir="/dev/ram0"        \
>                 bzImage                                \
>                 /tmp/initrd.ltsp.gz
>
>
>bzImage is  658631 bytes
>initrd.ltsp.gz is  864103 bytes
>
>When I run disnbi -e vmlinuz.ltsp, I get this:
>
>-rw-r--r--    1 root     root          512 Sep 19 16:21 nbidir
>-rw-r--r--    1 root     root         4608 Sep 19 16:21 segment0
>-rw-r--r--    1 root     root          512 Sep 19 16:21 segment1
>-rw-r--r--    1 root     root          512 Sep 19 16:21 segment2
>-rw-r--r--    1 root     root         4608 Sep 19 16:21 segment3
>-rw-r--r--    1 root     root       653824 Sep 19 16:21 segment4
>-rw-r--r--    1 root     root       864256 Sep 19 16:21 segment5
>
>I don't know enough about the segments, but it looks like segment4 is 
>the kernel, but
>it is somewhat smaller.

That's ok, the segment excludes the bootblock and the setup blocks.

>And, segment5 is the initrd image, and it is slightly larger.

That's ok, it's padded up 4k.

>I can continue using mknbi-1.2-2, but I figure there may be a problem that
>you all need to take a look at.

That's strange because there have been no changes in that area.

Also I just tested mknbi-1.2.4 with a 5.0.4 bootrom and the images load
with no problems, both NBI and ELF images.

You're sure your kernel is not too large and colliding with Etherboot?
Is it a zImage or a bzImage?

Re: [Etherboot-developers] Problem with mknbi-linux-1.2-4

[Jim M. <ja...@mc...>]

when I tag the image, this is the command line I use:

  mknbi-linux --output=vmlinuz.ltsp  \
                 --append="init=/linuxrc "   \
                 --rootdir="/dev/ram0"        \
                 bzImage                                \
                 /tmp/initrd.ltsp.gz


bzImage is  658631 bytes
initrd.ltsp.gz is  864103 bytes


When I run disnbi -e vmlinuz.ltsp, I get this:

-rw-r--r--    1 root     root          512 Sep 19 16:21 nbidir
-rw-r--r--    1 root     root         4608 Sep 19 16:21 segment0
-rw-r--r--    1 root     root          512 Sep 19 16:21 segment1
-rw-r--r--    1 root     root          512 Sep 19 16:21 segment2
-rw-r--r--    1 root     root         4608 Sep 19 16:21 segment3
-rw-r--r--    1 root     root       653824 Sep 19 16:21 segment4
-rw-r--r--    1 root     root       864256 Sep 19 16:21 segment5

I don't know enough about the segments, but it looks like segment4 is 
the kernel, but
it is somewhat smaller.
And, segment5 is the initrd image, and it is slightly larger.


I can continue using mknbi-1.2-2, but I figure there may be a problem that
you all need to take a look at.

I'd be happy to send you my pieces too, if you need it.

Jim.


Ken Yap wrote:

>>I'm having a problem with using the latest mknbi-linux, version 1.2-4.
>>
>>The new development versions of LTSP are using an initrd tacked onto
>>the end of a 2.4 kernel.
>>
>>During the download, via TFTP, it downloads almost all of it, then
>>fails with '(NBI)... Unable to load file'
>>Then, it repeats.
>>
>>If I use mknbi 1.2-2, it works great.
>>
>
>What happens if you do a disnbi on the image? If  you do a disnbi -e, do
>the kernel and initrd segments match the input?
>
>>I think I remember Eric B. sending a message at least a month ago, about
>>mknbi and initrd images, but I don't have that message anymore.
>>
>>Anybody remember this problem ?
>>
>
>I don't think that's the problem. Sounds like mknbi isn't including all
>of the input.
>
>_______________________________________________
>Etherboot-developers mailing list
>Eth...@li...
>https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

Re: [Etherboot-developers] Problem with mknbi-linux-1.2-4

[<ke...@us...>]

>I'm having a problem with using the latest mknbi-linux, version 1.2-4.
>
>The new development versions of LTSP are using an initrd tacked onto
>the end of a 2.4 kernel.
>
>During the download, via TFTP, it downloads almost all of it, then
>fails with '(NBI)... Unable to load file'
>Then, it repeats.
>
>If I use mknbi 1.2-2, it works great.

What happens if you do a disnbi on the image? If  you do a disnbi -e, do
the kernel and initrd segments match the input?

>I think I remember Eric B. sending a message at least a month ago, about
>mknbi and initrd images, but I don't have that message anymore.
>
>Anybody remember this problem ?

I don't think that's the problem. Sounds like mknbi isn't including all
of the input.

[Etherboot-developers] Problem with mknbi-linux-1.2-4

[Jim M. <ja...@mc...>]

I'm having a problem with using the latest mknbi-linux, version 1.2-4.


The new development versions of LTSP are using an initrd tacked onto
the end of a 2.4 kernel.

During the download, via TFTP, it downloads almost all of it, then
fails with '(NBI)... Unable to load file'
Then, it repeats.

If I use mknbi 1.2-2, it works great.

I think I remember Eric B. sending a message at least a month ago, about
mknbi and initrd images, but I don't have that message anymore.

Anybody remember this problem ?

Thanks,

Jim McQuillan
ja...@lt...

[Etherboot-developers] Re: [Etherboot-users] Etherboot 5.0.4 (production) released

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> + Eric Biederman tried a patch of Preston Wilson's and discovered that
> DI should be prefixed by ES in the test for a PnP BIOS in loader.S to be
> sure.  Furthermore some BIOSes are not fully compliant and we need an
> #ifndef PNP_BUT_NOT_BBS_COMPLIANT to work around that.
 

Hmm.   Shouldn't that by BBS_WITHOUT_PNP?  It is the missing PNP information
block that causes the the autodetection code....

Not that it really matters. :)

Eric

[Etherboot-developers] Etherboot 5.0.4 (production) released

[<ke...@us...>]

I have released Etherboot 5.0.4 at http://etherboot.sourceforge.net/

Changes from 5.0.3:

+ New version of contrib/Diskless-From-NT/furtmayer.html. I mangled the
previous version by forgetting to extract with metamail so it was still
quotable-printable encoded.

+ Renamed do_printf to vsprintf because that's the standard function it
has the same signature as.

+ More patches from Klaus Espenlaub. In his own words:

The patch to add UDP checksums for transmitted packets is attached.
Just don't be surprised if some packet sniffer tells you that the
checksum for the NFS_LOOKUP packets are wrong and that the filename is
truncated.  It's a bug in the sniffer, not in Etherboot.

Oh, and the small change in udpchksum() almost makes up for the
increased code size.

I also rewrote the NFS code to use pointers instead of array accesses.
This reduced the code size by 124 bytes.  Patch attached.

The last patch in this mail fixes misc things: a typo in misc.c
(DOT_PROGRESS instead of BAR_PROGRESS), and twiddle() is only called if
the packet type is IP.  This makes the output nicer - the dots are also
printed in some non-approriate places for ARP reply packets.  The
important packets are IP anyway.

+ The option BOOTP_DATA_AT_0x93C00 is deprecated, in preparation for
expanding the parameter area and the first32.c area.

+ Marty Connor found a typo in index.html, should be: Etherboot can work
with..., not Ethernet can work with... Ooops.

+ Eric Biederman tried a patch of Preston Wilson's and discovered that
DI should be prefixed by ES in the test for a PnP BIOS in loader.S to be
sure.  Furthermore some BIOSes are not fully compliant and we need an
#ifndef PNP_BUT_NOT_BBS_COMPLIANT to work around that.

+ Oops, there's no entry in config.c for the DFE530TX+ even though
there's one in NIC.

MD5 sums:

a15a124cb4e2ca06228d60bf83b2fac6  etherboot-5.0.4.tar.bz2
fcc64ea2438cb27b46be65bee7a4cab1  etherboot-5.0.4.tar.gz
5885f83520cdfa8ff77a3e3938eed504  etherboot-doc-5.0.4.tar.bz2
1af07b1b98a31b78c1747df953853260  etherboot-doc-5.0.4.tar.gz

SHA1 sums:

1c170d51cf2225afa544d7955bedaf016a1510a4  etherboot-5.0.4.tar.bz2
c9d7bd7982ddc5fb6de99f1fc7bfa8263d15f6ad  etherboot-5.0.4.tar.gz
b5ae3aec757578bcf9270ca61dfa6984817b3b9a  etherboot-doc-5.0.4.tar.bz2
c88093e5072f974e1c5f05fe76c540e67b1f5792  etherboot-doc-5.0.4.tar.gz

Re: [Etherboot-developers] Error reporting...

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >What looks like a solution is to send an SNMP trap.  This could be picked
> >up by any standard SNMP software.  What remains are designing the trap
> >and figuring where what MIB to put it under.  Currently the plan is to
> >get an enterprise number of LinuxNetworX and find a place in our MIB tree
> >for it, but I'm not certain if this is the best way to do this.
> >
> >The case where I'm thinking about reporting errors is not when a timeout
> >occurs and a retransmit happens but instead when etherboot gives up.  I'm
> >pretty familiar with that code path :)
> >
> >Comments, critiscims, and especially better ideas are welcome.
> 
> This is an excellent idea.  I think using SNMP is the way to go. Are
> there any MIBs for boot loaders?  Maybe Etherboot can start a trend
> here. In the meantime a private MIB should be ok to start with. What
> statii do you intend to return?

I'm not certain.  I skimmed the standard MIB's and didn't see one for
bootloaders.  Nor did I see an references to TRAP-TYPE or
NOTIFICATION-TYPE that looked hopeful.  This is in the thinking stage
and a month or more out from the actual implementation.

There is a hacked up error reporting interface that so of my coworkers
are implementing now, and I wanted to find an viable alternative
standard interface that we can integrate with etherboot.  Changing
the BOOT ROMS in existing systems is not to be taken lightly.

Mostly I'm thinking of an error saying something failed, and an
error message string.  So TFTP errors can be returned all of the
way up the chain.  But I really haven't thought it out yet.

Eric

Re: [Etherboot-developers] Error reporting...

[<ke...@us...>]

>> Just a thought from a non-network expert, but what about using syslog?
>> It seems like it would be an easy packet to put together and send, and
>> a syslog daemon would be easier to set up than SNMP.  I don't know if
>> you can broadcast a syslog packet or not, so you might have to have an
>> address.  This could be handled as a DHCP option if Etherboot has
>> gotten that far, or maybe a compile-time option for when DHCP is not
>> successful.
>
>That actually sounds a little better.  If syslog has the property
>where you can send a single udp packet that is a valid option as well.
>Especially if I can broadcast a syslog packet...

AFAIK syslog requires a directed packet. So to find the server you would
need to extract it from the DHCP options. BTW, I don't see a syslog
server option offhand, perhaps option 7 (MIT-LCS UDP log server) is the
one to use.  The other reason for preferring SNMP is that syslog is
normally a reporting facility and that one would have to set up
something to take action on the report; special syslog daemon, grep
/var/log/messages, whereas SNMP agents can issue alerts, execute code,
etc. Also syslog is Unixish as pointed out.

Re: [Etherboot-developers] Error reporting...

[<ebi...@ln...>]

Donald J Christensen <dj...@ci...> writes:

> Just a thought from a non-network expert, but what about using syslog?
> It seems like it would be an easy packet to put together and send, and
> a syslog daemon would be easier to set up than SNMP.  I don't know if
> you can broadcast a syslog packet or not, so you might have to have an
> address.  This could be handled as a DHCP option if Etherboot has
> gotten that far, or maybe a compile-time option for when DHCP is not
> successful.

That actually sounds a little better.  If syslog has the property
where you can send a single udp packet that is a valid option as well.
Especially if I can broadcast a syslog packet...

Eric

Re: [Etherboot-developers] Error reporting...

[Peter L. <P.L...@sy...>]

> Just a thought from a non-network expert, but what about using syslog?
> It seems like it would be an easy packet to put together and send, and
> a syslog daemon would be easier to set up than SNMP.

*Clients* should be as simple as possible. It's evil to transfer server
complexity onto clients (and here we are dealing with error conditions -
stuff is going wrong anyway). So if snmp is easier to implement in a
restricted client environment, I'm happy to think for a few minutes more
about setting up snmpd.

snmp also wins as common network monitor s/w (OpenView, Tivoli) uses it,
regardless of platform. syslog is unixish.

Re: [Etherboot-developers] Error reporting...

[Donald J C. <dj...@ci...>]

Just a thought from a non-network expert, but what about using syslog?
It seems like it would be an easy packet to put together and send, and
a syslog daemon would be easier to set up than SNMP.  I don't know if
you can broadcast a syslog packet or not, so you might have to have an
address.  This could be handled as a DHCP option if Etherboot has
gotten that far, or maybe a compile-time option for when DHCP is not
successful.

-Don

"Eric W. Biederman" wrote:
> 
> We are working on improving our error reporting when things go wrong,
> and I've been trying to figure out how to do that for etherboot.  The
> model I'm working with is that of a cluster so in normal practice the
> only connection  between an administrator and a machine is through the
> ethernet connection.
> 
> It is easy enough to hack the code to broadcast a udp packet to a specific
> port and have some proprietary software pick up the error message.  Doing
> it in a way that will benefit everyone using etherboot is trickier.
> 
> What looks like a solution is to send an SNMP trap.  This could be picked
> up by any standard SNMP software.  What remains are designing the trap
> and figuring where what MIB to put it under.  Currently the plan is to
> get an enterprise number of LinuxNetworX and find a place in our MIB tree
> for it, but I'm not certain if this is the best way to do this.
> 
> The case where I'm thinking about reporting errors is not when a timeout
> occurs and a retransmit happens but instead when etherboot gives up.  I'm
> pretty familiar with that code path :)
> 
> Comments, critiscims, and especially better ideas are welcome.
> 
> Eric
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Error reporting...

[<ke...@us...>]

>What looks like a solution is to send an SNMP trap.  This could be picked
>up by any standard SNMP software.  What remains are designing the trap
>and figuring where what MIB to put it under.  Currently the plan is to
>get an enterprise number of LinuxNetworX and find a place in our MIB tree
>for it, but I'm not certain if this is the best way to do this.
>
>The case where I'm thinking about reporting errors is not when a timeout
>occurs and a retransmit happens but instead when etherboot gives up.  I'm
>pretty familiar with that code path :)
>
>Comments, critiscims, and especially better ideas are welcome.

This is an excellent idea.  I think using SNMP is the way to go. Are
there any MIBs for boot loaders?  Maybe Etherboot can start a trend
here. In the meantime a private MIB should be ok to start with. What
statii do you intend to return?

[Etherboot-developers] Error reporting...

[<ebi...@ln...>]

We are working on improving our error reporting when things go wrong, 
and I've been trying to figure out how to do that for etherboot.  The
model I'm working with is that of a cluster so in normal practice the
only connection  between an administrator and a machine is through the
ethernet connection. 

It is easy enough to hack the code to broadcast a udp packet to a specific
port and have some proprietary software pick up the error message.  Doing
it in a way that will benefit everyone using etherboot is trickier.

What looks like a solution is to send an SNMP trap.  This could be picked
up by any standard SNMP software.  What remains are designing the trap
and figuring where what MIB to put it under.  Currently the plan is to
get an enterprise number of LinuxNetworX and find a place in our MIB tree
for it, but I'm not certain if this is the best way to do this.

The case where I'm thinking about reporting errors is not when a timeout
occurs and a retransmit happens but instead when etherboot gives up.  I'm
pretty familiar with that code path :)

Comments, critiscims, and especially better ideas are welcome.

Eric

Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)

[<ke...@us...>]

>>> My gut reaction is not to make this common, and just to insert helper
>>> functions calls.  The reason is that pci devices while they tend to
>>> be fairly standard, they are not always so.  Leaving this logic to the 
>>> device driver sounds a little more reasonable to me.  I don't
>>> think etherboot supports any unreasonable hardware at the moment.
>>And I forgot to say.  If you code it I really don't care how it is dealt
>>with, unless I'm the project maintainer.  If I code it I'll write it my 
>>way :)
>
>I am of two minds on this.  One one hand, since PCI bus initialization is 
>generally done outside the drivers anyway, I suspect his won't make much 
>difference, since most of the code I've looked at seems to be doing the 
>same thing for all the cards that need it.
>
>The sticky part is that we're trying to deal with (possibly) buggy 
>drivers that have failed to properly locate and initialize a card.  Since 
>this seems like a BIOS interface issue and not a driver issue, I'd prefer 
>that the etherboot core deal with it, and let the driver deal with making 
>the card ready to send and receive packets.
>
>I'll be interested in hearing what Ken's take on this is when he gets 
>back.  The other way to look at it is that if we put the logic in the 
>Etherboot core, it might break more things, rather than just the drivers 
>we add the code to.  I don't think this is the case though, since, 
>basically, it's code very similar to what the etherboot core does (or 
>should do) now.

My feeling is make it a helper function until it's judged worthwhile to
be something done for every PCI NIC. It won't make any difference to the
size since a boot image typically contains only one copy of the function
as it will contain only one driver.

Re: [Etherboot-developers] bootrom for Dlink DE530CT+

[<ke...@us...>]

>I am trying to etherboot a
>
>Dlink DE530CT+, a pci network controller.
>
>it uses an dc21041, therefore I'm using the
>tulip driver. The vendor id and pci id are correct.
>
>
>the problem is that this network controller mentioned
>above can only cope with 16 KB boot roms, but the dc21041
>boot rom is 32 KB.
>
>what I've also realised is that the dc21041 boot rom
>(dc21041.lzrom) only needs about 500 bytes more than a
>16 KB boot rom.
>
>my question:
>what are the possibilities I have for reducing the dc21041.lzrom
>size in order to be able to put it into an 16 KB rom?
>reducing the tulip driver? does anyone have experience with that?
>or saving space in any other part?

I find that hard to believe, that a modern NIC would be limited to
16kB. Anyway, there are various options that you can take out, perhaps
you can use only tagged or only ELF images, or you can remove MOTD. Have
a look at Config and see what can remove.

[Etherboot-developers] Redboot and eCos

[Gregg C L. <han...@wo...>]

Hello from Gregg C Levine normally with Jedi Knight Computers
Has anyone tried using the redboot boot images, and the eCos product
from Red Hat, with their Etherboot work?=20
-------------------
Gregg C Levine mailto:han...@wo...
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."=A0 Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi (Perhaps
one of the most powerful of all of the Jedi Knights))
(This company dedicates this E-Mail to Master =
Yoda=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
(Perhaps the other one of the most powerful of all of the Jedi Knights))
And the favorite line by Anonymous "May the Force be with you."=20