etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] currticks function

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

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

> >tfptd) and the problem persits. However, the behaviour of the system 
> >changes whenever I modify the currticks() function. :( Any idea ?
> 
> Sorry no. You're the one closest to the hardware. But I suggest you
> don't get hung up on the behaviour of the currticks constant. Collect
> more evidence, snoop on packets, put in printf statements, etc.
> 
> Is the Infineon an x86 architecture or are you the first to port it to a
> different architecture? If so, watch out for latent structure alignments
> and byte order bugs. It should be interesting.

The TriCore is a 32bit embedded RISC processor competing with the ARM.
http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=30926&cat_oid=-8362

It is little endian, and there are some alignment constraints.

So congratulations on the first non-x86 port ar in order.

Beyond this, it could be that there is a driver bug.  Drivers being
more susceptible than the core to differences in the hardware.

With respect to currticks you will run into problems if it rolls over.
overflows.  Though it looks like you are probably o.k.

The load_timer2  logic is also suspect.  I don't suppose you
have an x86 compatiable timer do you?

Beyond that my best suggestion is to use tcpdump and get a packet
trace from another machine on the same network segment.  That and to
verify that the tftp transfer works from another client machine,
plugged into the same network port. 

If you are timing out I would suggest defing CONGESTED and see if
retransmissions help.  It could be just that your network loses
some packets.

Alternatively it could be a driver bug where it either drops packets
being transmitted or received.

My best guess is that playing with the timeout simply varies when
another problem is detected.

Anyway if you can pinpoint where in a tftp transfer the code is
failing we may be able to point you in some productive directions.

Another possibility is that the image you are loading is overwriting
part of etherboot. 

Eric

Re: [Etherboot-developers] currticks function

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

>tfptd) and the problem persits. However, the behaviour of the system 
>changes whenever I modify the currticks() function. :( Any idea ?

Sorry no. You're the one closest to the hardware. But I suggest you
don't get hung up on the behaviour of the currticks constant. Collect
more evidence, snoop on packets, put in printf statements, etc.

Is the Infineon an x86 architecture or are you the first to port it to a
different architecture? If so, watch out for latent structure alignments
and byte order bugs. It should be interesting.

Re: [Etherboot-developers] currticks function

[Fotis A. <fa...@te...>]

>
>
>>all the bits in the low half of the timer and can do your arithmetic
>>
I have used long long for the declarations of the variables. I also 
checked out the value that the currticks() returned, during an 
assembly-implemented udelay() function, for 1 second, and I found out 
that the difference before and after the delay is [18]. I have tried it 
with various tftpd servers (2 different Win tftpd servers and the Linux 
tfptd) and the problem persits. However, the behaviour of the system 
changes whenever I modify the currticks() function. :( Any idea ?

Fotis Andritsopoulos

>>
>>with 32 bit variables.
>>
>>Also consider the possibility you have tftp server problems.
>>
>>When you have this alternate implementation working, please submit it
>>for inclusion (#ifdefed of course). Thanks.
>>
-- 
"Whom ever Controls your Perception of Reality Controls You"

Re: [Etherboot-developers] currticks function

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

>With the above implementation the bootp process works fine. However, I 
>have *many* problems with the tftp process. For example, the client 
>starts downloading the kernel image after at least 2-3 requests. For the 
>first requests (at least) the downloading fails due to timeouts. Many 
>times, the kernel downloading (even if it starts), stops before finish 
>succesfully (because the etherboot does not "read" a TFTP_DATA packet 
>from the tftpd). Moving arround with different values into the currticks 
>function, (especially with the value 182), I realized that the behaviour 
>of the system *changes*. I didn't find any documentation on currticks() 
>function and I don't know which has to be the value that it returns each 
>time is called, the period, the resolution etc. Just from a comment that 
>I found on cs89x0.c driver, I thought that it has a period of 55ms. Is 
>this true ? Is the tftp process so sensitive in time functions such as 
>currticks ? Thanks a lot.

currticks started with the standard PC BIOS implementation. Later Eric
Biederman wrote a BIOSless implementation, which is the one you are
trying to mimic. currticks returns a counter that's incremented 18.2
times per second. The exact value is not very sensitive, it's only used
for rough timing. However it must increase monotonically, i.e. not go
backwards, or the timeout logic will get very confused. You should check
that this property holds for your implementation. BTW, are you sure your
arithmetic is being done in sufficient precision? You don't show the
declaration of value, it should be a uint64_t. Maybe you don't even need
all the bits in the low half of the timer and can do your arithmetic
with 32 bit variables.

Also consider the possibility you have tftp server problems.

When you have this alternate implementation working, please submit it
for inclusion (#ifdefed of course). Thanks.

[Etherboot-developers] currticks function

[Fotis A. <fa...@te...>]

Dear all,

I tried to port the etherboot-5.0.6 to the Infineon's TriCore processor. 
I have faced some problems regarding the currticks() function. While I 
couldn't use the existing implementation of currticks (due to the 
assembly of the rdtsc() function and the different architecture), I 
tried to read a 55-bit timer that has 2ns resolution, and return its 
value. The best result that I acquired, derived by using something like 
the following:

    low = (*(volatile unsigned long *)0xF0000310);  // The low part of 
the 55-bit timer
    high = (*(volatile unsigned long *)0xF000032C);  // The high part of 
the 55-bit timer
    value = (low + high * 0x100000000LL);  // According to the existing 
currticks() function

    currticks = (( value ) * 182 / (50 * 1000000LL)); // 50 is the 
CPU_CLOCK [50MHz]
    return (unsigned)currticks;

With the above implementation the bootp process works fine. However, I 
have *many* problems with the tftp process. For example, the client 
starts downloading the kernel image after at least 2-3 requests. For the 
first requests (at least) the downloading fails due to timeouts. Many 
times, the kernel downloading (even if it starts), stops before finish 
succesfully (because the etherboot does not "read" a TFTP_DATA packet 
from the tftpd). Moving arround with different values into the currticks 
function, (especially with the value 182), I realized that the behaviour 
of the system *changes*. I didn't find any documentation on currticks() 
function and I don't know which has to be the value that it returns each 
time is called, the period, the resolution etc. Just from a comment that 
I found on cs89x0.c driver, I thought that it has a period of 55ms. Is 
this true ? Is the tftp process so sensitive in time functions such as 
currticks ? Thanks a lot.

Fotis Andritsopoulos

-- 
"Whom ever Controls your Perception of Reality Controls You"

[Etherboot-developers] TLAN network cards

[Tim F. <ti...@pa...>]

I have just taken delivery of 50 compaq machines that have intergrated
10/100 Netellignt cards (ie tlan chips) they work fine in linux / openbsd
but I have not managed to get them to actually netboot either via grub or
via etherboot. There is a tlan.c in the grub-0.92 release. It is disabled,
I have patched it in so it compiles and is probed for however the driver
doesn't work and hangs grub at the "Found TLAN at 0x1020, ROM at 0x0000.

I have looked in both the 5.0 and 5.1 cvs trees of etherboot for a driver
and it now appers to have been removed. Is there are working driver
somewhere for these cards or is work going on towards one. I would love to
be able to help actually write one but I can't code.

-- 
   Tim Fletcher - Network manager   .~.
                                    /V\      L   I   N   U   X   
     ti...@ni...        // \\  >Don't fear the penguin<
 ti...@pa...  /(   )\
irc: Night-Shade on openprojects   ^^-^^

"A computer lets you make more mistakes faster than any invention
in human history - with the possible exceptions of handguns and tequila."
          -Mitch Ratliffe, Technology Review April, 1992

[Etherboot-developers] dlink-530 detect 00:00:00:00:00:00

[<guo...@ho...>]

_________________________________________________________________
免费下载 MSN Explorer：http://explorer.msn.com/lccn/intl.asp

Re: [Etherboot-developers] Etherboot 5.1.2rc1 released

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

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

> >Why have a release canidate on a development release?
> 
> Why not? It's just packaging for lazy people. We can call it beta1,
> dev1, etc if you don't like rc1.
> 
> What I don't want is a release that's indefinitely in CVS. But what I
> want to see before 5.1.2 is official is an implementation of the server
> side from somebody, anybody. Instead of tinkering with small changes.

O.k. no real real until the server side, shows up.  That makes sense.
I'm still probably two weeks out before I can work on it any more,
but we will see what happens.

Without some server testing is definentily difficult, so I fully
see your point.

Eric

Re: [Etherboot-developers] Etherboot 5.1.2rc1 released

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

>Why have a release canidate on a development release?

Why not? It's just packaging for lazy people. We can call it beta1,
dev1, etc if you don't like rc1.

What I don't want is a release that's indefinitely in CVS. But what I
want to see before 5.1.2 is official is an implementation of the server
side from somebody, anybody. Instead of tinkering with small changes.

Re: [Etherboot-developers] Etherboot 5.1.2rc1 released

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

ke...@us... writes:

> I have released Etherboot 5.1.2rc1 at
> 
> 	http://etherboot.sourceforge.net/etherboot-5.1.2rc1.tar.bz2
> 
> Remember this is a *development* release.  Nothing is guaranteed except
> that it takes up disk space.  If it breaks, you get to keep the pieces.
> But please post here how it broke.
> 
> This release contains all of Eric's multicast changes and other
> cleanups.  It contains all the fixes for 5.0.7rc1 also. I have removed
> all builtin menu support, as menu support will be external in 5.2.

Why have a release canidate on a development release?

Eric

[Etherboot-developers] Etherboot 5.1.2rc1 released

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

I have released Etherboot 5.1.2rc1 at

	http://etherboot.sourceforge.net/etherboot-5.1.2rc1.tar.bz2

Remember this is a *development* release.  Nothing is guaranteed except
that it takes up disk space.  If it breaks, you get to keep the pieces.
But please post here how it broke.

This release contains all of Eric's multicast changes and other
cleanups.  It contains all the fixes for 5.0.7rc1 also. I have removed
all builtin menu support, as menu support will be external in 5.2.

Re: [Etherboot-developers] [COMMIT] Multicast & more.

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

On Thursday, 13. June 2002 21:40, Anselm Martin Hoffmeister wrote:
> On Wednesday, 12. June 2002 05:02, Eric W. Biederman wrote:
> > have only included the good bits but I have only tested the merge with
> > my tree to see if it compiles.  Holler if it breaks, something for you/
>
> Image_menu cannot compile, complains about something double defined....
> Just saw it, I will hunt for mknbi-menu instead :-)

OK, I tracked it down to two forward-definitions inside etherboot.c:
There are (lines 550, 551) two function definitions with a char* argument. It 
should be an unsigned char* and everythings works fine, compare bootmenu.c 
definitions. Patch in attachment solves this problem (for me at least...)

> I used the chance of the moment and changed the code to accept the
> following URIs:
>
> "file:"  (0,1 or 3 times "/")  "disk/" (devicenumber, 0..3 allowed only)
> to boot the MBR of a harddrive

[...]

> FILE:
> TFTP:
> NFS:
> X-SLAM: probably for the moment only
> SLAM: probably in the near future, when it's no longer experimental
> TFTM:

OK, I extended this a bit. If you apply the patches (attached), then your 
"Config" knows some more options.

-DURI_SUPPORT
	general support for any uri-like activites. Not needed by the code right 
	know, but who knows. Set it if you want ANY uri support.
To have the URIs for a specific protocol supported, use
-DURI_SUPPORT_<proto>
where <proto> is one of { FILE TFTP NFS SLAM TFTM }
Note that inclusion of URI_SUPPORT_TFTP enables the TFTP code and compiles it 
in, no matter wether the default download proto is NFS (and vice versa). If 
no known string at the beginning of the filename is detected, etherboot will 
fallback to either DOWNLOAD_PROTO_TFTP or .._NFS, which ever you specified. 
So it doesn't break anything to running installations (I hope. Correct me if 
wrong).
Note also that URI_SUPPORT_FILE will only work if CAN_BOOT_DISK is activated.
So if "file:" URI support is activated, "/dev/hda1" will always work. Perhaps 
this can move out in the future, as I dislike this filenames for special 
purpose.
Note further that DOWNLOAD_PROTO_SLAM requires URI_SUPPORT_SLAM and vice 
versa, as SLAM in the moment cannot be default protocol and needs to be 
started with "x-slam:" URI. Same applies to TFTM, which didn't leave my home 
network yet anyway.

For convenience, I allowed using a tilde ~ instead of the colon, as menu 
entries in dhcp.conf are separated by colons. Looks a bit ridiculous, but 
works. I will not mention it further down, just remember "tftp~/filename" is 
valid too.

Perhaps in the future there will be a feature to use different servers inside 
a bootmenu, so I would like to specify the URI syntax open to extension for 
support for an included servername (default the next-server, if given, or the 
computer DHCP/BOOTP replies came from):


URI types <proto> = {NFS, TFTP], <filename> starts with exactly ONE slash.
	<proto> : <filename>
	<proto> : / / <filename>

	loads the same file as you would get with DOWNLOAD_PROTO_<proto> and
	specifying <filename>.

	Example:	nfs:/tftpboot/vmlinuz.ltsp

	<proto> : / / <servername> <filename>   [ Not implemented yet ]

	could in some future load <filename> with <proto> from <server>

	Example:	nfs://chymaere.augustinnetz.de/tftpboot/vmlinuz.ltsp

URI type <proto> = SLAM
	This is (not yet) standard protocol, so it must be called (conformantly)
	x-slam : / / <filename>

	It's Eric's job to document this. He will surely when releasing the server 	
	so that anyone can use SLAM.

URI type <proto> = TFTM
	This protocol name is not standardized, although tftp-multicast is in an RFC.
	Documentation will follow on release date.
	x-tftm : / / <servername> <filename>

URI type <proto> = FILE
	file : <device type> / <device id>
	file : / <device type> / <device id>
	file : / / / <device type> / <device id>

	<device type> may currently be one of { disk, floppy }
	For floppy, <device id> may be 0...3 selecting one drive to boot from.
	For harddisk, <device id> may be of the form
	<drive no>
	<drive no> / <partition number>
	where first form loads the MBR of the specified disk.
	Partition number 1..4 select the primary partitions and so on.
	Specifying parition number 0 is not allowed. To have the MBR, just
	omit that partition number stuff.
	Same limits apply to <drive no> and <partition number> as do with
	CAN_BOOT_DISK: max. disk 0..3, partition 1...8 or MBR.

Hope I didn't forget to much. As I have no real CVS access (it behaves too 
strange! Perhaps I should change to debian one day...), Eric you will surely 
be so nice to enter it into CVS to me.

