etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] [RFC] Multicast reception....

[Anselm M. H. <an...@ho...>]

[...] URL support

Nice idea. Could be implemented right away, without longer testing, I think.

[...] another protocol than tftp
[...] 10000 clients

So you think in some other scale. Is your protocol RFC'ed? Tested?
I'm interested in that protocol, as in the implementation. Tell me more....

Anselm

Re: [Etherboot-developers] [RFC] Multicast reception....

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

"Anselm Martin Hoffmeister" <an...@ho...> writes:

> > multicast reception mode.  And it seems receiving all multicast
> > packets is widely implemented, and generally easy to setup.
> Another question is how to handle that multicast data.
> 
> > I think I can find a busy network  or two.
> Me, too. Good a dozen clients on an 10MB BNC can be.....making you brew lots
> of coffee. Especially when users start flood pinging (there have to
> winblows-machines on the cable) or transferring gigabytes to the old novell
> server)
> 
> > Given the warning I will start with -DALLMULTI so the driver changes
> > can be enabled/disabled.  For some cards doubtless this will be
> > promiscuous mode.
> 
> You surely are able to enable/disable promiscous mode on the fly, are you?
> So let's just assume - if it is needed at all - that it is only activated
> while retrieving a file (so while one process is near to continuously
> listening on the wire).

An important maintenace feature is to keep the drivers as simple
as possible.  So unless I can confirm there are real world problems
with enabling multicast reception all of the time -DALLMULTI will
be just an option during development.

> > But there is no point in asking for more than I need.
> 
> Please see RFC2090 (tftp multicast). It offers you quite a lot of what you
> need. Can be downloaded from http://www.faqs.org/rfcs/rfc2090.html

It's a good RFC, but it has several problems.  

 - It doesn't fix TFTP's streaming problem.  That is the server has
   challenges to keep the network busy.

 - It requires all clients to be registered.  My design goal is 10,000
   clients.  If something goes wrong 10,000 timeouts can be a real problem.

 - It doesn't handle large files.  (A requirement for using multicast
   transfers for other purposes). 

I already have a tested protocol that is a little simpler on the
server end but it about equivalent on the client end.

> I'm afraid googl'ing didn't hand out any server for that. Perhaps someone
> needs to write one.

atftp almost implements it, but I really don't like it's use of threads.

> Just to describe the additional needs for clients:
> 
> - They have to implement listening on a multicast address arbitrarily given
> by the tftp server
> 
> - They have to keep track of which packages were ok and which were not... 1
> bit to be stored for each 512 bytes of image data to be downloaded. As
> block# is a 16bit-word, we would need 8k of RAM for just the case of an 32MB
> file to be transferred.
> 
> - They have to be able to differentiate between TFTP and TFTP-MCAST files to
> be downloaded...
> Imagine a 1.2kB motd file to be retrieved versus a 1934kB kernel image. In
> first case, initiating an mcast request makes not so much sense,
> does it?

- They have to handle receiving packets in random order.  
 
> So let's assume the multicast ability should be transparent to the rest of
> the prom and should only be programmed inside tftp_getfile (sorry, no idea
> right know how that function is called. Must be something like that) so that
> e.g. the os loader only asks for "/vmlinuz" and does not have any interests
> in the mode how the file comes to the local memory. Do you think it's a good
> idea to have the client always try multicast if that's enabled (remember:
> The server could differentiate after the criterium of [files smaller than
> 10kB -> no multicast], but per specification, multicast servers listen on
> port 1758 instead of 69)? 

There are only 2 cases where multicast is not a win.
1) Very few clients want the file, and lots of people are listening on 
   the multicast ip, (it is being broadcast across a switch).
2) You are in an environment where multicast traffic is much worst than
   unicast trafic.

> We could of course replace the old tftp daemon by
> one that supports multicasting and on the fly decides for us. Or we could
> say all filenames beginning with e.g. the "{" character will be stripped and
> requested by multicast... or both...

Or we can put a URL in the file name field, my preference.  And then
we can compile in the multicast client, the nfs client, and the
classic tftp client, and the the dhcp server decide. 
 
> In any case, it's a lot of work. And it could improve a lot the look&feel,
> what I'm always interested in

It is some work but except for research and protocol scrutinization,
the coding isn't that hard.  The only really hard bit is the work of
stabalization. 

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

[Anselm M. H. <an...@ho...>]

> multicast reception mode.  And it seems receiving all multicast
> packets is widely implemented, and generally easy to setup.
Another question is how to handle that multicast data.

> I think I can find a busy network  or two.
Me, too. Good a dozen clients on an 10MB BNC can be.....making you brew lots
of coffee. Especially when users start flood pinging (there have to
winblows-machines on the cable) or transferring gigabytes to the old novell
server)

> Given the warning I will start with -DALLMULTI so the driver changes
> can be enabled/disabled.  For some cards doubtless this will be
> promiscuous mode.

You surely are able to enable/disable promiscous mode on the fly, are you?
So let's just assume - if it is needed at all - that it is only activated
while retrieving a file (so while one process is near to continuously
listening on the wire).

> But there is no point in asking for more than I need.

Please see RFC2090 (tftp multicast). It offers you quite a lot of what you
need. Can be downloaded from http://www.faqs.org/rfcs/rfc2090.html

I'm afraid googl'ing didn't hand out any server for that. Perhaps someone
needs to write one.
Just to describe the additional needs for clients:

- They have to implement listening on a multicast address arbitrarily given
by the tftp server

- They have to keep track of which packages were ok and which were not... 1
bit to be stored for each 512 bytes of image data to be downloaded. As
block# is a 16bit-word, we would need 8k of RAM for just the case of an 32MB
file to be transferred.

- They have to be able to differentiate between TFTP and TFTP-MCAST files to
be downloaded...
Imagine a 1.2kB motd file to be retrieved versus a 1934kB kernel image. In
first case, initiating an mcast request makes not so much sense, does it?

