etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] CVS COMMIT: Safe booting concept

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

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

> Dig into it, have a lot of fun.

The next question is do we want to look at using IKE
the internet key exchange defined for IPsec.  This would
allow us to switch keys with which we verify the image.

Currently since we don't have a private location to store
a key we cannot participate in a protocol that requires
us to have a well known private/public key pair.

For other things it could be interesting.

Eric

[Etherboot-developers] CVS COMMIT: Safe booting concept

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

>   ---)World Domination Of Etherboot(---

If this is our commonly accepted goal, hopefully we are one step
further. I just commited SafeBoot into CVS (5.1 only, of course)
Documentation and a helpful script are in the safeboot folder in the
contrib section. Openssl required for key management and digital
signatures.

After having some discussion, especially with Ken, I decided to
implement as follows:
A new Config switch named "SAFEBOOTMODE" has been introduced.
Depending on where to read the public key from and where to find the
digital signature, it must be set to an integer value - at this time,
only 0 (zero) is supported which means: public key stored in
include/safeboot_key.h (script creates this file for you, the one in
CVS is just a sample) and the digital signature is stored in an NBI
unused header section - so only tagged .nbi format (not elf....)
supported. With code from 5.0 (md5.c), a checksum over everything but
the dig.signature is created, then the digsig is unpacked and compared
with the checksum. If it does not match, user must explicitely confirm
that booting shall proceed.

I have to mention I used RSAEuro toolkit with their permission - it is
now even free to ex/import in US as RSA is now in Public Domain thanks
to RSA inc.

Dig into it, have a lot of fun.

BTW: I tested it, and it worked.

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

-- 
Merke: Nicht das OS macht dich zu einem interessanteren Gespraechs-
partner, sondern das, was du darueber weisst. Und die Toleranz macht
dich dann noch zu einem liebenswerten Gespraechspartner.
(Buelent Caliskan in de.org.ccc)

RE: [Etherboot-developers] Re: Etherboot-developers digest, Vol 1 #612 - 6 msgs

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

mdc> I agree that we should be pushing toward 5.2 and testing and fixing
issues. 
mdc> I'd really enjoy demoing a stable and flexible 5.2 (with UNDI
support ;) 
mdc> at LinuxWorld Expo in San Francisco in August.

I agree, 5.1 seems pretty stable and we need to move forward.  

mdc> Now, for 5.3, I want to propose that we consider adopting a coding
style and 
mdc> doing some major code reformatting to make it easier for people to
hack. 
mdc> I know from working on drivers that there is a lot of variability
in coding 
mdc> style that makes it somewhat difficult to edit files. Anybody else
feel this way?

I support this also.  Eric's reformatted 5.1 makes adding a driver to
the source tree dead simple compared to 5.0 but the adoption of a coding
style and reformatting/fixing the code would be great.  I know some of
the inconsistencies have slowed me down in the past.

mdc> Now of course this means we have to buckle down and get 5.2 out,
but, 
mdc> hey, that might even be fun. Ken's away for mdc> three weeks and if

mdc> we could test 5.1.8 and squash a few bugs, we could release in June
perhaps.

That should be doable and works nicely because I don't want to spend
much of the summer in my basement!

Tim

Re: [Etherboot-developers] Re: Etherboot-developers digest, Vol 1 #612 - 6 msgs

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

On Saturday, May 3, 2003, at 10:14  AM, Eric W. Biederman wrote:
> My biggest concern is that there currently a lot of people who
> should be using 5.1.x but aren't because it is a development version.
> For example I have had the alignment problem in nic.c come up twice
> now when it is already fixed in 5.1.x.  That and there are some
> drivers we can only support in 5.1.

I agree that we should be pushing toward 5.2 and testing and fixing 
issues. I'd really enjoy demoing a stable and flexible 5.2 (with UNDI 
support ;) at LinuxWorld Expo in San Francisco in August.

Now, for 5.3, I want to propose that we consider adopting a coding 
style and doing some major code reformatting to make it easier for 
people to hack. I know from working on drivers that there is a lot of 
variability in coding style that makes it somewhat difficult to edit 
files. Anybody else feel this way?

Now of course this means we have to buckle down and get 5.2 out, but, 
hey, that might even be fun. Ken's away for three weeks and if we could 
test 5.1.8 and squash a few bugs, we could release in June perhaps.

Thoughts?

Marty

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

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

