etherboot-developers — Discussion of developer issues

Re: Re: [Etherboot-developers] Multicast Support

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

> 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...
 
> 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.

What is the correct url?  Is it simply the filename delivered via the dhcpd 
server or some other weirdness?

Tim

Re: [Etherboot-developers] Multicast Support

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

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

> Hi
> 
> Waht is necessary for multicast support.  From What I can tell the drivers need
> to configure the nic for multicast support and any required support code.
> However I am wondering more about how to configure the server for
> testing/development purposes.

Right.  The filters on the nics need to be configured to receive multicast
packets.  That is pretty much a one liner.

> Do I need to specifically tell the Server to use multicast?

Yes.  Most importantly multicast support needs to be built into the kernel.
(Although this is the default).

> Do I need a different tftp server (for some reason this seems familiar).  Are
> there other option/configurations that I need to consider.

The server situation as I know it is:
atftp theoretically has support but it has not been tested against etherboot yet.

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.

Eric

Re: [Etherboot-developers] Multicast Support

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

>Waht is necessary for multicast support.  From What I can tell the drivers ne
>ed to configure the nic for multicast support and any required support code. 
> However I am wondering more about how to configure the server for testing/de
>velopment purposes.
>
>Do I need to specifically tell the Server to use multicast?
>
>Do I need a different tftp server (for some reason this seems familiar).  Are
> there other option/configurations that I need to consider.

You need a tftp server with multicast support. atftp supports RFC2090.
You don't need to do anything special at the server machine other than
run the service with -m. Also I believe the URL of the bootfile has to
indicate you want multicast loading.

What I've forgotten is what kinds of multicast support Eric has put in
the code. I believe he's got RFC2090 support there and also one for use
with lnxi clusters. I'm sure he'll post the story.

[Etherboot-developers] Multicast Support

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

Hi

Waht is necessary for multicast support.  From What I can tell the drivers need to configure the nic for multicast support and any required support code.  However I am wondering more about how to configure the server for testing/development purposes.

Do I need to specifically tell the Server to use multicast?

Do I need a different tftp server (for some reason this seems familiar).  Are there other option/configurations that I need to consider.

Tim

Re: [Etherboot-developers] developers is members only list now

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

>Bochs list of that. However there are it seems too many users of the
>product, who want to comment on things, so they have reversed their
>decision.

That's in fact part of the reason. The Nigerian spam is actually only
sporadic, but there are users who seem to think that a usage problem
or a bug report should be cross-posted to developers. It doesn't make
any difference, the developers read the users list already.

Re: [Etherboot-developers] developers is members only list now

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

Hello from Gregg C Levine
Ken, that's a good decision. I've been trying to convince the gang at the
Bochs list of that. However there are it seems too many users of the
product, who want to comment on things, so they have reversed their
decision.
:I stronly suggest that you do not reverse this.
Gregg C Levine dr...@wo...
"Oh my!" The Second Doctor's nearly favorite phrase.
----- Original Message -----
From: <ke...@et...>
To: "Etherboot developers list" <eth...@li...>
Sent: Friday, August 15, 2003 8:54 PM
Subject: [Etherboot-developers] developers is members only list now


> I've turned on the members only option in Sourceforge's list manager.
>
> It also means for some of you with multiple mail addresses, if you use a
> different posting address from the one you subscribed as, your posting
> will be delayed until one of the list admins notices it in the queue,
> which may be a while.
>
> HTML and multipart/alternative mail is already blocked which accounts
> for the lack of those now.  Unfortunately there is no header that can be
> used to detect Nigerian/Zimbabwe/HK spam at the Sourceforge list
> manager.  See how it goes. If too much legit mail is delayed, I'll may
> reverse this setting.
>
>
>
>

[Etherboot-developers] developers is members only list now

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

I've turned on the members only option in Sourceforge's list manager.

It also means for some of you with multiple mail addresses, if you use a
different posting address from the one you subscribed as, your posting
will be delayed until one of the list admins notices it in the queue,
which may be a while.

HTML and multipart/alternative mail is already blocked which accounts
for the lack of those now.  Unfortunately there is no header that can be
used to detect Nigerian/Zimbabwe/HK spam at the Sourceforge list
manager.  See how it goes. If too much legit mail is delayed, I'll may
reverse this setting.

RE: [Etherboot-developers] RTL8169 gigabit NIC

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