So let's assume the multicast ability should be transparent to the rest of
the prom and should only be programmed inside tftp_getfile (sorry, no idea
right know how that function is called. Must be something like that) so that
e.g. the os loader only asks for "/vmlinuz" and does not have any interests
in the mode how the file comes to the local memory. Do you think it's a good
idea to have the client always try multicast if that's enabled (remember:
The server could differentiate after the criterium of [files smaller than
10kB -> no multicast], but per specification, multicast servers listen on
port 1758 instead of 69)? We could of course replace the old tftp daemon by
one that supports multicasting and on the fly decides for us. Or we could
say all filenames beginning with e.g. the "{" character will be stripped and
requested by multicast... or both...

In any case, it's a lot of work. And it could improve a lot the look&feel,
what I'm always interested in

Anselm

Re: [Etherboot-developers] [RFC] Multicast reception....

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

Marty Connor <ma...@et...> writes:

> On Fri, 31 May 2002 23:55:36 -0600 Eric W. Biederman
> <ebi...@ln...> wrote:
> >Transmitting multicast packets is trivial and I have completed the
> >implemetation in 10 lines of code.  Receiving multicast packets is
> >more interesting.
> 
> This might somewhat more complicated than it first appears.  Although one
> can make a trivial change at the "kernel" level, every driver may have to
> be changed in order to accomodate this mode of operation.  I seem to
> recall specifically turning off multicast reception in a number of drivers.

Do you recall any specific problems, or performance issues for why you
did that? 

> Some of the older cards we now support may not even reliably be able to
> function in this mode.  Then there's the testing of cards in this new
> mode.  Retransmits and -DCONGESTED may need to be revisted as well.

Cards won't operate reliably if you ask them to receive all packets?

Hmm. Skimming the kernel it has both the concept of interfaces in
promiscuous mode, as well as the concept of interfaces in just
multicast reception mode.  And it seems receiving all multicast
packets is widely implemented, and generally easy to setup.

> Although it sounds like a really cool thing, I advise caution, lots of
> testing, maybe even a revival of the odd-numbered-release branch (maybe
> re-initialized to current production state first or something) to find
> out how well multicast will work.  We also need people who are willing to
> test it in busy networks.

I think I can find a busy network  or two.

> So, my first reaction is "go for it", but carefully ;)

Given the warning I will start with -DALLMULTI so the driver changes
can be enabled/disabled.  For some cards doubtless this will be
promiscuous mode.  But there is no point in asking for more than I
need.  

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

[Marty C. <ma...@et...>]

On Fri, 31 May 2002 23:55:36 -0600 Eric W. Biederman
<ebi...@ln...> wrote:
>Transmitting multicast packets is trivial and I have completed the
>implemetation in 10 lines of code.  Receiving multicast packets is
>more interesting.

This might somewhat more complicated than it first appears.  Although one
can make a trivial change at the "kernel" level, every driver may have to
be changed in order to accomodate this mode of operation.  I seem to
recall specifically turning off multicast reception in a number of drivers.

Some of the older cards we now support may not even reliably be able to
function in this mode.  Then there's the testing of cards in this new
mode.  Retransmits and -DCONGESTED may need to be revisted as well.

Although it sounds like a really cool thing, I advise caution, lots of
testing, maybe even a revival of the odd-numbered-release branch (maybe
re-initialized to current production state first or something) to find
out how well multicast will work.  We also need people who are willing to
test it in busy networks.

So, my first reaction is "go for it", but carefully ;)

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: ma...@et...
    Web: http://www.etherboot.org/

Re: [Etherboot-developers] [RFC] Multicast reception....

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

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

> "Eric W. Biederman" wrote:
> ...
> > My understanding of the guts of NIC is limited, so please check me.  I
> > believe NICs have a hardware filter that allows them to receive just
> > broadcast packets, and packets to their own mac address.  So to
> > receive multicast packets I need open up or disable the filter all
> > together.  The simplest solution appears to be disabling the hardware
> > filter and go into promiscous mode, and then replace the hardware
> > filter with a software filter in await_reply.
> 
> I thought at least some NICs have support for monitoring some number
> of multicast addresses, in addition to broadcast and the local MAC.
> I'm not an expert on NICs, but I think it might be worthwhile to
> check the Linux drivers for some of the newer NICs and see if there
> is anything obvious there as far as multicast support.

I have seen some support but unless there is a compelling reason to
enable it, the complexity and the few percetage points performance
gains are not worth it.
 
> > Does anyone know if there is any communication between NICs and
> > switches about what a NIC is listening for that would make promiscous
> > mode a bad state to put NICs into?
> 
> Other than IGMP, I am not aware of any communication along these lines.
> I think the main problem with promiscuous mode is the additional CPU
> overhead if there is a lot of unwanted traffic.  Since you are doing
> this at boot time, it probably is not a concern, especially if all of
> the clients are booting at the same time, in which case there will be
> very little "unwanted" traffic.

Right.  My research seems to back this up.  And this probably explains
why layer 2 switches have such a hard time with multicast traffic.
All they have enough information to do is broadcast it.  So a switch
has to climb up to layer 3 and start interacting with IGMP to even see
where the multicast traffic should go.  Which make switches a very
interesting tradeoff.

When you are running through a switch generally you don't have much
extraneous network traffic except broadcast traffic, so I don't see a
lot of problems.

The real question is for people with ISA NIC's where the bandwidth to
memory is less than the network bandwidth if loosing a little extra
performance is a problem.  Because I'd like to enable promiscous mode
unconditionally.

Working at Cisco do you know why some switches loose 90% of their
multicast traffic.  I haven't had a chance to investigate this one
personally but I have heard it reported of the Cisco gige switches
amoung others.  With enough clients (11+) multicast is still a win
even at 90% packet loss but it would be nice to not need so many
retransmissions.

Eric

Re: [Etherboot-developers] [RFC] Multicast reception....

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