Comments welcome.

Anselm

Re: [Etherboot-developers] On disk drivers and other things...

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

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

> >- Size limitations.  Currently etherboot is limited to just 64K.  And
> >  while that is fine if it is just booting off one nic.  Going the
> >  full general purpose route is more difficult.  And I like to be able
> >  to have a build with all of the etherboot drivers included.  So this
> >  pretty much requires some deep architecture work, to go bigger.  I
> >  was hoping to avoid this oh, well.
> 
> The one rejig that would help a lot is to convert the calls to 16 bit
> PCBIOS from inline calls to general calls.  This would remove the need
> for the 32 bit stack to live in the same 64kB as the code. Then I could
> for example, move Etherboot to start at 0x84000, and take all 112kB
> (minus anything taken by the BIOS) up to 0xA0000. In fact, with memory
> so abundant, one could declare all of the lower 640kB fair game when
> loading bzImage Linux.  I realise you're targeting LinuxBIOS, but
> freeing PCBIOS calls from this limitation would allow both to move ahead
> together. It would also help Etherboot to be moved to top of memory with
> an interface stub in low memory later.  Possibilities widen here,
> dynamic loading of modules, etc.


LinuxBIOS is the primary, but I can always use etherboot, so I've been
considering both cases.  

The the work basically looks like an interface stub in low memory for
the PCBIOS, and if possible moving the rest of etherboot to the top
of memory.  