> Has anybody tried making this work with Etherboot? I see some mods in
> the Linux 8139cp.c driver that seem to indicate the hardware has a
> similar structure. There is also a driver written by Realtek which
might
> handle media negotiation better.  What are the prices of NICs based on
> this controller like? Is Realtek stamping them out like cookies like
> they did with the 8139?

I saw a fairly cheap Gig card a while back but the box was sealed, damn
plastic wrapper.  Some searching revealed that DLink has a DL2000 based
NIC available.  It is apparently somehow related to the suncance card
(or maybe that driver was used as the base).

Tim

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

[Etherboot-developers] (no subject)

[deng z. <dz...@ho...>]

 Hi:
     I have a RTL8139 NIC, and if I insert a PXE-BOOTROM, I set the all 
boot device to "disable", the PC boot from PXE-BOOTROM,but if I insert a 
Etherboot-BOOTROM, it can not do so. It must set first boot device to 
"LAN", the pc can boot from the Etherboot-BOOTROM.
     And now I have a PC, if I insert a PXE-BOOTROM, it can boot fine. If I 
insert a Etherboot-BOOTROM, it can not boot, even I set first boot device 
to "LAN", it display "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS 
ENTER", could you tell me why? Thanks very much!

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  

Re: [Etherboot-developers] RTL8169 gigabit NIC

[Anselm M. H. <ans...@gm...>]

> Has anybody tried making this work with Etherboot? I see some mods in
> the Linux 8139cp.c driver that seem to indicate the hardware has a
> similar structure. There is also a driver written by Realtek which might
> handle media negotiation better.  What are the prices of NICs based on
> this controller like? Is Realtek stamping them out like cookies like
> they did with the 8139?
> 
> Sigh, technology moves on, time for me to start looking for a Gb switch.

I have three of these and let me say - some drivers are crap. The rtl8169 in
2.4.21 works fine, as does the latest (at least when I last looked) from
realtek which also runs on 2.4.18. The older realtek driver crashes at heavier
load (YMMV, interrupt handling seemed to be the problem). There are two 8139er
drivers out in the net which claim (directly or by short comments in the
code) to be rtl8169 comptaible, but they are *NOT* (again, when I looked some
months ago). The hardware seems to differ stronger than their developers
expected.
Realtek's documentation on rtl8169 did not bring me much in understanding
the changes to rtl8139. Most parts are similar (but slightly different,
obviuosly), other parts (as media detection, IIRC) are implemented totally
different.
I'd expect the 8169 to become a cheapo. When I bought my cards (Nov 2002),
there wasn't even Linux support for them except that crashing realtek driver
(which changed soon, before I got to using them really, for luck). By now,
there seem to be more 8169er cards on the market, number growing?

I'm not in time to implement it for etherboot. I'm even stuck on PCMCIA as
my laptop goes nuts. Could be the heat (38°C at day) in my flat, so let's wait
another week (sorry).

Greetings,
Anselm

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post

Re: [Etherboot-developers] RTL8169 gigabit NIC

[Hans-Peter J. <hp...@ur...>]

Hi Ken,

On Thursday 14 August 2003 18:48, ke...@et... wrote:
> Has anybody tried making this work with Etherboot? I see some mods in
> the Linux 8139cp.c driver that seem to indicate the hardware has a
> similar structure. There is also a driver written by Realtek which
> might handle media negotiation better.  What are the prices of NICs
> based on this controller like? Is Realtek stamping them out like
> cookies like they did with the 8139?
>
> Sigh, technology moves on, time for me to start looking for a Gb
> switch.

The cheap ones aren't jumbo frame capable yet, unfortunately, but this 
is necessary to squeeze the bones out of it without insanely hogging 
the cpu. 64/66 PCI is helpful, too. In order to play with jumbo frames, 
I've created a linux kernel patch to support the dhcp interface-mtu 
option, BTW. 

Sorry, can't say anything about the RTL8169, using the Pro/1000 MT 
desktop NICs here.

Pete

[Etherboot-developers] RTL8169 gigabit NIC

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

Has anybody tried making this work with Etherboot? I see some mods in
the Linux 8139cp.c driver that seem to indicate the hardware has a
similar structure. There is also a driver written by Realtek which might
handle media negotiation better.  What are the prices of NICs based on
this controller like? Is Realtek stamping them out like cookies like
they did with the 8139?

Sigh, technology moves on, time for me to start looking for a Gb switch.