"Eric W. Biederman" wrote:
...
> My understanding of the guts of NIC is limited, so please check me.  I
> believe NICs have a hardware filter that allows them to receive just
> broadcast packets, and packets to their own mac address.  So to
> receive multicast packets I need open up or disable the filter all
> together.  The simplest solution appears to be disabling the hardware
> filter and go into promiscous mode, and then replace the hardware
> filter with a software filter in await_reply.

I thought at least some NICs have support for monitoring some number
of multicast addresses, in addition to broadcast and the local MAC.
I'm not an expert on NICs, but I think it might be worthwhile to
check the Linux drivers for some of the newer NICs and see if there
is anything obvious there as far as multicast support.

> Does anyone know if there is any communication between NICs and
> switches about what a NIC is listening for that would make promiscous
> mode a bad state to put NICs into?

Other than IGMP, I am not aware of any communication along these lines.
I think the main problem with promiscuous mode is the additional CPU
overhead if there is a lot of unwanted traffic.  Since you are doing
this at boot time, it probably is not a concern, especially if all of
the clients are booting at the same time, in which case there will be
very little "unwanted" traffic.

-Don


-- 
Don Christensen       Senior Software Development Engineer
dj...@ci...         Cisco Systems, Santa Cruz, CA
  "It was a new day yesterday, but it's an old day now."

[Etherboot-developers] [RFC] Multicast reception....

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

When booting large numbers of clients the reception of boot images,
(if you only have one tftp server) has been show to be a bottleneck.

To address that address that I am implemeting a reliable multicast
download protocol in etherboot.

Transmitting multicast packets is trivial and I have completed the
implemetation in 10 lines of code.  Receiving multicast packets is
more interesting.

Implementing IGMP and filtering for multicast addresses we are waiting
for looks like about the same amount of work as ARP.

My understanding of the guts of NIC is limited, so please check me.  I
believe NICs have a hardware filter that allows them to receive just
broadcast packets, and packets to their own mac address.  So to
receive multicast packets I need open up or disable the filter all
together.  The simplest solution appears to be disabling the hardware
filter and go into promiscous mode, and then replace the hardware
filter with a software filter in await_reply.  

Does anyone know if there is any communication between NICs and
switches about what a NIC is listening for that would make promiscous
mode a bad state to put NICs into?

Eric

Re: [Etherboot-developers] TFTP speed

[James N. <jn...@me...>]

Thanks Eric and Ken for the responses so far.  We are using a 3COM LAN
Modem.   The ping times are using around 210ms.   It is taking about 7
minutes to boot up (using the world's smallest 2.4 kernel!).  Using the LAN
Modem is about the slowest possible way, we know -- but it does seem to be a
working solution.   Of course "working" for some would not be using a 33.6
link.   We will probably move to another form of connection, but at the
present time 33.6 is all we have available.      We will look into
installing a disk drive in a workstation.   I'm just glad we don't need to
run X over that 33.6 link.

Thanks,

James


----- Original Message -----
From: "Ken Yap" <ke...@us...>
To: "Etherboot developers list" <eth...@li...>
Sent: Thursday, May 30, 2002 9:20 AM
Subject: Re: [Etherboot-developers] TFTP speed


> >Hi. Not sure if this is the correct place of this post, forgive me if it
is
> >not.    It seems that the TFTP speed downloading a kernel from an
Etherboot
> >workstation using a standard 33.6 modem is very slow.  I know that
33.6kbps
> >is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
>
> You're a brave man to do TFTP across a 33.6kb link.  That's roughly 300
> times slower than 10 Mb. How far is the client from the server network
> wise, i.e. what sort of delay numbers do you get when you do a ping?
> TFTP was never intended for downloading across thin links, the UDP
> protocol is stop and wait. TCP gets its speed from buffering and
> streaming. You really should situate a server near the client.
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] TFTP speed

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

"James Newlin" <jn...@me...> writes:

> Hi. Not sure if this is the correct place of this post, forgive me if it is
> not.    It seems that the TFTP speed downloading a kernel from an Etherboot
> workstation using a standard 33.6 modem is very slow.  I know that 33.6kbps
> is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
> very slowing, which makes us think that maybe there is some sort of sleep
> state in place.   The modems send/recv LEDs are on constantly after the
> kernel is loaded and booted up and the application is running.   Is there
> some sort of built in sleeps or maybe timeouts with TFTP-SERVER.0.17-9.RPM?
> Server is RedHat 7.2.      Would it be worth trying other TFTP servers?
> 

Is the modem code in etherboot, or do you have a router in the middle
talking over the 33.6 link?

If the code is in etherboot I'd love to have a look at it.  Being
able to boot over the serial port has a strange appeal in certain
weird circumstances.

Eric

Re: [Etherboot-developers] TFTP speed

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

"James Newlin" <jn...@me...> writes:

> Hi. Not sure if this is the correct place of this post, forgive me if it is
> not.    It seems that the TFTP speed downloading a kernel from an Etherboot
> workstation using a standard 33.6 modem is very slow.  I know that 33.6kbps
> is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
> very slowing, which makes us think that maybe there is some sort of sleep
> state in place.   The modems send/recv LEDs are on constantly after the
> kernel is loaded and booted up and the application is running.   Is there
> some sort of built in sleeps or maybe timeouts with TFTP-SERVER.0.17-9.RPM?
> Server is RedHat 7.2.      Would it be worth trying other TFTP servers?

TFTP is painfully synchronous.  In particular the  greater your latency
between send and receive the slower TFTP will go.

The options worth investigating are the TFTP block size option, and upping
your interface MTU.   It's a modem it has no natural MTU.  Together you should
be able to handle large packets and at least saturate your link.

Over 100Mbit I can boot in less than a second.

At best for a 2M kernel you are looking at 8 minutes over a 33.6 link.

What kind of speed are you seeing?

Eric

Re: [Etherboot-developers] TFTP speed

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