I guess these can be done as seperate steps.  Which helps.

On the LinuxBIOS side I also need to work on a decompressor.  

The problem with my current relocator code, is that it winds up
building a string table of all global variables.  Great if you really
are a shared library, but when noone is dynamically linkingo to you it
is something that is just useless baggage, and pushes the code size
up.

For the LinuxBIOS case I really don't have a problem with that, I have
the better part of a 4Mbit == 256K Rom I can fill.  For the normal
etherboot I think the excess size may be prohibitive.

Eric

Re: [Etherboot-developers] On disk drivers and other things...

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

>- Size limitations.  Currently etherboot is limited to just 64K.  And
>  while that is fine if it is just booting off one nic.  Going the
>  full general purpose route is more difficult.  And I like to be able
>  to have a build with all of the etherboot drivers included.  So this
>  pretty much requires some deep architecture work, to go bigger.  I
>  was hoping to avoid this oh, well.

The one rejig that would help a lot is to convert the calls to 16 bit
PCBIOS from inline calls to general calls.  This would remove the need
for the 32 bit stack to live in the same 64kB as the code. Then I could
for example, move Etherboot to start at 0x84000, and take all 112kB
(minus anything taken by the BIOS) up to 0xA0000. In fact, with memory
so abundant, one could declare all of the lower 640kB fair game when
loading bzImage Linux.  I realise you're targeting LinuxBIOS, but
freeing PCBIOS calls from this limitation would allow both to move ahead
together. It would also help Etherboot to be moved to top of memory with
an interface stub in low memory later.  Possibilities widen here,
dynamic loading of modules, etc.

