etherboot-developers — Discussion of developer issues

RE: [Etherboot-developers] Update - How to Enable Multicast in Etherboot 5.2 using mini-slamd

[Timothy L. <tl...@ro...>]

> >How to Enable Multicast in Etherboot 5.2 using mini-slamd
> 
> There's Anselm's Etherboot wiki, pehaps this should go there too. Link
> from the doco page at www.etherboot.org

Done, I also made a few formatting changes to the Wiki...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

Re: [Etherboot-developers] Re: mini-slamd question

[<ke...@et...>]

Timothy, when you think you're ready to release, I'll cut a 5.3 tarball.

>> And last of all, has anyone else noticed the delay on the list?
>
>I have noticed I can have a whole email exchange with you before it shows
>up the list.  Yes.

Yes. I assume the current round of worms and viruses are clogging up
networks.

Re: [Etherboot-developers] Re: mini-slamd question

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

"Timothy Legge" <tl...@ro...> writes:

> > But my hunch is the packets are getting through just with UDP checksum
> > errors.  So I guess the question is what is causing the packets to
> > become corrupt.
> 
> I reviewed a Becker version of rtl8139.c and found the issue.  I did it
> wrong ;-)

Ok.  Good because that is what it felt like.

> Ken, should we #ifdef the multicast code in 5.2 with ALLMULTI?

What I have done is after I have tested it I have simply removed the #ifdef.
My intention was for it to go away.  In all of the cases I have seen
it is harmless to leave it always enabled, and it makes the drivers simpler
to maintain if they only do one thing.

> And last of all, has anyone else noticed the delay on the list?

I have noticed I can have a whole email exchange with you before it shows
up the list.  Yes.

Eric

RE: [Etherboot-developers] Re: mini-slamd question

[Timothy L. <tl...@ro...>]

> But my hunch is the packets are getting through just with UDP checksum
> errors.  So I guess the question is what is causing the packets to
> become corrupt.

I reviewed a Becker version of rtl8139.c and found the issue.  I did it
wrong ;-)

So, multicast is now confirmed to exist in:

Driver	Version		Confirmed By
--------	----------	-------------------
3c509		5.3			Tim Legge
3c515		5.2			Tim Legge
3c90x		5.2			Eric Biederman and Tim Legge
eepro100	5.2			Eric Biederman and Tim Legge
rtl8139	5.3			Tim Legge
sundance	5.2 cvs		Tim Legge
tlan		5.2 cvs		Tim Legge

For now, I am leaving the code in 5.3.  The changes to the drivers are
minor and have tested Ok with tftp, but I would feel better if a few
people tested it.  I don't particularly relish being known as the guy
who broke all the drivers in 5.2.  

Ken, should we #ifdef the multicast code in 5.2 with ALLMULTI?

Left on my list are:

1) tulip
2) ns8390 (Are those cards even capable)
2) via-rhine
3) pcnet32

Of those, only the tulip and ns8390 seems to be working correctly (at
least for me) in 5.3 so I will need to dig into a couple of them.  Did
some one report issues with the via-rhine with a rev A3-1 DLink
DFE-530TX?

And last of all, has anyone else noticed the delay on the list?

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

[Etherboot-developers] Rom-o-matic feature request

[Paolo S. <al...@io...>]

Hi all!

The new etherboot should allow to build auto-detecting floppy
("etherboot", "etherboot-pci"); can this feature be usable also from the
rom-o-matic web site?

It would be really useful to produce auto-detecting boot floppy! (ie
"etherboot.zdsk")

Bye!

Paolo

[Etherboot-developers] Re: mini-slamd question

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

"Timothy Legge" <tl...@ro...> writes:
> 
> I have made some progress.  I now receive a lot of UDP checksum errors
> and retransmissions see attached tar however the Linux kernel boots
> correctly.  Are these retransmissions normal?

The retransmissions are correct behavior of the protocol when packet
loss occurs.  They are undesirable.  There are a couple possible
causes of:

Kernel with broken multicast support. 2.4.early had this problem.
Broken switch.
Transmitter that transmits packets faster than the receiver can
  receive them.  (mini-slamd transmits packets as fast as it can...)

But my hunch is the packets are getting through just with UDP checksum
errors.  So I guess the question is what is causing the packets to
become corrupt.

Eric

Re: [Etherboot-developers] Update - How to Enable Multicast in Etherboot 5.2 using mini-slamd

[<ke...@et...>]

>How to Enable Multicast in Etherboot 5.2 using mini-slamd

There's Anselm's Etherboot wiki, pehaps this should go there too. Link
from the doco page at www.etherboot.org

[Etherboot-developers] RE: mini-slamd question

[Timothy L. <tl...@ro...>]

> The NACK lists the packets that have not been received so if you
> are seeing 0-20 it looks like nothing was received.
> 
> It does look like the communication by the unicast side band
> channel is working so etherboot is getting the size of the image
> to download.
> 
> Good luck finding the unicast enable for the rtl8139.
> 

I have made some progress.  I now receive a lot of UDP checksum errors
and retransmissions see attached tar however the Linux kernel boots
correctly.  Are these retransmissions normal?

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 
  

[Etherboot-developers] Update - How to Enable Multicast in Etherboot 5.2 using mini-slamd

[Timothy L. <tl...@ro...>]

How to Enable Multicast in Etherboot 5.2 using mini-slamd

1) Edit src\Config and add the following compile flags

	# Enable Multicast Support
	CFLAGS+=	-DALLMULTI -DMULTICAST_LEVEL1 -DMULTICAST_LEVEL2

	# Download files via mini-slapd
	CFLAGS+=	-DDOWNLOAD_PROTO_SLAM
	
3) Compile mini-slamd 

	cd etherboot\etherboot-5.1\contrib\mini-slamd\
	make
	
4) Modify /etc/dhcpd.conf

	Set the file name for the NIC to:
		filename	"slam-d:///"; 

	or
		filename
"x-slam://192.168.0.253:10000/239.255.1.1:10000";

	where:

		The first IP is the IP of your server. 
		The second IP is the multicast IP and udp port to use.  
			(as hard coded in mini-slamd)
	
		
5) Run mini-slamd with the filename to be delivered as the parameter:

	etherboot/etherboot-5.1/contrib/mini-slamd/mini-slamd
/tftpboot/lts/vmlinuz-2.4.19.bgz

mini-slamd Facts:

- A lot less dots appear on the screen using slamd

- There is a one hop limit on the packets, to limit the distance the
  packets will travel.  So the packets are non routable.

- If you compile mini-slamd with -DDEBUG=1 you will get some debugging
  output from the server.  

Current Drivers Multicast Enabled:

Driver	Version		Confirmed By
--------	----------		-------------------
eepro100	5.2			Eric Biederman and Tim Legge
3c90x		5.2			Eric Biederman
tlan		5.2 cvs		Tim Legge
sundance	5.2 cvs		Tim Legge
3c515		5.2			Tim Legge

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

Re: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

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

"Timothy Legge" <tl...@ro...> writes:

> > Except with respect to the rare switches that are broken with respect
> > to multicast traffic (and drop an huge number of packets) mini-slamd
> > should be as fast or faster than tftp.
> > 
> > How many dots do you get before a transmission completes?
> 
> I am probably subjectively wrong.  A half dozen or so dots appear.  I
> think I was concerned that at the speed they appear it would take 15
> minutes to fill the screen like tftp does.  I have since realized that
> linux starts after a half dozen or so dots...

Sounds about right. But this is probably a worth addition to the howto.
Are you running at 10Mbps or at 100Mbps?

I just repeated the test to refresh my memory and I get:
Loading x-slam://192.168.0.253:10000/239.255.1.1:10000 ......(ELF)... done
My 1.7M images loads in about a second, after the DHCP reply is received.

A couple of more facts that may be useful:

- There is a one hop limit on the packets, to limit the distance the
  packets will travel.  So the packets are non routable.