>Hi. Not sure if this is the correct place of this post, forgive me if it is
>not.    It seems that the TFTP speed downloading a kernel from an Etherboot
>workstation using a standard 33.6 modem is very slow.  I know that 33.6kbps
>is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink

You're a brave man to do TFTP across a 33.6kb link.  That's roughly 300
times slower than 10 Mb. How far is the client from the server network
wise, i.e. what sort of delay numbers do you get when you do a ping?
TFTP was never intended for downloading across thin links, the UDP
protocol is stop and wait. TCP gets its speed from buffering and
streaming. You really should situate a server near the client.

Re: [Etherboot-developers] DHCP option 175

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

>For this case it appears Microsoft has already done the work to map the ISA
>netowrk adapters into the ISA PnP id space. So we might as well use that.

Sounds good, let's use them.

Re: [Etherboot-developers] DHCP option 175

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

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

> >We could assign random arbitrary strings.  But strings that make sense
> >in some other context are probably better because someone can look at
> >it and make sense of it.  And also be able to predict with some degree
> >of accuracy what other ISA chips will have.
> 
> It's not too bad. The number of ISA NICs supported by Etherboot is
> finite and no new ISA NICs are being designed. We could use the
> manufacturer's ID (if available) plus a device ID we invent, possibly
> the ur-chip of the family. E.g.


For this case it appears Microsoft has already done the work to map the ISA
netowrk adapters into the ISA PnP id space. So we might as well use that.

> 
> 	3c509	VENDOR_3COM	509
PNP80f7
> 	3c515	VENDOR_3COM	515
TCM5051
> 	NE2000	'NE'		2000
PNP80d6
> 	EEPRO10	VENDOR_INTEL	10
PNP828A  (Does intel have another PnP ID?)
> 	WD8013	VENDOR_SMC	8013
PNP812a
> 	Lance	VENDOR_AMD	7990
PNP828C (Is there a better mapping?)
> 	CS89x0	VENDOR_CRYSTAL	8900
This is PnP ISA so it has an ID somewhere.
> 	DEPCA	VENDOR_DIGITAL	100
PNP80e7

i82586: PNP812d
ni5010:????
sk_g16:????
smc9000: PNP8228
tiara:???
> 
> It's a different namespace from PCI so clashes won't be a problem. A
> couple of passes on this forum and we'll have the table.

For most of the cards I have found at least a semi-standard
ISA PnP ID which appears appropriate.    So I would suggest
using those, when we can.   If a standard Id can't be found your idea
sounds fine.

Eric
 