Re: [Etherboot-developers] to:Eric W. Biederman

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

"zhiguo deng" <dz...@ho...> writes:

> Eric W. Biederman:
>     Is there a server code for etherboot that support multicast?

A) yes.

B) I don't currently have authorization to release it.  If I get a
   spare minute I will check on this.  There is some argument for
   getting a server released but I don't want to go there.

At the same time a simple server could be written in probably 1000 lines
of C, and probably less.  

There are a lot of options for just getting something up and running.
- The stupidest server would just transmit the entire file over and
  over again.  
- A slightly smarter server would transmit the file only when it saw a 
  nack packet. 
- An even smater server would actually pay attention to what the
  client needs, and send the client just the necessary data.  And
  periodically ping the client when it wanted to know what it needed.
- An even smater would keep track of more than one client at a time.

My gut impression at this point is that having to document the
protocol, so someone else can write a second server.  And having the
experiences from a second completely different implementation would
be very useful.

Eric

[Etherboot-developers] On disk drivers and other things...

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

Just a couple of random thoughts before I call this enough for now.
I need to get LinuxBIOS ready so manufacturing can use it, and then
I can get back to improving it's bootloader.

- I have finally realized why I am having so much trouble getting
  disk support integrated in.   The current code in floppy.c really
  is extremly special purpose and only good if all you want to load
  is a boot sector.  A lot of the more general purpose problems are not
  handled.  Such as floppy geometry detection.