- If you compile mini-slamd with -DDEBUG=1 you will get some debugging
  output from the server.  

Eric

RE: [Etherboot-developers] Multicast Support

[Timothy L. <tl...@ro...>]

> Excellent work. I'd like to see the changes in both 5.2 and 5.3. It
> shouldn't break anything in 5.2. But if you want to test in 5.3 first,
> that's fine with me too. I'd like to release 5.3.0 with Georg Baum's
> improved e1000, your multicast fixes and my factored etherboot.h.

Ah Yes, I forgot about 5.3.  I have obviously tested both multicast and
tftp prior to submitting the patches, but you are correct, something
else may break however unlikely.

Tim
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

RE: [Etherboot-developers] Multicast Support

[Timothy L. <tl...@ro...>]

> Cool.  This is better than my plan of simply enabling multicast
reception
> and not testing the drivers, since I don't have the cards.

I don't have all of them, but can probably add multicast and test (with
at least one NIC):

Pcnet32
Lance
3c515
3c509
3c595
tulip
via-rhine
ns8390

And maybe a couple of others.

Tim


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

RE: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

[Timothy L. <tl...@ro...>]

> Except with respect to the rare switches that are broken with respect
> to multicast traffic (and drop an huge number of packets) mini-slamd
> should be as fast or faster than tftp.
> 
> How many dots do you get before a transmission completes?

I am probably subjectively wrong.  A half dozen or so dots appear.  I
think I was concerned that at the speed they appear it would take 15
minutes to fill the screen like tftp does.  I have since realized that
linux starts after a half dozen or so dots...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

Re: [Etherboot-developers] Multicast Support

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

"Timothy Legge" <tl...@ro...> writes:

> > The eepro100, and the 3c90x drivers should both work.
> > 
> 
> We can now add the tlan and sundance drivers to this list.  As Eric said
> the process of updating the drivers is quite simple once you follow my
> mini-howto to setup Etherboot for multicast for testing.
> 
> I will update pcnet32 and 3c515 next and I will probably move on to the
> other drivers (if there are no objections from the driver authors).

Cool.  This is better than my plan of simply enabling multicast reception
and not testing the drivers, since I don't have the cards.

Eric

Re: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

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

"Timothy Legge" <tl...@ro...> writes:

> > > 7) Boot Etherboot and watch it download from mini-slamd (this is
> quite
> > > slow on a 486 with a 3c509 isa card)
> 
> No, my development box and server is my trusty 486.  The 3c509 is the
> card that slamd is transmitting via.  

Hmm.  Then I am at a lose to explain the slowness except to note that
etherboot only prints progress dots when it transmits a packet and with
slam it needs to transmit many fewer packets so this might be subjective.

Except with respect to the rare switches that are broken with respect
to multicast traffic (and drop an huge number of packets) mini-slamd
should be as fast or faster than tftp.

How many dots do you get before a transmission completes?

Eric

Re: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

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

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

> >> It got removed from the contrib directory?  Or does it just live in
> >CVS?
> >> Anyway at least it exists and is available.
> >
> >It just does not seem to be in the contrib. directory in the cvs of 5.2
> 
> Looks like my fault, I must not have updated my contrib tree from CVS
> when I was making 5.1 releases and so it didn't carry over to 5.2. Will
> check it out and add to 5.2 and 5.3 shortly.

Thank you.  I am pretty certain that mini-slamd was not the only addition
to the contrib directory during 5.1.

Eric

Re: [Etherboot-developers] Multicast Support

[<ke...@et...>]

>We can now add the tlan and sundance drivers to this list.  As Eric said
>the process of updating the drivers is quite simple once you follow my
>mini-howto to setup Etherboot for multicast for testing.

Excellent work. I'd like to see the changes in both 5.2 and 5.3. It
shouldn't break anything in 5.2. But if you want to test in 5.3 first,
that's fine with me too. I'd like to release 5.3.0 with Georg Baum's
improved e1000, your multicast fixes and my factored etherboot.h.

>I will update pcnet32 and 3c515 next and I will probably move on to the
>other drivers (if there are no objections from the driver authors).