***** Network Adapters - PNP8xxx ***********************
PNP8001         Novell/Anthem NE3200
PNP8004         Compaq NE3200
PNP8006         Intel EtherExpress/32
PNP8008         HP EtherTwist EISA LAN Adapter/32 (HP27248A)
PNP8065         Ungermann-Bass NIUps or NIUps/EOTP
PNP8072         DEC (DE211) EtherWorks MC/TP
PNP8073         DEC (DE212) EtherWorks MC/TP_BNC
PNP8078         DCA 10 Mb MCA
PNP8074         HP MC LAN Adapter/16 TP (PC27246)
PNP80c9         IBM Token Ring
PNP80ca         IBM Token Ring II
PNP80cb         IBM Token Ring II/Short
PNP80cc         IBM Token Ring 4/16Mbs
PNP80d3         Novell/Anthem NE1000
PNP80d4         Novell/Anthem NE2000
PNP80d5         NE1000 Compatible
PNP80d6         NE2000 Compatible
PNP80d7         Novell/Anthem NE1500T
PNP80d8         Novell/Anthem NE2100
PNP80dd         SMC ARCNETPC
PNP80de         SMC ARCNET PC100, PC200
PNP80df         SMC ARCNET PC110, PC210, PC250
PNP80e0         SMC ARCNET PC130/E
PNP80e1         SMC ARCNET PC120, PC220, PC260
PNP80e2         SMC ARCNET PC270/E
PNP80e5         SMC ARCNET PC600W, PC650W
PNP80e7         DEC DEPCA
PNP80e8         DEC (DE100) EtherWorks LC
PNP80e9         DEC (DE200) EtherWorks Turbo
PNP80ea         DEC (DE101) EtherWorks LC/TP
PNP80eb         DEC (DE201) EtherWorks Turbo/TP
PNP80ec         DEC (DE202) EtherWorks Turbo/TP_BNC
PNP80ed         DEC (DE102) EtherWorks LC/TP_BNC
PNP80ee         DEC EE101 (Built-In)
PNP80ef         DECpc 433 WS (Built-In)
PNP80f1         3Com EtherLink Plus
PNP80f3         3Com EtherLink II or IITP (8 or 16-bit)
PNP80f4         3Com TokenLink
PNP80f6         3Com EtherLink 16
PNP80f7         3Com EtherLink III
PNP80f8         3Com Generic Etherlink Plug and Play Device
PNP80fb         Thomas Conrad TC6045
PNP80fc         Thomas Conrad TC6042
PNP80fd         Thomas Conrad TC6142
PNP80fe         Thomas Conrad TC6145
PNP80ff         Thomas Conrad TC6242
PNP8100         Thomas Conrad TC6245
PNP8105         DCA 10 MB
PNP8106         DCA 10 MB Fiber Optic
PNP8107         DCA 10 MB Twisted Pair
PNP8113         Racal NI6510
PNP811C         Ungermann-Bass NIUpc
PNP8120         Ungermann-Bass NIUpc/EOTP
PNP8123         SMC StarCard PLUS (WD/8003S)
PNP8124         SMC StarCard PLUS With On Board Hub (WD/8003SH)
PNP8125         SMC EtherCard PLUS (WD/8003E)
PNP8126         SMC EtherCard PLUS With Boot ROM Socket (WD/8003EBT)
PNP8127         SMC EtherCard PLUS With Boot ROM Socket (WD/8003EB)
PNP8128         SMC EtherCard PLUS TP (WD/8003WT)
PNP812a         SMC EtherCard PLUS 16 With Boot ROM Socket (WD/8013EBT)
PNP812d         Intel EtherExpress 16 or 16TP
PNP812f         Intel TokenExpress 16/4
PNP8130         Intel TokenExpress MCA 16/4
PNP8132         Intel EtherExpress 16 (MCA)
PNP8137         Artisoft AE-1
PNP8138         Artisoft AE-2 or AE-3
PNP8141         Amplicard AC 210/XT
PNP8142         Amplicard AC 210/AT
PNP814b         Everex SpeedLink /PC16 (EV2027)
PNP8155         HP PC LAN Adapter/8 TP (HP27245)
PNP8156         HP PC LAN Adapter/16 TP (HP27247A)
PNP8157         HP PC LAN Adapter/8 TL (HP27250)
PNP8158         HP PC LAN Adapter/16 TP Plus (HP27247B)
PNP8159         HP PC LAN Adapter/16 TL Plus (HP27252)
PNP815f         National Semiconductor Ethernode *16AT
PNP8160         National Semiconductor AT/LANTIC EtherNODE 16-AT3
PNP816a         NCR Token-Ring 4 Mbs ISA
PNP816d         NCR Token-Ring 16/4 Mbs ISA
PNP8191         Olicom 16/4 Token-Ring Adapter
PNP81c3         SMC EtherCard PLUS Elite (WD/8003EP)
PNP81c4         SMC EtherCard PLUS 10T (WD/8003W)
PNP81c5         SMC EtherCard PLUS Elite 16 (WD/8013EP)
PNP81c6         SMC EtherCard PLUS Elite 16T (WD/8013W)
PNP81c7         SMC EtherCard PLUS Elite 16 Combo (WD/8013EW or 8013EWC)
PNP81c8         SMC EtherElite Ultra 16
PNP81e4         Pure Data PDI9025-32 (Token Ring)
PNP81e6         Pure Data PDI508+ (ArcNet)
PNP81e7         Pure Data PDI516+ (ArcNet)
PNP81eb         Proteon Token Ring (P1390)
PNP81ec         Proteon Token Ring (P1392)
PNP81ed         Proteon ISA Token Ring (1340)
PNP81ee         Proteon ISA Token Ring (1342)
PNP81ef         Proteon ISA Token Ring (1346)
PNP81f0         Proteon ISA Token Ring (1347)
PNP81ff         Cabletron E2000 Series DNI
PNP8200         Cabletron E2100 Series DNI
PNP8209         Zenith Data Systems Z-Note
PNP820a         Zenith Data Systems NE2000-Compatible
PNP8213         Xircom Pocket Ethernet II
PNP8214         Xircom Pocket Ethernet I
PNP821d         RadiSys EXM-10
PNP8227         SMC 3000 Series
PNP8228         SMC 91C2 controller
PNP8231         Advanced Micro Devices AM2100/AM1500T
PNP8263         Tulip NCC-16
PNP8277         Exos 105
PNP828A         Intel '595 based Ethernet
PNP828B         TI2000-style Token Ring
PNP828C         AMD PCNet Family cards
PNP828D         AMD PCNet32 (VL version)
PNP8294         IrDA Infrared NDIS driver (Microsoft-supplied)
PNP82bd         IBM PCMCIA-NIC
PNP82C2         Xircom CE10
PNP82C3         Xircom CEM2
PNP8321         DEC Ethernet (All Types)
PNP8323         SMC EtherCard (All Types except 8013/A)
PNP8324         ARCNET Compatible
PNP8326         Thomas Conrad (All Arcnet Types)
PNP8327         IBM Token Ring (All Types)
PNP8385         Remote Network Access Driver
PNP8387         RNA Point-to-point Protocol Driver
PNP8388         Reserved for Microsoft Networking components
PNP8389         Peer IrLAN infrared driver (Microsoft-supplied)
PNP8390         Generic network adapter

[Etherboot-developers] TFTP speed

[James N. <jn...@me...>]

Hi. Not sure if this is the correct place of this post, forgive me if it is
not.    It seems that the TFTP speed downloading a kernel from an Etherboot
workstation using a standard 33.6 modem is very slow.  I know that 33.6kbps
is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
very slowing, which makes us think that maybe there is some sort of sleep
state in place.   The modems send/recv LEDs are on constantly after the
kernel is loaded and booted up and the application is running.   Is there
some sort of built in sleeps or maybe timeouts with TFTP-SERVER.0.17-9.RPM?
Server is RedHat 7.2.      Would it be worth trying other TFTP servers?

Thanks for any input,

James

Re: [Etherboot-developers] (unsigned) char bugs

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

>Explicitly specifying "unsigned char" fixes the problem.  I've fixed the
>ones I've come across, but it seems to be common problem in many locations
>- it might be worth eliminating them all with a quick code review at some
>point.

Please fix away. Please do post a list of those files you've fixed so
that I can sync with the CVS archive.

[Etherboot-developers] (unsigned) char bugs

[Michael B. <mb...@fe...>]

I've noticed some strange things happening when DHCP options get longer
than 128 characters (which is easily possible if you use the
extensions-path mechanism to load an external options file via TFTP).
I've tracked it down to the lack of "unsigned" when defining character
types in places like:

char *motd[RFC1533_VENDOR_NUMOFMOTD];

which causes problems in bootmenu.c, at the point