Re: [Etherboot-developers] Re: Etherboot-developers digest, Vol 1 #612 - 6 msgs

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

"Robb Main" <ma...@ac...> writes:

> > Hmm. I think it's probably best to get to 5.2 soon and to keep the major
> > hacking and portability fixes for 5.3.
> 
> Given the bulk of changes already in 5.1 (and some of Eric's reservations -
> I know he has allot invested in 5.1), I can submit my nic.c split to 5.3. I
> need to get further with memtest86 before I know if I've got the split
> right.

If we weren't on the edge of talking about what little things need
to happen before 5.2 I would be less concerned.  

My biggest concern is that there currently a lot of people who
should be using 5.1.x but aren't because it is a development version.
For example I have had the alignment problem in nic.c come up twice
now when it is already fixed in 5.1.x.  That and there are some
drivers we can only support in 5.1.

Eric

Re: [Etherboot-developers] Uninitialized 'iplen' in nic.c

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

"Robb Main" <ma...@ac...> writes:

> > please use diff -u next time.  It is a whole lot more readable.
> 
> Thanks for the pointer, new patch attached.
> 
> > I have a big problem with the patch.  It does exactly the opposite
> > of what it is supposed to do.  It adds a case where iplen will
> > be used initialized.  In particular you take out the surrounding
> > test for ip.  You cannot have a udp unless it is also an ip packet.
> > But you can sure have a packet that is not a ip packet.
> 
> I hope the problem is due to the difficulty in readability, and not because
> I'm missing something...

Yes.  The change looks correct.  

I still have reservations about fixing things just because
the compiler cannot follow data dependencies.  But there is also
a very practical point of keeping the warning count low in production
code, so the warnings that show up are about real things.

Eric

[Etherboot-developers] Re: Etherboot-developers digest, Vol 1 #612 - 6 msgs

[Robb M. <ma...@ac...>]

> Hmm. I think it's probably best to get to 5.2 soon and to keep the major
> hacking and portability fixes for 5.3.

Given the bulk of changes already in 5.1 (and some of Eric's reservations -
I know he has allot invested in 5.1), I can submit my nic.c split to 5.3. I
need to get further with memtest86 before I know if I've got the split
right.

Robb.

Re: [Etherboot-developers] Uninitialized 'iplen' in nic.c

[Robb M. <ma...@ac...>]

> please use diff -u next time.  It is a whole lot more readable.

Thanks for the pointer, new patch attached.

> I have a big problem with the patch.  It does exactly the opposite
> of what it is supposed to do.  It adds a case where iplen will
> be used initialized.  In particular you take out the surrounding
> test for ip.  You cannot have a udp unless it is also an ip packet.
> But you can sure have a packet that is not a ip packet.

I hope the problem is due to the difficulty in readability, and not because
I'm missing something...
I originally looked into the issue because the compiler was complaining
about iplen potentially being used without being initialized. With the patch
applied, this warning is gone.

I know that the UDP is encapsulated in an IP packet, and the patch changes
the nesting so that the check for UDP occurs only for packets where (ptype
== IP), and hence the check for ip nonzero is no longer necessary in the
check for UDP packets. Originally, ip was set to zero, then set non-zero
within the (ptype==IP) case, and was a precondition for checking for
(ip->protocol == IP_UDP). Instead, the patch simply makes the check for UDP
a subset of the if{} that checks for (ptype == IP). Functionally equivalent,
a whole lot clearer, and it stops the compiler complaining - I usually take
"uninitialized variable" compiler warnings seriously.

The if{} nesting is not well illustrated in the patch - I will send you a
gzip of the patched nic.c privately for review.

> Is this just code motion or is more involved.  We are approaching
> a stable release, and I just don't want to see things break
> at this late stage in the game.

This is code motion - should not be introducing any breakage :-)
The intention is to support the memtest86 usage I mentioned earlier.

Robb.

Re: [Etherboot-developers] Uninitialized 'iplen' in nic.c

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

>Is this just code motion or is more involved.  We are approaching
>a stable release, and I just don't want to see things break
>at this late stage in the game.

Hmm. I think it's probably best to get to 5.2 soon and to keep the major
hacking and portability fixes for 5.3.

Re: [Etherboot-developers] Uninitialized 'iplen' in nic.c

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

"Robb Main" <ma...@ac...> writes:

> Attached patch against etherboot-5.1.8 corrects a coding issue in
> await_reply() that could (in a bizarre set of circumstances) use the
> variable 'iplen' without it being initialized. I doubt this would ever occur
> in practice, but....
> I submit the attached patch for cleanliness.

-EINVAL.

please use diff -u next time.  It is a whole lot more readable.

I have a big problem with the patch.  It does exactly the opposite
of what it is supposed to do.  It adds a case where iplen will
be used initialized.  In particular you take out the surrounding
test for ip.  You cannot have a udp unless it is also an ip packet.
But you can sure have a packet that is not a ip packet.

And that makes me worry a lot about:

> BTW - I have commence hacking NIC.C into pieces (slicing down protocol
> lines). So far, I have created:
> - dhcp.c
> - ip.c
> - mcast.c
> - rarp.c
> - tftp.c
> - udp.c
> , and have retained the balance of (appropriate) code in 'nic.c'.

Is this just code motion or is more involved.  We are approaching
a stable release, and I just don't want to see things break
at this late stage in the game.


Eric

Re: [Etherboot-developers] bootp_t alignment problem

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

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

> >bootpreply = (struct bootp_t *)&nic.packet[ETH_HLEN + sizeof(struct iphdr)
> >+ sizeof(struct udphdr)];
> >
> >how this alignment problem can be taken care of..I was using in header
> >file,
> >struct bootp_t __attribute__ ((aligned(4)))
> >without any difference.
> 
> This one is a nasty one, you've found an alignment bug. 

And it is fixed in 5.1.8.  Itanium fails on every alignment issue.

Why is it that no one trys porting the portable version of etherboot?

> The IP and UDP headers are multiples of 4 but ETH_HLEN is 14.  
> Declaring bootp_t
> aligned does no good because that only aligns instances of bootp_t, not
> buffers that have been cast to bootp_t.  To fix this will require a copy
> of the packet, instead of a cast. 

Or it requires a misaligned ethernet header.  Which is fine because
mac addresses are just 6 byte character arrays (No alignment needed).

[snip possible fix]

> Robb Main is hacking nic.c at the moment so you should probably let him
> make this fix.

Unless there has been a regression nic.c is fine in this regard
at least in 5.1.x.

Eric

Re: [Etherboot-developers] bootp_t alignment problem

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

>bootpreply = (struct bootp_t *)&nic.packet[ETH_HLEN + sizeof(struct iphdr)
>+ sizeof(struct udphdr)];
>
>how this alignment problem can be taken care of..I was using in header
>file,
>struct bootp_t __attribute__ ((aligned(4)))
>without any difference.

This one is a nasty one, you've found an alignment bug. The IP and UDP
headers are multiples of 4 but ETH_HLEN is 14.  Declaring bootp_t
aligned does no good because that only aligns instances of bootp_t, not
buffers that have been cast to bootp_t.  To fix this will require a copy
of the packet, instead of a cast. To avoid having to allocate another
1.5kB buffer statically or on the stack, you can move this memcpy:

        memcpy((char *)BOOTP_DATA_ADDR, (char *)bootpreply, sizeof(struct bootpd_t));

up just after the test for packet length, changing it to:

        memcpy((char *)BOOTP_DATA_ADDR, nic.packet, sizeof(struct bootpd_t));

then assign bootpreply:

	bootpreply = (struct bootp_t *)BOOTP_DATA_ADDR;

Thanks for finding this alignment bug and the endian bugs. Obviously
we've been spoiled by running on little endian and u16 alignment
machines.

Robb Main is hacking nic.c at the moment so you should probably let him
make this fix.

[Etherboot-developers] bootp_t alignment problem

[Ashish a. <ash...@in...>]

Hello,

1. if anyone looking for 82557 nic driver in etherboot for both endiannes
,i can mail it,also i would be correcting the RXFD and TXFD and command
bit as per Linux driver shortly to make it more robust.

2.after receving bootp reply i am facing some problems of struct bootp_t 
alignment..it starts giving me exception , say if i refer to 
bootpreply->bp_yiaddr.s_addr . I observed that structure is obtained by
folowing code,

bootpreply = (struct bootp_t *)&nic.packet[ETH_HLEN + sizeof(struct iphdr)
+ sizeof(struct udphdr)];

how this alignment problem can be taken care of..I was using in header
file,
struct bootp_t __attribute__ ((aligned(4)))
without any difference.

Best Regards,
Ashish Anand

[Etherboot-developers] Uninitialized 'iplen' in nic.c