Don't worry, if they object I'll come around with a baseball bat. :-)

Re: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

[<ke...@et...>]

>> It got removed from the contrib directory?  Or does it just live in
>CVS?
>> Anyway at least it exists and is available.
>
>It just does not seem to be in the contrib. directory in the cvs of 5.2

Looks like my fault, I must not have updated my contrib tree from CVS
when I was making 5.1 releases and so it didn't carry over to 5.2. Will
check it out and add to 5.2 and 5.3 shortly.

RE: [Etherboot-developers] Multicast Support

[Timothy L. <tl...@ro...>]

> The eepro100, and the 3c90x drivers should both work.
> 

We can now add the tlan and sundance drivers to this list.  As Eric said
the process of updating the drivers is quite simple once you follow my
mini-howto to setup Etherboot for multicast for testing.

I will update pcnet32 and 3c515 next and I will probably move on to the
other drivers (if there are no objections from the driver authors).

Regards

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

RE: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

[Timothy L. <tl...@ro...>]

> > 2) Replace the following
> > 	# Download files via TFTP
> > 	CFLAGS+=	-DDOWNLOAD_PROTO_TFTP
> >
> > 	with
> >
> > 	# Download files via mini-slapd
> > 	CFLAGS+=	-DDOWNLOAD_PROTO_SLAM
> 
> You can just add -DDOWNLOAD_PROTO_SLAM the options are not exclusive.

I will update my mini doc.

> It got removed from the contrib directory?  Or does it just live in
CVS?
> Anyway at least it exists and is available.

It just does not seem to be in the contrib. directory in the cvs of 5.2

> > 7) Boot Etherboot and watch it download from mini-slamd (this is
quite
> > slow on a 486 with a 3c509 isa card)
> 
> mini-slamd transmit the entire file as fast as it can.  Which likely
> means that the old isa card has to get the file retransmitted multiple
> times.  The protocol is flexible enough to allows for the implementing
> windowing and slow start in the server to resolve the worst of this
> but no one has done it.
> 
> So you have added support to the 3c509 driver?

No, my development box and server is my trusty 486.  The 3c509 is the
card that slamd is transmitting via.  

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

Re: [Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

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

"Timothy Legge" <tl...@ro...> writes:

> Hi
> 
> I decided to write this up based on what I gleaned from Eric and
> experimentation.  Eric, please jump in with any corrections:

Ok.  It sounds pretty good.
 
> How to Enable Multicast in Etherboot 5.2 using mini-slamd
> 
> 1) Edit src\Config
> 	Add the following compile flags
> 	CFLAGS+=	-DALLMULTI -DMULTICAST_LEVEL1 -DMULTICAST_LEVEL2
> 
> 	
> 2) Replace the following 
> 	# Download files via TFTP
> 	CFLAGS+=	-DDOWNLOAD_PROTO_TFTP
> 	
> 	with 		
> 	
> 	# Download files via mini-slapd
> 	CFLAGS+=	-DDOWNLOAD_PROTO_SLAM

You can just add -DDOWNLOAD_PROTO_SLAM the options are not exclusive.


> 3) Compile mini-slamd (This is not in the 5.2 release)
> 	cd etherboot\etherboot-5.1\contrib\mini-slamd\
> 	make

It got removed from the contrib directory?  Or does it just live in CVS?
Anyway at least it exists and is available.

> 4) Modify /etc/dhcpd.conf
> 	Set the file name for the NIC to:
> 		filename	"x-slam:///";
> 		
> 5) Run mini-slamd with the filename to be delivered as the parameter:
> 
> 	etherboot/etherboot-5.1/contrib/mini-slamd/mini-slamd
> /tftpboot/lts/vmlinuz-2.4.19.ltsp-1
> 
> 6) Compile a multicast enabled rom:
> 	make bin/eepro100.rom
> 
> 7) Boot Etherboot and watch it download from mini-slamd (this is quite
> slow on a 486 with a 3c509 isa card)