int  i,j,k = 0;
for (i = 0; i < RFC1533_VENDOR_NUMOFMOTD; i++) if (motd[i]) {
  for (j = TAG_LEN(motd[i])

since if the DHCP option length is >=128, j will either be set to the
correct length or (correct length-256), at the discretion of the compiler.

Explicitly specifying "unsigned char" fixes the problem.  I've fixed the
ones I've come across, but it seems to be common problem in many locations
- it might be worth eliminating them all with a quick code review at some
point.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Additional Features in Etherboot

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

Christoph Plattner <chr...@al...> writes:

> Hello !
> 
> One word to:
> 	-DLOCALBOOT_DEINIT_NIC
> 
> This option should no be an option. IMO it is very important to handle
> the full deactivation of all devices touched in the net booting stuff
> and in boot loaders.
> 
> This is true for etherboot (also for GRUB). Before any system is booted,
> kernel is started or a local system is loaded, all devices used or
> touched should be clean deactivated. I also so the effect one day under
> Windows, that it explicitly cannot operate on the NIC. 
> 
> So a good design should include the activation (probing) and a clean
> "close" before jumping to the loaded kernel or to the chainloaded image.

Agreed.

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] Request for Comments

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

>Is this not already possible via judicious use of the extensions-path
>option and the ANSI escape sequence "<esc>['filename'#"?  Without filling
>up the DHCP packet, you can specify a menu file via the extensions-path
>option (or etherboot.extensions-path, if you've already upgraded to
>encapsulated options!) and the menu file can contain escape sequences to
>load icons, backdrops etc from further files.

But this still imposes the need for Etherboot to interpret the graphics,
which means bloat and also makes it harder to fix bugs and upgrade
because Etherboot code is often written in silicon. Also there's no
accounting for taste. One person will be happy with ANSI escapes,
another wants PCX graphics, yet another wants mouse interaction. All
those customisations can be done on the auxilliary program, not the core
of Etherboot. Menus could even be conditional on client info as returned
by DHCP. I would like to see all the menu stuff in Etherboot move into
an auxilliary program and Etherboot be just a loader.

>Very true.  On my system, the only message that is actually visible is
>"Boot from Network or Local?": all the others vanish off the screen before
>you could even read enough to determine the language they were written in!
>
>Maybe it would be worth localizing this single message since it does
>prompt for user interaction?

There are basic defines for these at the top of etherboot.h. Possibly
they should be enclosed in #ifdefs or patch sets developed.

Re: [Etherboot-developers] Re: [Etherboot-users] Request for Comments

[Michael B. <mb...@fe...>]

On Mon, 27 May 2002, Ken Yap wrote:
> >a/ Graphical boot logos
> I would very like to see this but by means of loading a menu program
> which does all the fancy things rather than the way it's done now by
> encoding the menu in the DHCP reply packet, which is becoming rather
> packed with features. I started some work on this but didn't take it
> beyond proof of concept, see mknbi-menu. My intention was next to take
> an interpreter like LUA (www.lua.org) to allow people to write menus as
> LUA scripts. LILO has some nice stuff you might be able to borrow from.
> Unfortunately I have only square tuits at the moment, no round ones (bad
> pun).
> If you pull this off, you will not need some of the additional features
> you proposed to introduce in your previous posting.

Is this not already possible via judicious use of the extensions-path
option and the ANSI escape sequence "<esc>['filename'#"?  Without filling
up the DHCP packet, you can specify a menu file via the extensions-path
option (or etherboot.extensions-path, if you've already upgraded to
encapsulated options!) and the menu file can contain escape sequences to
load icons, backdrops etc from further files.

> >b/ Localized Etherboot version (text output in german, for example)
> Again, a user controllable graphics and menu capability might make this
> issue unimportant. Booting is normally so fast that before you know it,
> the kernel messages have appeared. If you could boot a menu, then before
> you know it, you have a graphics screen, and you just see the Probing,
> etc messages flash past.

Very true.  On my system, the only message that is actually visible is
"Boot from Network or Local?": all the others vanish off the screen before
you could even read enough to determine the language they were written in!

Maybe it would be worth localizing this single message since it does
prompt for user interaction?

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Additional Features in Etherboot

[Christoph P. <chr...@al...>]

Hello !

One word to:
	-DLOCALBOOT_DEINIT_NIC

This option should no be an option. IMO it is very important to handle
the full deactivation of all devices touched in the net booting stuff
and in boot loaders.

This is true for etherboot (also for GRUB). Before any system is booted,
kernel is started or a local system is loaded, all devices used or
touched should be clean deactivated. I also so the effect one day under
Windows, that it explicitly cannot operate on the NIC. 

So a good design should include the activation (probing) and a clean
"close" before jumping to the loaded kernel or to the chainloaded image.

With friendly regards
Christoph P.



Anselm Martin Hoffmeister wrote:
> 
> Moin all around,
> 
> I had some special requirements for etherboot functions, so I changed some
> lines in code. Perhaps it would be a good idea to introduce these changes
> into standard etherboot source tree.... That's what I would like to hear your
> opinion about.
> 
> -DSILENT
> ========
> I added this additional switch which suppresses displaying the menu, password
> question and so on.... shortly said, every output between MOTD and [bootdisk]
> resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can
> be shown, which in our case displays a penguin and a windumb flag offering
> the selection. We don't want text inside that.... And it's really nice.
> Alternatively, submitting the *keep*shut*up*-option via dhcp (more
> complicated) would allow the boot rom to be used this or that way - which we
> don't need at our site, so I took the way of least resistance.
> 
> -DLAST_MOTD_AFTER_BOOTMENU
> ==========================
> The motd option is VERY useful for designing one's own face of etherboot, but
> supported by the load-file-option ^['filename'# we do not need eight lines of
> text, the first one only indeed. We would prefer to display a text string
> after user chose an operating system, which cleans away our graphical logo,
> brings the display back to text mode and says "Lade Betriebssystem:" (load
> operating system). This is done by modifying the [for]-loop in [show_motd] or
> whatever that function is called so it displays only seven motd-lines, and
> after menu selection displaying the 8th motd line, if defined.
> 
> -DHARDDISK_FALLBACK
> ===================
> What happens when the server cannot be reached? At the school computer room
> where my ltsp project is in development, one time or another the linux server
> may be down, so that a fallback to boot Win3.11 is the best alternative (the
> best existing... Win is sooo slow). We don't want the floppy drive to be
> tried for a boot disk, because some of them are broken, and they are
> hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk
> without any other delay would be best. This option inserts two lines of code
> at the location where server_not_reachable would occur. It just calls
> bootdisk(0x80,0) to load operating system from MBR instead of returning to
> BIOS boot.
> 
> -DLOCALBOOT_DEINIT_NIC
> ======================
> I use to test etherboot at home, on my system with some M$-Operating System
> on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the
> function [bootdisk]. Somehow Windumb didn't like being booted by etherboot
> (hanging at some time without further notice.... when trying to find network
> interfaces?), so I tried to investigate why. Entering this switch, which
> de-inits the NIC at the beginning of [bootdisk], made it work.
> 
> -DNO_GFX_COLOUR_CORRECTION
> ==========================
> We really had a hard time finding out what happened to the colours of our
> boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi
> didn't like that. After really frustrating hours of trying and always
> odd-colored logo, we changed to using 16-color images (converted by some
> windumb software to VGA-Color-palette), converting them with a small C
> proggie to ansi and - most important - disabling the colour correction inside
> the ansiesc.c where every colour <= 7 is looked up inside a table and
> replaced by another one. After all this, it went really great. I hope our
> users like it. Obviously, there is need for both measures (disabling colour
> correction AND not using ansitoppm) to work properly.
> 
> That's quite a lot of topic for a single posting, isn't it? But two more
> things I want to mention - kind of request-for-comment. They will go to
> etherboot-users, too.
> a) Is there a need/want for a howto-graphical-boot-logo? We finally managed
> to get one, it was worth the pain. I could also post the program we now use
> to convert bitmap to ansi-graphics.
> b) Is there a need/want for a translated version of etherboot? Our system
> runs in the computer room of a secondary school, and it is kind of teacher's
> policy to prefer german user interfaces... This could be implemented by
> adding symbolic constants instead of strings which would have to be declared
> inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...
> 
> Have a nice day,
> 
> Anselm M. Hoffmeister
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers


-----------------------------------------------------------------
private:  chr...@gm...
company:  chr...@al...

[Etherboot-developers] Re: [Etherboot-users] Request for Comments

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

>a/ Graphical boot logos

I would very like to see this but by means of loading a menu program
which does all the fancy things rather than the way it's done now by
encoding the menu in the DHCP reply packet, which is becoming rather
packed with features. I started some work on this but didn't take it
beyond proof of concept, see mknbi-menu. My intention was next to take
an interpreter like LUA (www.lua.org) to allow people to write menus as
LUA scripts. LILO has some nice stuff you might be able to borrow from.
Unfortunately I have only square tuits at the moment, no round ones (bad
pun).

If you pull this off, you will not need some of the additional features
you proposed to introduce in your previous posting.

>b/ Localized Etherboot version (text output in german, for example)

I understand the motivation for this. However my policy is that the
output text in the source stays in English. The reason is the same as
for the Linux kernel. To be able to report problems with the software,
diagnostic output must be readable by developers. This means, like it or
not, English. However I have no objections to (or any intention of
stopping) localisation patches. You are welcome to use the patch area at
the web site to post such patches. Perhaps you should register as a
developer.

Again, a user controllable graphics and menu capability might make this
issue unimportant. Booting is normally so fast that before you know it,
the kernel messages have appeared. If you could boot a menu, then before
you know it, you have a graphics screen, and you just see the Probing,
etc messages flash past.

[Etherboot-developers] Additional Features in Etherboot

[Anselm M. H. <an...@ho...>]

Moin all around,

I had some special requirements for etherboot functions, so I changed some 
lines in code. Perhaps it would be a good idea to introduce these changes 
into standard etherboot source tree.... That's what I would like to hear your 
opinion about.

-DSILENT
========
I added this additional switch which suppresses displaying the menu, password
question and so on.... shortly said, every output between MOTD and [bootdisk] 
resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can 
be shown, which in our case displays a penguin and a windumb flag offering 
the selection. We don't want text inside that.... And it's really nice.
Alternatively, submitting the *keep*shut*up*-option via dhcp (more 
complicated) would allow the boot rom to be used this or that way - which we 
don't need at our site, so I took the way of least resistance.

-DLAST_MOTD_AFTER_BOOTMENU
==========================
The motd option is VERY useful for designing one's own face of etherboot, but 
supported by the load-file-option ^['filename'# we do not need eight lines of 
text, the first one only indeed. We would prefer to display a text string 
after user chose an operating system, which cleans away our graphical logo, 
brings the display back to text mode and says "Lade Betriebssystem:" (load 
operating system). This is done by modifying the [for]-loop in [show_motd] or 
whatever that function is called so it displays only seven motd-lines, and 
after menu selection displaying the 8th motd line, if defined.

-DHARDDISK_FALLBACK
===================
What happens when the server cannot be reached? At the school computer room 
where my ltsp project is in development, one time or another the linux server 
may be down, so that a fallback to boot Win3.11 is the best alternative (the 
best existing... Win is sooo slow). We don't want the floppy drive to be 
tried for a boot disk, because some of them are broken, and they are 
hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk 
without any other delay would be best. This option inserts two lines of code 
at the location where server_not_reachable would occur. It just calls 
bootdisk(0x80,0) to load operating system from MBR instead of returning to 
BIOS boot.

-DLOCALBOOT_DEINIT_NIC
======================
I use to test etherboot at home, on my system with some M$-Operating System 
on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the 
function [bootdisk]. Somehow Windumb didn't like being booted by etherboot 
(hanging at some time without further notice.... when trying to find network 
interfaces?), so I tried to investigate why. Entering this switch, which 
de-inits the NIC at the beginning of [bootdisk], made it work.

-DNO_GFX_COLOUR_CORRECTION
==========================
We really had a hard time finding out what happened to the colours of our 
boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi 
didn't like that. After really frustrating hours of trying and always 
odd-colored logo, we changed to using 16-color images (converted by some 
windumb software to VGA-Color-palette), converting them with a small C 
proggie to ansi and - most important - disabling the colour correction inside 
the ansiesc.c where every colour <= 7 is looked up inside a table and 
replaced by another one. After all this, it went really great. I hope our 
users like it. Obviously, there is need for both measures (disabling colour 
correction AND not using ansitoppm) to work properly.

That's quite a lot of topic for a single posting, isn't it? But two more 
things I want to mention - kind of request-for-comment. They will go to 
etherboot-users, too.
a) Is there a need/want for a howto-graphical-boot-logo? We finally managed 
to get one, it was worth the pain. I could also post the program we now use 
to convert bitmap to ansi-graphics.
b) Is there a need/want for a translated version of etherboot? Our system 
runs in the computer room of a secondary school, and it is kind of teacher's 
policy to prefer german user interfaces... This could be implemented by 
adding symbolic constants instead of strings which would have to be declared 
inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...