- Size limitations.  Currently etherboot is limited to just 64K.  And
  while that is fine if it is just booting off one nic.  Going the
  full general purpose route is more difficult.  And I like to be able
  to have a build with all of the etherboot drivers included.  So this
  pretty much requires some deep architecture work, to go bigger.  I
  was hoping to avoid this oh, well.

- Imprtance of size.  As I work with the etherboot code I'm coming to
  realize just how tuned it is for size.  The big player is how many
  strings and calls to printf the code has.  So disabling debugging
  helps a lot.

  For those people suggesting complicated multicast implementations
  in the driver where we keep lists of the multicast ip addresses we
  are listening to, I won't touch that.   The performance impact would
  have to be huge, to justify a size increase.

Eric

[Etherboot-developers] to:Eric W. Biederman

[zhiguo d. <dz...@ho...>]

Eric W. Biederman:
    Is there a server code for etherboot that support multicast?

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: [Etherboot-developers] unsubscription request

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

>Please unsubscribe me from this mailing list
>
>srikanth

The URL of the un/subscription web page is at the bottom of EVERY
message.

>Etherboot-developers mailing list
>Eth...@li...
>https://lists.sourceforge.net/lists/listinfo/etherboot-developers

[Etherboot-developers] unsubscription request

[srikanth <ks...@cm...>]

Please unsubscribe me from this mailing list

srikanth

Re: [Etherboot-developers] About etherboot that support multicast

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