[Robb M. <ma...@ac...>]

Attached patch against etherboot-5.1.8 corrects a coding issue in
await_reply() that could (in a bizarre set of circumstances) use the
variable 'iplen' without it being initialized. I doubt this would ever occur
in practice, but....
I submit the attached patch for cleanliness.

BTW - I have commence hacking NIC.C into pieces (slicing down protocol
lines). So far, I have created:
- dhcp.c
- ip.c
- mcast.c
- rarp.c
- tftp.c
- udp.c
, and have retained the balance of (appropriate) code in 'nic.c'.
I have modified the Makefile, and have successfully rebuilt, although I have
yet to resolve a slight increase in compiled filesize. Next step is to build
a UDP test message application, then on to memtest86 & syslog.

Cheers,
Robb.

---------------------------------
*** nic_org.c Thu May  1 21:32:52 2003
--- nic.c Thu May  1 21:38:09 2003
***************
*** 1032,1037 ****
--- 1032,1038 ----
    } else continue; /* what else could we do with it? */
    /* Verify an IP header */
    ip = 0;
+   udp = 0;
    if ((ptype == IP) && (nic.packetlen >= ETH_HLEN + sizeof(struct iphdr)))
{
     unsigned ipoptlen;
     ip = (struct iphdr *)&nic.packet[ETH_HLEN];
***************
*** 1061,1081 ****
       nic.packetlen - ipoptlen);
      nic.packetlen -= ipoptlen;
     }
!   }
!   udp = 0;
!   if (ip && (ip->protocol == IP_UDP) &&
!    (nic.packetlen >=
!    ETH_HLEN + sizeof(struct iphdr) + sizeof(struct udphdr))) {
!    udp = (struct udphdr *)&nic.packet[ETH_HLEN + sizeof(struct iphdr)];

!    /* Make certain we have a reasonable packet length */
!    if (ntohs(udp->len) > (ntohs(ip->len) - iplen))
!     continue;

!    if (udp->chksum && udpchksum(ip, udp)) {
!     printf("UDP checksum error\n");
!     continue;
!    }
    }
    result = reply(ival, ptr, ptype, ip, udp);
    if (result > 0) {
--- 1062,1081 ----
       nic.packetlen - ipoptlen);
      nic.packetlen -= ipoptlen;
     }