[Etherboot-developers] Fwd: SCALE 2003

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

If somebody wants to take up the offer. No way I can make it.

------- Forwarded Message

Date: Wed, 13 Aug 2003 23:39:17 -0700
From: ga...@so...
Subject: Your Invitation To SCALE 2003
Message-id: <200...@wi...>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030616-p3 (Debian) at wiked.org

Greetings! I would like to formally invite Etherboot to participate
in the Southern California Linux Expo on November 22nd, at the Los
Angeles Convention Center.

Because your group is non-commercial we will waive the cost of a booth
if you decide to represent Etherboot at SCALE.  More details are available
at http://www.socallinuxexpo.com.  If you have any questions, please
contact me.  

If you're not able to take advantage of this offer, please pass it
along to someone else in your group who may want to represent
Etherboot.

Thank you.
Gareth Greenaway 
SCALE Booth/Exposition Chair

------- End of Forwarded Message

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

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

I propose to break up the sections relating to various headers and
protocols into separate include files, e.g. ip.h, udp.h, tftp.h, dhcp.h,
etc.

I will probably adopt the filenames and structures in the corresponding
files on a recent Linux system. I may even just adopt some include files
more or less as is.  This would probably mean some renaming where the
member names are used in the code.

The idea is to reduce the difference between the names on a GNU system
and those of Etherboot, as well as a step towards IPv6 someday.

[Etherboot-developers] 5.3.0

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

To developers using $CVSROOT/etherboot/etherboot-5.3

Due to cvs import ignoring directories called core and me importing them
separately and getting the places in the directory wrong, you may be
missing arch/{i386,ia64}/core if you did a checkout before now.  So you
should do an update. I think that will fix it, if not a checkout of
those directories should.

[Etherboot-developers] 5.3 CVS opened

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

With the release of 5.2.1, I have imported the initial files into 5.3.
So it's open for business.

Guidelines for use of 5.2 and 5.3 CVS:

5.2 is production so when I release I have to be careful that things
that are broken are fixed and things that work are not broken, or at
they are replaced with something better. This doesn't mean nothing new
can be introduced into 5.2. If the change can be isolated, e.g. a new
driver, things that are conditionally compiled, can be added. The PCMCIA
and TCP code are examples of things that can go into 5.2. But because
the release cycle for 5.2 is longer, you may wish to use 5.3 as a
testbed first.

5.3 is development so the requirements are less stringent. All I ask is
that it compiles and most things work. Breakage is an inherent risk and
part of the testing. I also want to keep the iterations frequent and not
use EXTRAVERSION much if at all. So here's the deal: when you think you
have a significant set of changes committed and want a release, just
post in this list and I will check out the current state, and do sanity
checks on it. I may bounce it back to you if it fails the checks. When
it passes I'll release. You can even do the announcement since you know
best what has changed. I may or may not announce in Freshmeat. Commit
conflicts we'll deal with on a case-by-case basis.

When/if you have backported it into 5.2, just drop a note here.

Re: [Etherboot-developers] http/dns

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

>Doing it correctly, requires a full Javascript interpreter. This is 
>definitly not going to happen in Etherboot ;-) There might be some 
>heuristics we could use to extract the relevant information from 
>commonly used PAC files, though.

I don't think it's worth doing at all. As I pointed out, there is no
fixed filename for the pac file so you have to provide that so it's not
much better than providing the proxy URL. Secondly, if you do a
half-baked job, those people whom it doesn't work for will pester you
for a better heuristic (which will never work for all cases), and you
are then on a treadmill of fixes. One proxy spec for which it won't work
is SOCKS. No, I'm not having socks support in Etherboot.

Re: [Etherboot-developers] http/dns

[Markus G. <ma...@gu...>]

> So well... do you know what the PAC stuff works like? Perhaps it would
> be worth to implement this?

Doing it correctly, requires a full Javascript interpreter. This is 
definitly not going to happen in Etherboot ;-) There might be some 
heuristics we could use to extract the relevant information from 
commonly used PAC files, though.


Markus

Re: Re: [Etherboot-developers] http/dns (was: List of NICs by popularity)

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

> >How far did multicast support get?
> 
> I think Eric is disappointed that nobody fixed up the other drivers to
> do multicast. Hungry for work?

That is on my list for the 3c515, sundance, tlan and pcnet32.  However, I have no idea how to test it.