>Where can I get the etherboot that support multicast, thanks very much!

Only in the CVS archive for the 5.1 development series. Better wear
gloves, this is bleeding edge stuff; you break something, you get to
keep the pieces. I think someone also needs to write a publicly
distributable multicast server.

[Etherboot-developers] About etherboot that support multicast

[zhiguo d. <dz...@ho...>]

Where can I get the etherboot that support multicast, thanks very much!

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: [Etherboot-developers] [COMMIT] Multicast & more.

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

Michael Brown <mb...@fe...> writes:

> On 14 Jun 2002, Eric W. Biederman wrote:
> > > > FILE:
> > > > TFTP:
> > > > NFS:
> > > > X-SLAM: probably for the moment only
> > > > TFTM:
> > One thing we need to do is to advertise in a dhcp option which protocols
> > we support.  This way someone with an ISC dhcp v3 server or equivalent
> > can automatically take advantage of the other protocols.
> 
> Can I suggest putting this inside the etherboot-encapsulated-options
> option, in order to avoid further polluting the site-local dhcp option
> space?  This is easy to do: in main.c, where it currently says
> 
> etherboot_encap_len = sprintf(ip.bp.bp_vend + sizeof rfc1533_cookie + sizeof
> dhcprequest + 2,
> 
> 			      "%c%c%s", RFC1533_VENDOR_NIC_DEV_ID,
> strlen(nic.devid), nic.devid);
> 
> 
> just add further options inside the sprintf statement.

Sounds sane, and roughly what I was thinking.  I posted in large part
to avoid forgetting the issue, and to bring the issue to the attention
of others.

Eric

[Etherboot-developers] Re: bootloaders....

[Ronald G M. <rmi...@la...>]

we'll probably continue with etherboot here too. I keep thinking there may
be other ways to do it but for now etherboot is it.

So I'll have to send any/all patches in next week.

ron

[Etherboot-developers] bootloaders....

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

A while ago there was a conversation about a bootloader wish list,
to get a feel for where we would like to go.  

I haven't had time to do as thourough survey of all of the options
but, my tenative conclusion is that I can get the most bang for my buck
by enhancing Etherboot.  It is small, and runs both under LinuxBIOS
and the stock x86 BIOS's.  And it is written in C so it should be
straight forward to graft on the OpenBIOS forth interpreter.

The code is GPL'd and Ken Yap is a good maintainer, and the code is
mature after having been in use for a long time.  This means all sorts
of interesting cases are already handled, and the problem of booting
is well understood.

The portability will need a nudge, but Etherboot is in considerably
better shape the Linux 1.0 in that regard.

Etherboot may not be the best solution and others are free to pursue
the courses they see best.  But it looks like I can extend it to do
what I need with just a little work, and I am already familiar with
it.  Additionally there has been a fair amount of success by others
extending etherboot to be a more general purpose bootloader for
LinuxBIOS.  The other etherboot developers don't see any real problems
with including that code so long as it is optional.

Ron Minich and company are working on Plan9.  And there are definitely
other options out there.  For the moment I am going to pick the easy
low hanging fruit, with etherboot.  And after that we shall see.

Now back to being quiet and finishin the LinuxBIOS port for MCR.

Eric

Re: [Etherboot-developers] [COMMIT] Multicast & more.

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

On 14 Jun 2002, Eric W. Biederman wrote:
> > > FILE:
> > > TFTP:
> > > NFS:
> > > X-SLAM: probably for the moment only
> > > TFTM:
> One thing we need to do is to advertise in a dhcp option which protocols
> we support.  This way someone with an ISC dhcp v3 server or equivalent
> can automatically take advantage of the other protocols.

Can I suggest putting this inside the etherboot-encapsulated-options
option, in order to avoid further polluting the site-local dhcp option
space?  This is easy to do: in main.c, where it currently says

etherboot_encap_len = sprintf(ip.bp.bp_vend + sizeof rfc1533_cookie + sizeof dhcprequest + 2,
			      "%c%c%s", RFC1533_VENDOR_NIC_DEV_ID, strlen(nic.devid), nic.devid);

just add further options inside the sprintf statement.

Michael