!    if ((ip->protocol == IP_UDP) &&
!     (nic.packetlen >=
!     ETH_HLEN + sizeof(struct iphdr) + sizeof(struct udphdr))) {
!     udp = (struct udphdr *)&nic.packet[ETH_HLEN + sizeof(struct iphdr)];

!     /* Make certain we have a reasonable packet length */
!     if (ntohs(udp->len) > (ntohs(ip->len) - iplen))
!      continue;

!     if (udp->chksum && udpchksum(ip, udp)) {
!      printf("UDP checksum error\n");
!      continue;
!     }
!           }
    }
    result = reply(ival, ptr, ptype, ip, udp);
    if (result > 0) {
---------------------------------

Re[8]: [Etherboot-developers] RFC: Safe booting concept

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

ebi...@ln...:
> When you get something working I will find it interesting.  This
> definitely
> calls for an extension to mkelf or similar.

Yesterday, I got permission by RSAEURO to use their RSA codebase to develop
some verification code for etherboot (they had some restricitve permissions
earlier, but now don't have problems with their code getting modified,
open-sourced and everything - we only need to notice in the code and in binary
etherboot distributions that make use of it). That means I will work on it as soon
as I'm back to Bonn (off for the long weekend).

Status: MD5 generation works like a charm. My own-coded RSA code did only
hang my CPU on 90% for one hour and returned something very unsimilar to the
result openssl and openpgp produced... :-( That's why I decided to ask RSAEuro,
and yesterday they answered.

Notice follows when code works.

Greetings,

Anselm

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

RE: [Etherboot-developers] Missing NIC Drivers

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

> So our list so far is:
> [...]
> 7) Gigabyte Nics

As it is mentioned: Anyone any experience on RTL8169 chips? I have three of
those boards here, but they won't work with the linux-2.4.20 included driver
(which claims to support those chips, but don't really as it seems). The old
Realtek driver used to crash the kernel and the newer one runs, but the code
seems not to trivial... Would be interesting to hear if some started porting
to etherboot. As Realtek claims, it's not to difficult from rtl8139, even
though it looks harder.

Have a nice holiday,

Anselm

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

[Etherboot-developers] Fwd: eepro100-diag for 82557 receive truncates last one byte

[Ashish a. <ash...@in...>]

Hello,

if it helps i am attaching two eepro100-diag log one imediately after
card is probed and second inside poll routine.


Best Regards,
Ashish Anand

-----Original Message-----
From: "Ashish anand" <ash...@in...>
To: eth...@li...
Date: Wed, 30 Apr 2003 09:07:25 +0530
Subject: 82557 receives one byte less than data put on wire..

Hello,

earlier i had problems of getting my bootp request packet silently
discarded by bootp server.
now I have statred getting bootp reply after takling care of checksum 
problem.I am getting bootp server reply that is of standard 342 byte put 
on wire as shown in ethereal and tcpdump log.

but my nic card reports 341 bytes as count of receive bytes.

it is calculated lke this on my big endian target,
printf ("Got a packet: Len = %d.\n", cpu_to_le16(ACCESS(rxfd)count) &
0x3fff);

I am little confused why my nic card loos one byte , i have also 
confirmed from the the linux driver it is the same way we report receive 
count as in etherboot driver.
in linux we report like.. 
pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff

can anybody hint me ..

Best Regards,
Ashish Anand
where i may need to debug..

Best Regards,
Ashish Aanand


          Inbox (188/43) Drafts (4/4) Sent (174/0) Trash (107/25)    

RE: [Etherboot-developers] Missing NIC Drivers

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

> I assume that any NICS that Linux support have the code to enable the
> encryption available?

AFAIK.

> > There are slightly more stages to getting a wireless NIC initialised;
> you
> > have to join to an access point before you can transmit or receive.
> With
> > the Prism2 cards (the only ones currently supported by Etherboot), you
> > also have to deal with the Info frames (out-of-band information) that
> > arrive, otherwise your card's receive buffer gradually fills up.
> That doesn't sound too bad.

It's not; I just thought I'd document the answer to the question for 
posterity.  :)

> > Also, the current code supports a PLX adaptor, i.e. a wireless PCMCIA
> card
> > slotted into a PCMCIA-to-PCI adaptor card.  This means that you have
> to
> > implement some aspects of PCMCIA: initialising the PLX chip, looking
> for
> > the PCMCIA card and doing the ISA-style initialisation of the PCMCIA
> card
> > before you can even start talking to the actual wireless hardware.
> Hm, I had wondered how difficult one of those would be to implement.  Is
> there enough of the PCMCIA process there to use for other PCMCIA cards
> or is a more general solution required?

No, it wouldn't really generalise, although it would provide a useful 
starting point for implementing PCMCIA support.

Michael

RE: [Etherboot-developers] Missing NIC Drivers

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

> Current code uses no encryption, although this would be fairly trivial
to
> add.  Encryption could always be switched on after you've downloaded
and
> booted the kernel, anyway.

I assume that any NICS that Linux support have the code to enable the
encryption available?
 
> There are slightly more stages to getting a wireless NIC initialised;
you
> have to join to an access point before you can transmit or receive.
With
> the Prism2 cards (the only ones currently supported by Etherboot), you
> also have to deal with the Info frames (out-of-band information) that
> arrive, otherwise your card's receive buffer gradually fills up.

That doesn't sound too bad.
 
> Also, the current code supports a PLX adaptor, i.e. a wireless PCMCIA
card
> slotted into a PCMCIA-to-PCI adaptor card.  This means that you have
to
> implement some aspects of PCMCIA: initialising the PLX chip, looking
for
> the PCMCIA card and doing the ISA-style initialisation of the PCMCIA
card
> before you can even start talking to the actual wireless hardware.

Hm, I had wondered how difficult one of those would be to implement.  Is
there enough of the PCMCIA process there to use for other PCMCIA cards
or is a more general solution required?

RE: [Etherboot-developers] Missing NIC Drivers

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

> >slots).  Of course if I come across a cheap source of GB cards I will
> >pitch in on that.
> 
> well and if your really looking for obscure cards, I have an Intel
PRO100
> Intelligent Server 10/100 card that's up for grabs for anyone brave
enough
> to try it...
>    -Sam
No thanks, if it is not supported by Linux, it's really not worth
looking at.  I am not yet brave enough or foolish enough to try to
displace Becker as a Linux NIC god. ;-)

RE: [Etherboot-developers] Missing NIC Drivers

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