mini-slamd transmit the entire file as fast as it can.  Which likely
means that the old isa card has to get the file retransmitted multiple
times.  The protocol is flexible enough to allows for the implementing
windowing and slow start in the server to resolve the worst of this
but no one has done it.

So you have added support to the 3c509 driver?

Eric

[Etherboot-developers] How to Enable Multicast in Etherboot 5.2 using mini-slamd

[Timothy L. <tl...@ro...>]

Hi

I decided to write this up based on what I gleaned from Eric and
experimentation.  Eric, please jump in with any corrections:

How to Enable Multicast in Etherboot 5.2 using mini-slamd

1) Edit src\Config
	Add the following compile flags
	CFLAGS+=	-DALLMULTI -DMULTICAST_LEVEL1 -DMULTICAST_LEVEL2

	
2) Replace the following 
	# Download files via TFTP
	CFLAGS+=	-DDOWNLOAD_PROTO_TFTP
	
	with 		
	
	# Download files via mini-slapd
	CFLAGS+=	-DDOWNLOAD_PROTO_SLAM
	
3) Compile mini-slamd (This is not in the 5.2 release)
	cd etherboot\etherboot-5.1\contrib\mini-slamd\
	make
	
4) Modify /etc/dhcpd.conf
	Set the file name for the NIC to:
		filename	"x-slam:///";
		
5) Run mini-slamd with the filename to be delivered as the parameter:

	etherboot/etherboot-5.1/contrib/mini-slamd/mini-slamd
/tftpboot/lts/vmlinuz-2.4.19.ltsp-1

6) Compile a multicast enabled rom:
	make bin/eepro100.rom

7) Boot Etherboot and watch it download from mini-slamd (this is quite
slow on a 486 with a 3c509 isa card)


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003
 

[Etherboot-developers] 5.3 commit: etherboot.h breakup

[<ke...@et...>]

I have checked in a bunch of new files in include/ which are bits of
etherboot.h broken up along protocol lines following the usual names in
a Linux include tree, e.g. in.h, ip.h, if_ether.h, etc. So you will see
a bunch of updates next time you run cvs update.

Re: [Etherboot-developers] Multicast Support

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

"Timothy Legge" <tl...@ro...> writes:

> > An extract from my dhcpd.conf file is:
> > 
> > filename "x-slam://192.168.20.252:10000/239.255.1.1:10000";
> > 
> 
> I guess to be sure I should start from a known configuration.  Are there
> any current drivers (other that GHz drivers) that you have tested to
> work with multicast?

The eepro100, and the 3c90x drivers should both work.

When I initially added the support I added a define to all of the drivers
to complain if they had not been modified to receive multicast packets.
And really anything with that define cleared should work.

Eric

Re: [Etherboot-developers] Multicast Support

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

Timothy Legge <tl...@ro...> writes:

> > The server situation as I know it is:
> > atftp theoretically has support but it has not been tested against etherboot 
> yet.
> 
> Maybe I will try it after the mini-slamd.  If it has not been tested I could 
> have problems...

Right.  The code was tested but against a different RFC2090 implementation.
  
> > There is also the stupid mini-slamd server in the contrib directory.  
> > Which because of it's nature requires virtually no setup.  You supply
> > the correct url to etherboot.

For mini-slamd or atftp if you have multiple interfaces you need to 
make certain the multicast traffic is routed to the proper interface.
 
> What is the correct url?  Is it simply the filename delivered via the dhcpd 
> server or some other weirdness?

The url is delivered in the DHCP filename address.  The decision was
made that in etherboot if we are not doing tftp we will deliver a URL
in place of the normal filename. 

An extract from my dhcpd.conf file is:

filename "x-slam://192.168.20.252:10000/239.255.1.1:10000";

You should be able to just get away with just "x-slam:///", and have
all of the defaults be taken.  The first IP is the IP of your
server. The second IP is the multicast IP and udp port to use.  And
those are hard coded in mini-slamd.

I think the slam protocol is simpler, and more scalable than RFC2090.
Though the simplicity factor is a hard thing to test.

Eric