Hi Jay
Thank you for answering.
“Jay Hogg” <Jay.Hogg@t-netix.com.r-e-m-o-v-e> wrote in message
news:9r6jia$1ns$1@inn.qnx.com…
A couple things…
- on netsniff increase the size of the packet it is dumping?
OK, here you go > 
> I’ve used > ftp://download.intel.com/ial/wfm/pxespec.pdf
to decipher the data.
Src 0002A5 79E2B1 [5] Dst FFFFFF FFFFFF [?] Len 578 Lan 1(Eth)
1004021163
08 00 45 00 02 40 00 00 00 00 14 11 A4 AE 00 00 …E…@…
00 00 FF FF FF FF 00 44 00 43 02 2C 52 ED 01 01 …D.C.,R…
06 00 A6 79 E2 B1 00 04 80 00 00 00 00 00 00 00 …y…
00 00 00 00 00 00 00 00 00 00 00 02 A5 79 E2 B1 …y…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
all '0’s here, sname and bootfile in the DHCPDISCOVER packet
00 00 00 00 00 00 00 00 00 00 63 82 53 63 35 01 …c.Sc5.
01 37 0E 01 03 2B 36 3C 43 80 81 82 83 84 85 86 .7…+6<C…
87 39 02 04 EC 61 11 00 6F DA FF AB 34 4D D5 11 .9…a…o…4M…
8A 48 5C BE 22 BC A7 25 5D 02 00 00 5E 03 01 02 .H."…%]…^…
01 3C 20 50 58 45 43 6C 69 65 6E 74 3A 41 72 63 .< PXEClient:Arc
68 3A 30 30 30 30 30 3A 55 4E 44 49 3A 30 30 32 h:00000:UNDI:002
30 30 31 FF 00 00 00 00 00 00 00 00 00 00 00 00 001…
'0’s in rest of package
My understanding is that this is a DHCPDISCOVER packet as specified in the
“0x35 0x01 0x01” tag.
The QNX bootpd reply is this;
Src 00A024 4FB36C [2] Dst 0002A5 79E2B1 [5] Len 578 Lan 1(Eth)
1004021163
08 00 45 00 02 40 AE 99 00 00 1E 11 D4 97 0A 10 …E…@…
01 AD 0A 10 01 B0 00 43 00 44 02 2C 69 E8 02 01 …C.D.,i…
06 00 A6 79 E2 B1 00 04 80 00 00 00 00 00 0A 10 …y…
01 B0 0A 10 01 AD 0A 10 01 AD 00 02 A5 79 E2 B1 …y…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 2F 62 6F 6F 74 2F …/boot/
69 6D 61 67 65 73 2F 63 6F 6D 70 61 71 2E 71 6E images/compaq.qn
78 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 x5…
'0’s in rest of bootfile name
00 00 00 00 00 00 00 00 00 00 63 82 53 63 35 01 …c.Sc5.
01 37 0E 01 03 2B 36 3C 43 80 81 82 83 84 85 86 .7…+6<C…
87 39 02 04 EC 61 11 00 6F DA FF AB 34 4D D5 11 .9…a…o…4M…
8A 48 5C BE 22 BC A7 25 5D 02 00 00 5E 03 01 02 .H."…%]…^…
01 3C 20 50 58 45 43 6C 69 65 6E 74 3A 41 72 63 .< PXEClient:Arc
68 3A 30 30 30 30 30 3A 55 4E 44 49 3A 30 30 32 h:00000:UNDI:002
30 30 31 FF 00 00 00 00 00 00 00 00 00 00 00 00 001…
Here we have (all OK):
yiaddr 10.16.1.176
siaddr 10.16.1.173
giaddr 10.16.1.173
Unfortunately the bootpd seems to echo the ‘DHCP Options’ part of the client
request, I’ve tried adding Tn tags to my bootptab file, but as far as I can
see bootpd just ignores them. Here’s what I’m trying to use at the moment:
qnx5:T53=2:hn:hd=/boot:sm=255.255.255.0:ht=ethernet:ha=00.02.A5.79.E2.B1:\
:gw=10.16.1.2:ds=10.16.1.17:ip=10.16.1.176:bf=images/compaq:to=auto:vm=rfc10
48:
:sa=10.16.1.173:T6=0x08:
The ‘T53=2’ is supposed to return a ‘DHCPOFFER’ option to the client, the
‘T6=0x08’ is an effort to set PXE_DISCOVERY_CONTROL to persuade the client
to immediately download the boot image as specified in the reply. But, as I
said, bootpd just ignores these extra Tn options. By mistake I happened to
write ‘t6=0x08’ the first time I tried to use the generic Tn tag, the lower
case ‘t’ was considered a syntax error by bootpd, so at least it seems to be
parsing the option. I guess there could be potential problems with the #53
tag, since there already is one in the echoed part of the packet.
The client will however interpret the echoed ‘DHCP options’ part of the
reply as a DHCPOFFER packet. The client now issues a DHCPREQUEST;
Src 0002A5 79E2B1 [5] Dst FFFFFF FFFFFF [?] Len 578 Lan 1(Eth)
1004021164
08 00 45 00 02 40 00 01 00 00 14 11 A4 AD 00 00 …E…@…
00 00 FF FF FF FF 00 44 00 43 02 2C CB 6D 01 01 …D.C.,.m…
06 00 A6 79 E2 B1 00 04 80 00 00 00 00 00 00 00 …y…
00 00 00 00 00 00 00 00 00 00 00 02 A5 79 E2 B1 …y…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 63 82 53 63 35 01 …c.Sc5.
03 32 04 0A 10 01 B0 37 0E 01 03 2B 36 3C 43 80 .2…7…+6<C.
81 82 83 84 85 86 87 39 02 04 EC 36 04 0A 10 01 …9…6…
AD 61 11 00 6F DA FF AB 34 4D D5 11 8A 48 5C BE .a…o…4M…H.
22 BC A7 25 5D 02 00 00 5E 03 01 02 01 3C 20 50 "…%]…^…< P
58 45 43 6C 69 65 6E 74 3A 41 72 63 68 3A 30 30 XEClient:Arch:00
30 30 30 3A 55 4E 44 49 3A 30 30 32 30 30 31 FF 000:UNDI:002001.
This seems fine, some of the data is;
Tag #50 = 10.16.1.176 (The client’s IP addr, can’t find any doc on Tag #50,
but seems reasonable)
Tag #54 = 10.16.1.173 (Server IP, OK)
The bootpd will once again answer with a proper DHCP header and echo the
DHCP options part of the packet;
Src 00A024 4FB36C [2] Dst 0002A5 79E2B1 [5] Len 578 Lan 1(Eth)
1004021164
08 00 45 00 02 40 AE B6 00 00 1E 11 D4 7A 0A 10 …E…@…z…
01 AD 0A 10 01 B0 00 43 00 44 02 2C E2 68 02 01 …C.D.,.h…
06 00 A6 79 E2 B1 00 04 80 00 00 00 00 00 0A 10 …y…
01 B0 0A 10 01 AD 0A 10 01 AD 00 02 A5 79 E2 B1 …y…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 2F 62 6F 6F 74 2F …/boot/
69 6D 61 67 65 73 2F 63 6F 6D 70 61 71 2E 71 6E images/compaq.qn
78 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 x5…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 63 82 53 63 35 01 …c.Sc5.
03 32 04 0A 10 01 B0 37 0E 01 03 2B 36 3C 43 80 .2…7…+6<C.
81 82 83 84 85 86 87 39 02 04 EC 36 04 0A 10 01 …9…6…
AD 61 11 00 6F DA FF AB 34 4D D5 11 8A 48 5C BE .a…o…4M…H.
22 BC A7 25 5D 02 00 00 5E 03 01 02 01 3C 20 50 "…%]…^…< P
58 45 43 6C 69 65 6E 74 3A 41 72 63 68 3A 30 30 XEClient:Arch:00
30 30 30 3A 55 4E 44 49 3A 30 30 32 30 30 31 FF 000:UNDI:002001.
The client was expecting a DHCPACK packet and now gives up and once again
issues a DHCPDISCOVER packet and the sequence starts over again.
- Did bootp respond to the MAC address with the bootp packet?
Answered above.
- Does the board support DHCP booting or PXE booting?
The progression is bootp->dhcp->pxe using extensions to bootp but
they each have different signatures in the boot request.
The dump on the client’s display reads “PXE 2.0 … WfM(2.0)” and then an
animated “DHCP …/” with a new dot for each packet sent.
- Do you have tftp configured? The response to bootp must be
relative to the tftp root.
I havent gotten that far with the client/server requests, but manual tftp to
get the boot file works.
If you post the info I’ll look up the stuff tonight… haven’t done this
in
a while so I’m a little rusty.
I truly appreciate your generous offer. I’ve been searching all over the net
to find info on this. My main concern now is that the QNX bootpd seems to
ignore options in the bootptab file. I’ve mentioned the Tn tag in this post,
and as I wrote in my previous post the “bf=|cd /boot; buildqnx build/node1”
does not seem to work. sin ver doesn’t give any info from bootpd, ls -l says
this:
-rwxrwxr-x 1 root root 61512 Aug 12 1998
/usr/tcprt/current/usr/ucb/bootpd
I’m pretty sure that this is what’s on the May 2001 CD. Or is there a newer
version?
Thanks,
P-O
Jay
P-O Håkansson wrote in message <9r1cb9$egq$> 1@inn.qnx.com> >…
Hi again
Thanks to Mario Charest and Michael Huebbers for answering my previous
question.
I’m using a Compaq Deskro EN to do some BOOTP experimenting. The boot ROM
of
the Intel Ethernet controller can issue DHCP boot requests. I hoping I’m
right in believing that this is a superset of BOOTP and I should be able
to
handle the requests in QNX 4.25?
Here’s what netsniff says about a boot request;
Src 0002A5 79E2B1 [5] Dst FFFFFF FFFFFF [?] Len 578 Lan 1(Eth)
1003756887
IP hl 5 v 4 tos 0 len 576 id 0 off 0 ttl 20 proto 17 sum a4ae src 0.0.0.0
dst 255.255.255.255
UDP src 68 dst 67 len 556 sum 52ed
BOOTP request ethernet hwlen 6 hop 0 trans -1501961551 sec 4 client
0.0.0.0 your 0.0.0.0 server 0.0.0.0 gateway 0.0.0.0
client hw addr 00 02 a5 79 e2 b1
63 82 53 63 35 01 01 37 0E 01 03 2B 36 3C 43 80 c.Sc5…7…+6<C.
81 82 83 84 85 86 87 39 02 04 EC 61 11 00 6F DA …9…a…o.
FF AB 34 4D D5 11 8A 48 5C BE 22 BC A7 25 5D 02 …4M…H."…%].
On my number 2 QNX node I’ve configured inetd so that bootpd is started
when
a boot request arrives;
tftp dgram udp wait bin /usr/ucb/tftpd in.tftpd
…
#BOOTP
bootps dgram udp wait root /usr/ucb/bootpd bootpd -dd
I’ve configured bootptab to accept requests from my number 5 QNX node;
qnx5:hn:hd=/boot:sm=255.255.255.0:ht=ethernet:ha=00.02.A5.79.E2.B1:
:gw=10.16.1.2::ds=10.16.1.17:ip=10.16.1.176:bf=images/compaq:to=auto:vm=rfc
1
048:
Here’s the debug dump in syslog from bootpd;
Oct 22 17:12:08 node<<2>> bootpd[1610]: request from Ethernet address
0002A579E2B1
Oct 22 17:12:08 node<<2>> bootpd[1610]: found 10.16.1.176 qnx5
Oct 22 17:12:08 node<<2>> bootpd[1610]: trying /boot/images/compaq.qnx5
Oct 22 17:12:08 node<<2>> bootpd[1610]: /boot/images/compaq.qnx5 has size
409600
As far as I can see, bootpd never sends any reply to the BOOTP request.
Should bootpd itself send the reply? Or am I missing something in my
services file? At least my netmap file seems to be correct, I guess that
otherwise I wouldn’t have gotten this far.
I hope the boot image related directories have the proper read/write
settings. I can ‘get’ the boot image with tftp, which hopefully indicates
that it’s OK.
In my desperation I tried the alternative QNX ‘TCP/IP User’s Guide’
method
of building the boot image on the fly from bootptab;
:bf=|cd /boot; buildqnx build/a_file_name:
That wasn’t any success either, bootpd didn’t execute any command,
instead
it tries to find the file ‘|cd /boot; buildqnx build/a_file_name.qnx5’
…
Any input is appreciated, thanks,
P-O Håkansson
\