>  *      Cameo           SOHO-GA2000T    SOHO-GA2500T
>  *      D-Link          DGE-500T
>  *      PureData        PDP8023Z-TG
>  *      SMC             SMC9452TX       SMC9462TX
>  *      Netgear         GA621
> 
> But I have only seen one board with it, the 8139s have swamped the
cheap
> NIC market. :-( But the other day I saw a cheap AN983 (Tulip). :-)

Thanks, I will keep an eye out for them.

> If you collect ISA cards, occasionally someone asks about the Intel
> EtherExpress, and the Digital Etherworks series.

Intel EtherExpress - The horror!  I junked a couple of those cards
several years ago.  They would not work on my 486 but I realize now that
it was probably a timer issue.  If I ever come across some again I will
take a look.

So our list so far is:

1) pcnet32
2) tlan
3) ns83820
4) Intel EtherExpress
5) Digital Etherworks
6) Any wireless nic
7) Gigabyte Nics

[Etherboot-developers] 82557 receives one byte less than data put on wire..

[Ashish a. <ash...@in...>]

Hello,

earlier i had problems of getting my bootp request packet silently
discarded by bootp server.
now I have statred getting bootp reply after takling care of checksum 
problem.I am getting bootp server reply that is of standard 342 byte put 
on wire as shown in ethereal and tcpdump log.

but my nic card reports 341 bytes as count of receive bytes.

it is calculated lke this on my big endian target,
printf ("Got a packet: Len = %d.\n", cpu_to_le16(ACCESS(rxfd)count) &
0x3fff);

I am little confused why my nic card loos one byte , i have also 
confirmed from the the linux driver it is the same way we report receive 
count as in etherboot driver.
in linux we report like.. 
pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff

can anybody hint me ..

Best Regards,
Ashish Anand
where i may need to debug..

Best Regards,
Ashish Aanand


          Inbox (188/43) Drafts (4/4) Sent (174/0) Trash (107/25)    

[Etherboot-developers] (no subject)

[Ashish a. <ash...@in...>]

Hello,

earlier i had problems of getting my bootp request packet silently
discarded by bootp server.
now I have statred getting bootp reply after takling care of checksum 
problem.I am getting bootp server reply that is of standard 342 byte put 
on wire as shown in ethereal and tcpdump log.

but my nic card reports 341 bytes as count of receive bytes.

it is calculated lke this on my big endian target,
printf ("Got a packet: Len = %d.\n", cpu_to_le16(ACCESS(rxfd)count) &
0x3fff);

I am little confused why my nic card loos one byte , i have also 
confirmed from the the linux driver it is the same way we report receive 
count as in etherboot driver.
in linux we report like.. 
pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff

can anybody hint me ..

Best Regards,
Ashish Anand
where i may need to debug..

Best Regards,
Ashish Aanand


          Inbox (188/43) Drafts (4/4) Sent (174/0) Trash (107/25)    

Re: [Etherboot-developers] Missing NIC Drivers

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

> >> Then of course there are the wireless NICs which are very popular.
> >Are the wireless pci cards any different from standard pci NICs?
> I should think they look just like any other PCI NIC on the bus, but
> there is the encryption key setting. Anybody know different?

Current code uses no encryption, although this would be fairly trivial to 
add.  Encryption could always be switched on after you've downloaded and 
booted the kernel, anyway.

There are slightly more stages to getting a wireless NIC initialised; you 
have to join to an access point before you can transmit or receive.  With 
the Prism2 cards (the only ones currently supported by Etherboot), you 
also have to deal with the Info frames (out-of-band information) that 
arrive, otherwise your card's receive buffer gradually fills up.

Also, the current code supports a PLX adaptor, i.e. a wireless PCMCIA card 
slotted into a PCMCIA-to-PCI adaptor card.  This means that you have to 
implement some aspects of PCMCIA: initialising the PLX chip, looking for 
the PCMCIA card and doing the ISA-style initialisation of the PCMCIA card 
before you can even start talking to the actual wireless hardware.

Michael

Re: [Etherboot-developers] Missing NIC Drivers

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

>I don't believe so. Its not an EEPRO100A. It is based off of the 82557 
>chipset, but it has an i960 CPU on card for offloading... Supported under 
>NT at one time as I recall...

Ah, any NIC with an onboard processor is generally not supported under
Linux due to unavailable proprietary details.

http://www.scyld.com/network/index.html#notsupported