Tim

Re: Re[4]: [Etherboot-developers] http/dns

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

>So well... do you know what the PAC stuff works like? Perhaps it would
>be worth to implement this?

http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

I don't think so. Essentially you have to parse a Javascript routine
called FindProxyForURL. What's worse is this routine can call various
Javascript functions that are assumed to be available. So you'd end up
requiring a Javascript interpreter.

Also it doesn't have to called proxy.pac, it's whatever the site wants
to call it (so there can be different pac files for different groups),
but the Content-Type must be correct. Which means you then need a means
of specifying what the URL of the pac file is. Might as well specify the
URL of the proxy directly.

PS: No need to CC me separately, I'm on the devel list.

Re[4]: [Etherboot-developers] http/dns

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

Hello Ken,

> Well you'd have to convince the site admin to add option 72 to the DHCP
> server (if it's possible at all with some DHCP servers, e.g. Windoze may
> not support it), and it still doesn't solve the port problem. So you
> might as well do the second ugly thing and that is hardwire the proxy
> into the image with a #define, which of course means the image is only
> usable as long as the web server and proxy don't change name/address or
> port.

So well... do you know what the PAC stuff works like? Perhaps it would
be worth to implement this?

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

Re: Re[2]: [Etherboot-developers] http/dns

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

>I think there are even dhcp options that could be used for that.
>It should be quite reasonable to either set the proxy to the supplied
>address (what about the port, then?) or (though this would be pain,
>probably) ask a www server on port 80 for a proxy.pac if this option
>is set in local dhcp server. I wonder what it originally way thought
>for - should clients really only contact to one,2,..5.. specified http
>server? Does this RFC come from Cuba? :-)

Well you'd have to convince the site admin to add option 72 to the DHCP
server (if it's possible at all with some DHCP servers, e.g. Windoze may
not support it), and it still doesn't solve the port problem. So you
might as well do the second ugly thing and that is hardwire the proxy
into the image with a #define, which of course means the image is only
usable as long as the web server and proxy don't change name/address or
port.

Re[2]: [Etherboot-developers] http/dns

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

Hello Markus,

> Ken Yap wrote:
>> There is still the problem that such strict sites will almost certainly
>> have a HTTP proxy so you will have to handle proxies also.

> Adding support for proxied HTTP connections is trivial and takes almost 
> no code (as long as you don't need full *.pac support). Of course, now 
> we need a way to pass in the address/port of the proxy.

I think there are even dhcp options that could be used for that.
It should be quite reasonable to either set the proxy to the supplied
address (what about the port, then?) or (though this would be pain,
probably) ask a www server on port 80 for a proxy.pac if this option
is set in local dhcp server. I wonder what it originally way thought
for - should clients really only contact to one,2,..5.. specified http
server? Does this RFC come from Cuba? :-)

=== QUOTING
Alexander & Droms           Standards Track                    [Page 23]

RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
8.17. Default World Wide Web (WWW) Server Option
   The WWW server option specifies a list of WWW available to the
   client.  Servers SHOULD be listed in order of preference.
   The code for the WWW server option is 72.  The minimum length for
   this option is 4 octets, and the length MUST always be a multiple of
   4.
    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 72  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--
===

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

-- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .. :w :q :wq :wq! ^d X^?
exit X Q ^C ^c ^? :quitbye  CtrlAltDel  ~~q :~q logout save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d
man help ^C exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."

Re: [Etherboot-developers] http/dns

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

>Do they? Can't we build a floppy image that includes all of our drivers? 
>I thought this was supported with 5.2, but I haven't tested myself.

Well that also highlights the slim advantage of using rom-o-matic to
install Debian. If they are going to download 96kB of an Etherboot
Debian bootstrap, why not download 1440kB of a Debian boot floppy which
contains a real Linux kernel with a real routing table, user space
clients like wget that can handle proxies, a DNS resolver library, etc?
I mean this is pretty much what the SuSE FTP install does, except you
have to type in the IP address of the FTP server.

Re: [Etherboot-developers] http/dns

[Markus G. <ma...@gu...>]

Ken Yap wrote:
> There is still the problem that such strict sites will almost certainly
> have a HTTP proxy so you will have to handle proxies also.

Adding support for proxied HTTP connections is trivial and takes almost 
no code (as long as you don't need full *.pac support). Of course, now 
we need a way to pass in the address/port of the proxy.


Markus