Have a nice day,

Anselm M. Hoffmeister

[Etherboot-developers] Additional Features in Etherboot

[Anselm M. H. <an...@ho...>]

Moin all around,

I had some special requirements for etherboot functions, so I changed some 
lines in code. Perhaps it would be a good idea to introduce these changes 
into standard etherboot source tree.... That's what I would like to hear your 
opinion about.

-DSILENT
========
I added this additional switch which suppresses displaying the menu, password
question and so on.... shortly said, every output between MOTD and [bootdisk] 
resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can 
be shown, which in our case displays a penguin and a windumb flag offering 
the selection. We don't want text inside that.... And it's really nice.
Alternatively, submitting the *keep*shut*up*-option via dhcp (more 
complicated) would allow the boot rom to be used this or that way - which we 
don't need at our site, so I took the way of least resistance.

-DLAST_MOTD_AFTER_BOOTMENU
==========================
The motd option is VERY useful for designing one's own face of etherboot, but 
supported by the load-file-option ^['filename'# we do not need eight lines of 
text, the first one only indeed. We would prefer to display a text string 
after user chose an operating system, which cleans away our graphical logo, 
brings the display back to text mode and says "Lade Betriebssystem:" (load 
operating system). This is done by modifying the [for]-loop in [show_motd] or 
whatever that function is called so it displays only seven motd-lines, and 
after menu selection displaying the 8th motd line, if defined.

-DHARDDISK_FALLBACK
===================
What happens when the server cannot be reached? At the school computer room 
where my ltsp project is in development, one time or another the linux server 
may be down, so that a fallback to boot Win3.11 is the best alternative (the 
best existing... Win is sooo slow). We don't want the floppy drive to be 
tried for a boot disk, because some of them are broken, and they are 
hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk 
without any other delay would be best. This option inserts two lines of code 
at the location where server_not_reachable would occur. It just calls 
bootdisk(0x80,0) to load operating system from MBR instead of returning to 
BIOS boot.

-DLOCALBOOT_DEINIT_NIC
======================
I use to test etherboot at home, on my system with some M$-Operating System 
on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the 
function [bootdisk]. Somehow Windumb didn't like being booted by etherboot 
(hanging at some time without further notice.... when trying to find network 
interfaces?), so I tried to investigate why. Entering this switch, which 
de-inits the NIC at the beginning of [bootdisk], made it work.

-DNO_GFX_COLOUR_CORRECTION
==========================
We really had a hard time finding out what happened to the colours of our 
boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi 
didn't like that. After really frustrating hours of trying and always 
odd-colored logo, we changed to using 16-color images (converted by some 
windumb software to VGA-Color-palette), converting them with a small C 
proggie to ansi and - most important - disabling the colour correction inside 
the ansiesc.c where every colour <= 7 is looked up inside a table and 
replaced by another one. After all this, it went really great. I hope our 
users like it. Obviously, there is need for both measures (disabling colour 
correction AND not using ansitoppm) to work properly.

That's quite a lot of topic for a single posting, isn't it? But two more 
things I want to mention - kind of request-for-comment. They will go to 
etherboot-users, too.
a) Is there a need/want for a howto-graphical-boot-logo? We finally managed 
to get one, it was worth the pain. I could also post the program we now use 
to convert bitmap to ansi-graphics.
b) Is there a need/want for a translated version of etherboot? Our system 
runs in the computer room of a secondary school, and it is kind of teacher's 
policy to prefer german user interfaces... This could be implemented by 
adding symbolic constants instead of strings which would have to be declared 
inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...

Have a nice day,

Anselm M. Hoffmeister

[Etherboot-developers] mkinitrd-net in contribs

[Michael B. <mb...@fe...>]

I have just uploaded mkinitrd-net to etherboot-5.0/contribs/initrd.  From
the README:

mkinitrd-net enables you to use your distribution's stock kernel for
diskless workstations, without having to compile in support for the
relevant network card(s).  It creates an initial ramdisk image containing
the required network-card kernel modules and bootstrap scripts to load the
module, obtain an IP address via DHCP and mount the root filesystem via
NFS.

mkinitrd-net also generates a dhcpd.conf file fragment that can be used to
automate the process of mapping NBI files to clients, based on the PCI IDs
of their network cards.  Etherboot will send the PCI ID of the network
card to the DHCP server in the etherboot-encapsulated-options field
(Etherboot 5.0.7 and newer) and the DHCP server can use this to identify
the correct NBI to point the client towards.

The end result is that:

a) You can avoid the hassle of compiling custom kernels for diskless
   workstations.

b) Diskless workstations will automatically download the correct
   kernel+initrd.

c) You have an easier life! :-)



Instructions are very simple: run "make".  Has been tested on Mandrake 8.2
only; reports of problems with other distributions are very welcome.
Patches to make it work with other distributions even more so.  :-)

Michael Brown
http://www.fensystems.co.uk