Re: tfdpd doesn't deliver pxeboot file
> On Oct 6, 2016, at 7:24 AM, Peer Janssen wrote:
>
> But I realized that there must be something in the dhcpd options and/or
> something related to arp resolution, which I didn't grok. So I read some
> more RFCs about pxebooting in relation to dhcp and arp, but finally
> abandoned this problem for now, because it was taking way too much time
> for my current local situation.
So, I just happened across my notes for setting up a PXE server from scratch,
and thought I’d send this for the benefit of anyone trying to set up a PXE
server on OpenBSD 6.0. Granted, this was written to boot an Alix.2d13 using a
VMware Fusion OpenBSD VM instance on a MacBook Pro, but it shows the important
steps for tftpd and dhcpd.
There are bunches of places on the web that talk about this (usually using a
Linux instance for setting up PXE), but I was amazed that I basically could go
from a freshly installed OBSD6.0 to PXE server in about 5 minutes (depending,
really, on how fast I typed). I particularly like this set up for testing
builds (I build on the Mac in a VM, use the USB port on the Mac to talk to the
alix board’s console, and use the Mac ethernet port for installation).
And, again, these were my own notes, not really meant for publication, but I
wanted to show how simple it was to set up an OpenBSD PXE server.
Sean
#
# Setting up the PXE Server #
#
# These notes assume a FRESHLY installed OpenBSD 6.0 system, with no
modifications.
# Primary NIC is connected (bridged) to another network just to get the sets
loaded on it.
* Set up httpd — You need to do this unless you put a router/gateway on the
network.
/etc/httpd.conf:
chroot “/var/www"
server "default" {
listen on * port 80
}
* Add the sets to the httpd server
mkdir /var/www/htdocs/release
Populate /var/www/htdocs/release/OPENBSD_X_Y (from the release server)
* Set up dhcpd
/etc/dhcpd.conf:
subnet 192.168.100.0 netmask 255.255.255.0 {
option router 192.168.100.1;
range 192.168.100.32 192.168.100.127;
filename "pxeboot";
next-server 192.168.100.1;
}
* Set up tftpd
mkdir -p /path/to/tftpdir/etc
echo "set tty com0" > /path/to/tftpdir/etc/boot.conf
echo "boot bsd.rd" >> /path/to/tftpdir/etc/boot.conf
cp /path/to/www/htdpcs/release/OPENBSD_X_Y/bsd.rd /path/to/tftpdir
cp /path/to/www/htdpcs/release/OPENBSD_X_Y/pxeboot /path/to/tftpdir
* Set up vic1
* vic1 is an added NIC, Bridged to Ethernet. The Ethernet port
* is plugged into a switch that the Alix is also plugged into
/etc/hostname.vic1:
inet 192.168.100.1 255.255.255.0 192.168.100.255 description "PXE Net"
chmod 640 /etc/hostname.vic1
* Enable httpd
rcctl enable httpd
* Enable dhcpd
rcctl enable dhcpd
rcctl set dhcpd flags vic1
* Turn on tftpd
rcctl enable tftpd
rcctl set tftpd flags /path/to/tftpdir
* Reboot VM (just to verify everything was set up correctly, not really
necessary;
* you can just bring vic1 up if instead (when you set it up))
* Boot the Alix board, set it to PXE boot (S on startup) and set the board
rate to 9600 or whatever speed you want.
* It should boot into bsd.rd
Re: tfdpd doesn't deliver pxeboot file
Am 29.09.2016 um 14:05 schrieb Stuart Henderson: > On 2016-09-28, Peer Janssen wrote: >> # tftpd -d /tftpboot >> >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out >> tftpd: 192.168.0.81: read request for 'pxeboot' >> tftpd: 192.168.0.81: Operation timed out > Check your firewall rules. The packets where the file is actually > transferred come from a high numbered source port: > > Request $high_port_A -> port 69 > First file packet $high_port_B -> $high_port_A > Ack $high_port_A -> $high_port_B > Second file packet $high_port_B -> $high_port_A > etc. > > I suspect you might not be allowing the return packets. Adding "log" > to any "block" rules that you have and watch "tcpdump -neipflog0" > probably gives you some clues. Thank you for this hint. Frankly, I find it generally enthusing to realize the power of the tools you OpenBSD ecosystem create. The pflog0 live tcpdump log revealed that no packets at all were dropped, and even turning off pf completely didn't change the behavior. But I realized that there must be something in the dhcpd options and/or something related to arp resolution, which I didn't grok. So I read some more RFCs about pxebooting in relation to dhcp and arp, but finally abandoned this problem for now, because it was taking way too much time for my current local situation. That alix2d13 is now working fine, although I finally installed it via CF-Disk, now that I got that reader. (I'm not working in my home lab, so I didn't have that part handy, what made my try using pxeboot in the first place.) Maybe I'll try pxebooting again later, either just to get to the bottom of it, or using it for installing a row of servers, because I still like the idea of that method. Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
On 2016-09-28, Peer Janssen wrote: > # tftpd -d /tftpboot > > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out > tftpd: 192.168.0.81: read request for 'pxeboot' > tftpd: 192.168.0.81: Operation timed out Check your firewall rules. The packets where the file is actually transferred come from a high numbered source port: Request $high_port_A -> port 69 First file packet $high_port_B -> $high_port_A Ack $high_port_A -> $high_port_B Second file packet $high_port_B -> $high_port_A etc. I suspect you might not be allowing the return packets. Adding "log" to any "block" rules that you have and watch "tcpdump -neipflog0" probably gives you some clues.
Re: tfdpd doesn't deliver pxeboot file
I’ve been working on transitioning to an all Alix 2d13 environment for my home set up. Using 6.0 base, I had no problems with PXE (DHCP or tftp) on my Alix 2d13 machine. The server in this case is running on a MacBook Pro with VMware Fusion with a (just freshly built) 6.0 (Stable) install. Despite the bizarre setup (using the ethernet port of the Mac as a secondary interface to the VM and using a primary interface that’s NATed out the wireless port of the Mac), it Just Worked(tm). So, i KNOW OBSD6.0 will provide PXE for an Alix 2d13. The only part I don’t know is if an Alix 3x can be a server. But I don’t see why it couldn’t. Sean > On Sep 28, 2016, at 5:29 AM, Peer Janssen wrote: > > Am 28.09.2016 um 13:27 schrieb Solène Rapenne: >> Le 2016-09-28 12:45, Peer Janssen a écrit : >>> TFTP pxeboot requests: >>> >>> 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ >>> "pxeboot" >>> : 4500 0034 0002 1411 24ea c0a8 0051 E..4..$Q >>> 0010: c0a8 002c 0816 0045 0020 f181 0001 7078 ...,...E. px >>> 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz >>> 0030: 6500 3000e.0. >> >> The TFTP request from alix asks for a binary transfer >> >>> As a comparison, the reaction against the RRQ from the linux box: >>> >>> 12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19 >>> RRQ "pxeboot" (DF) >>> : 4500 002f eca9 4000 4011 cc78 c0a8 001f E../..@.@..x >>> 0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078 ...,.@.E..u...px >>> 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. >>> >>> >> >> The TFTP request from your linux box asks for an ascii transfer >> >> There is a difference between the 2 tftp transfers that may explain >> your problem >> >> Can you try the cli tftp and type "binary" before "get pxeboot" ? >> >> like the following : >> >> tftp 192.168.0.44 >> tftp> binary >> tftp> get pxeboot >> > > Good idea. > This works fine. As well as with "localhost". > > # tftp localhost > tftp> binary > tftp> get pxeboot > Received 81444 bytes in 0.0 seconds > tftp> ascii > tftp> get pxeboot > Received 81965 bytes in 0.1 seconds > tftp> # > > 13:54:47.936070 localhost.23896 > localhost.tftp: [udp sum ok] 16 RRQ > "pxeboot" (ttl 64, id 51686, len 44) > : 4500 002c c9e6 4011 b2d8 7f00 0001 E..,@... > 0010: 7f00 0001 5d58 0045 0018 9309 0001 7078 ]X.E..px > 0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet. > > 13:54:54.649378 localhost.23896 > localhost.tftp: [udp sum ok] 19 RRQ > "pxeboot" (ttl 64, id 50915, len 47) > : 4500 002f c6e3 4011 b5d8 7f00 0001 E../@... > 0010: 7f00 0001 5d58 0045 001b 2b39 0001 7078 ]X.E..+9..px > 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. > > # tftp 192.168.0.44 > tftp> binary > tftp> get pxeboot > Received 81444 bytes in 0.0 seconds > tftp> ascii > tftp> get pxeboot > Received 81965 bytes in 0.1 seconds > tftp> # > > 13:55:11.780098 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok] > 16 RRQ "pxeboot" (ttl 64, id 50778, len 44) > : 4500 002c c65a 4011 32be c0a8 002c E..,.Z..@.2, > 0010: c0a8 002c 810e 0045 0018 ebac 0001 7078 ...,...E..px > 0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet. > > 13:55:18.738183 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok] > 19 RRQ "pxeboot" (ttl 64, id 51568, len 47) > : 4500 002f c970 4011 2fa5 c0a8 002c E../.p..@./, > 0010: c0a8 002c 810e 0045 001b 83dc 0001 7078 ...,...E..px > 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. > > > Maybe the additional options which the alix target (at IP .81) sends are > what the server does not like.There we had: > > 12:16:05.039971 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot" > > : 4500 0034 0006 1411 24e6 c0a8 0051 E..4..$Q > 0010: c0a8 002c 081a 0045 0020 f17d 0001 7078 ...,...E. .}..px > 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz > 0030: 6500 3000e.0. > > 12:16:15.203886 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot" > : 4500 0039 0007 1411 24e0 c0a8 0051 E..9..$Q > 0010: c0a8 002c 081b 0045 0025 619c 0001 7078 ...,...E.%a...px > 0020: 6562 6f6f 7400 6f63 7465 7400 626c 6b73 eboot.octet.blks > 0030: 697a 6500 3134 3536 00 ize.1456. > > => > > Could it be that OpenBSD6.0's tftpd refuses to serve a binary tftp RRQ with > tsize 0 or blksize 1456? > > Is there a way to tell the target how to build it's pxeboot request (maybe > some dhcpd option which will get sent to it)? > > Peer > > > -- > Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 13:27 schrieb Solène Rapenne: > Le 2016-09-28 12:45, Peer Janssen a écrit : >> TFTP pxeboot requests: >> >> 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ >> "pxeboot" >> : 4500 0034 0002 1411 24ea c0a8 0051 E..4..$Q >> 0010: c0a8 002c 0816 0045 0020 f181 0001 7078 ...,...E. px >> 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz >> 0030: 6500 3000e.0. > > The TFTP request from alix asks for a binary transfer > >> As a comparison, the reaction against the RRQ from the linux box: >> >> 12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19 >> RRQ "pxeboot" (DF) >> : 4500 002f eca9 4000 4011 cc78 c0a8 001f E../..@.@..x >> 0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078 ...,.@.E..u...px >> 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. >> >> > > The TFTP request from your linux box asks for an ascii transfer > > There is a difference between the 2 tftp transfers that may explain > your problem > > Can you try the cli tftp and type "binary" before "get pxeboot" ? > > like the following : > > tftp 192.168.0.44 > tftp> binary > tftp> get pxeboot > Good idea. This works fine. As well as with "localhost". # tftp localhost tftp> binary tftp> get pxeboot Received 81444 bytes in 0.0 seconds tftp> ascii tftp> get pxeboot Received 81965 bytes in 0.1 seconds tftp> # 13:54:47.936070 localhost.23896 > localhost.tftp: [udp sum ok] 16 RRQ "pxeboot" (ttl 64, id 51686, len 44) : 4500 002c c9e6 4011 b2d8 7f00 0001 E..,@... 0010: 7f00 0001 5d58 0045 0018 9309 0001 7078 ]X.E..px 0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet. 13:54:54.649378 localhost.23896 > localhost.tftp: [udp sum ok] 19 RRQ "pxeboot" (ttl 64, id 50915, len 47) : 4500 002f c6e3 4011 b5d8 7f00 0001 E../@... 0010: 7f00 0001 5d58 0045 001b 2b39 0001 7078 ]X.E..+9..px 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. # tftp 192.168.0.44 tftp> binary tftp> get pxeboot Received 81444 bytes in 0.0 seconds tftp> ascii tftp> get pxeboot Received 81965 bytes in 0.1 seconds tftp> # 13:55:11.780098 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok] 16 RRQ "pxeboot" (ttl 64, id 50778, len 44) : 4500 002c c65a 4011 32be c0a8 002c E..,.Z..@.2, 0010: c0a8 002c 810e 0045 0018 ebac 0001 7078 ...,...E..px 0020: 6562 6f6f 7400 6f63 7465 7400eboot.octet. 13:55:18.738183 alix.fritz.box.33038 > alix.fritz.box.tftp: [udp sum ok] 19 RRQ "pxeboot" (ttl 64, id 51568, len 47) : 4500 002f c970 4011 2fa5 c0a8 002c E../.p..@./, 0010: c0a8 002c 810e 0045 001b 83dc 0001 7078 ...,...E..px 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. Maybe the additional options which the alix target (at IP .81) sends are what the server does not like.There we had: 12:16:05.039971 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot" : 4500 0034 0006 1411 24e6 c0a8 0051 E..4..$Q 0010: c0a8 002c 081a 0045 0020 f17d 0001 7078 ...,...E. .}..px 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz 0030: 6500 3000e.0. 12:16:15.203886 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot" : 4500 0039 0007 1411 24e0 c0a8 0051 E..9..$Q 0010: c0a8 002c 081b 0045 0025 619c 0001 7078 ...,...E.%a...px 0020: 6562 6f6f 7400 6f63 7465 7400 626c 6b73 eboot.octet.blks 0030: 697a 6500 3134 3536 00 ize.1456. => Could it be that OpenBSD6.0's tftpd refuses to serve a binary tftp RRQ with tsize 0 or blksize 1456? Is there a way to tell the target how to build it's pxeboot request (maybe some dhcpd option which will get sent to it)? Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Le 2016-09-28 12:45, Peer Janssen a écrit : TFTP pxeboot requests: 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ "pxeboot" : 4500 0034 0002 1411 24ea c0a8 0051 E..4..$Q 0010: c0a8 002c 0816 0045 0020 f181 0001 7078 ...,...E. px 0020: 6562 6f6f 7400 6f63 7465 7400 7473 697a eboot.octet.tsiz 0030: 6500 3000e.0. The TFTP request from alix asks for a binary transfer As a comparison, the reaction against the RRQ from the linux box: 12:38:12.807419 kubuntu-neu.fritz.box.36672 > alix.fritz.box.tftp: 19 RRQ "pxeboot" (DF) : 4500 002f eca9 4000 4011 cc78 c0a8 001f E../..@.@..x 0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078 ...,.@.E..u...px 0020: 6562 6f6f 7400 6e65 7461 7363 6969 00eboot.netascii. The TFTP request from your linux box asks for an ascii transfer There is a difference between the 2 tftp transfers that may explain your problem Can you try the cli tftp and type "binary" before "get pxeboot" ? like the following : tftp 192.168.0.44 tftp> binary tftp> get pxeboot
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 11:33 schrieb Peer Janssen: > the request seems to be constructed in different ways. This goes > beyond what tftpd man page says about tftpd's options. Indeed, it > looks like there aren't any tftpd options for this kind of variation > at all, so it seems to me at this time that a pxeboot of such an > alix.2d13 target is currently not possible with OpenBSD 6.0's tftpd. Here is a complete tcpdump of such an unsuccessful pxeboot session from an alix.2d13 to the alix.3x server: # tcpdump -Xi vr0 tcpdump: listening on vr0, link-type EN10MB Getting an IP: 12:15:43.020040 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c secs:4 flags:0x8000 [|bootp] : 4500 0240 1411 a4ae E..@ 0010: 0044 0043 022c d577 0101 0600 .D.C.,.w 0020: ba33 d45c 0004 8000 .3.\ 0030: 000d b933 d45c ...3.\.. 0040: 0050: 0060: .. 12:15:44.031351 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 cd31 0201 0600 .C.D.7.1 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. 12:15:44.031755 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 afc7 0201 0600 .C.D.7.. 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. 12:15:44.055566 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c secs:4 flags:0x8000 [|bootp] : 4500 0240 0001 1411 a4ad E..@ 0010: 0044 0043 022c fc8d 0101 0600 .D.C.,.. 0020: ba33 d45c 0004 8000 .3.\ 0030: 000d b933 d45c ...3.\.. 0040: 0050: 0060: .. 12:15:44.765199 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 acc7 0201 0600 .C.D.7.. 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. 12:15:44.766913 alix.fritz.box.bootps > 255.255.255.255.bootpc: xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether 00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10] : 4510 014b 1011 e8be c0a8 002c E..K..., 0010: 0043 0044 0137 ca31 0201 0600 .C.D.7.1 0020: ba33 d45c 0004 8000 c0a8 0051 .3.\...Q 0030: c0a8 002c 000d b933 d45c ...,...3.\.. 0040: 4448 4350 7365 7276 DHCPserv 0050: 6572 er.. 0060: .. ARP request and answer: 12:15:45.063894 arp who-has alix.fritz.box tell 192.168.0.81 : 0001 0800 0604 0001 000d b933 d45c c0a8 ...3.\.. 0010: 0051 c0a8 002c .Q., 0020: .. 12:15:45.063957 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30 : 0001 0800 0604 0002 000d b913 3c30 c0a8 <0.. 0010: 002c 000d b933 d45c c0a8 0051 .,...3.\...Q 0020: .. TFTP pxeboot requests: 12:15:45.064076 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ "pxeboot" : 4500 0034 0002 1411 24ea c0a8 0051 E..4..$Q 0010: c0a8 002
Re: tfdpd doesn't deliver pxeboot file
Le 2016-09-28 11:05, Peer Janssen a écrit : Am 28.09.2016 um 10:50 schrieb Solène Rapenne: Le 2016-09-28 10:21, Peer Janssen a écrit : The target system for an OpenBSD 6.0 install, an alix.2d13, is directly connected to an alix.3x box serving dhcp and tftp. alix.3x (Server): # tftp localhost tftp> get pxeboot Received 81965 bytes in 0.1 seconds tftp> Can you try the LAN ip address instead of localhost ? Maybe it's a firewall issue or tftp not listening on the lan interface You may want to boot another computer with PXE to see if the problem is related to the alix board or a configuration problem maybe ? From my little experience with PXE and your configs files, everything seems fine there for me.
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 11:05 schrieb Peer Janssen: > Am 28.09.2016 um 10:50 schrieb Solène Rapenne: >> Le 2016-09-28 10:21, Peer Janssen a écrit : >>> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly >>> connected to an alix.3x box serving dhcp and tftp. >>> alix.3x (Server): >>> >>> # tftp localhost >>> tftp> get pxeboot >>> Received 81965 bytes in 0.1 seconds >>> tftp> >>> >> Can you try the LAN ip address instead of localhost ? >> Maybe it's a firewall issue or tftp not listening on the lan interface > Works fine: > $ # on a linux box: > $ # after switching the cable an vr0 of alix server from alix target to > network switch where linux box is connected: > > $ tftp 192.168.0.44 > tftp> get pxeboot > Received 81965 bytes in 1.3 seconds > tftp> Looking at the tcpdump, I noticed this: unsuccessful tftp requests from alix target: 09:44:54.290322 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot" 09:45:04.454216 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot" successful tftp request from linux system: 10:54:07.685813 arp who-has alix.fritz.box tell 10:54:07.685910 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30 10:54:07.686004 .55726 > alix.fritz.box.tftp: 19 RRQ "pxeboot" (DF) 10:54:07.698624 .55726 > alix.fritz.box.24979: udp 4 (DF) 10:54:07.705934 .55726 > alix.fritz.box.24979: udp 4 (DF) [...] So the request seems to be constructed in different ways. This goes beyond what tftpd man page says about tftpd's options. Indeed, it looks like there aren't any tftpd options for this kind of variation at all, so it seems to me at this time that a pxeboot of such an alix.2d13 target is currently not possible with OpenBSD 6.0's tftpd. Unless I missed something somewhere, of course. Peer -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Am 28.09.2016 um 10:50 schrieb Solène Rapenne: > Le 2016-09-28 10:21, Peer Janssen a écrit : >> The target system for an OpenBSD 6.0 install, an alix.2d13, is directly >> connected to an alix.3x box serving dhcp and tftp. >> alix.3x (Server): >> >> # tftp localhost >> tftp> get pxeboot >> Received 81965 bytes in 0.1 seconds >> tftp> >> > > Can you try the LAN ip address instead of localhost ? > Maybe it's a firewall issue or tftp not listening on the lan interface Works fine: # ifconfig urtwn0 | grep inet inet 192.168.0.45 netmask 0xff00 broadcast 192.168.0.255 # ifconfig vr0 | grep inet inet 192.168.0.44 netmask 0xff00 broadcast 192.168.0.255 $ # on a linux box: $ # via wifi ssh link to the alix server: $ tftp alix.fritz.box tftp> status Connected to alix.fritz.box. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> get pxeboot Received 81965 bytes in 1.9 seconds tftp> $ md5sum pxeboot 6d0075598b6672a06dda44498ab7d663 pxeboot $ # after switching the cable an vr0 of alix server from alix target to network switch where linux box is connected: $ tftp 192.168.0.44 tftp> get pxeboot Received 81965 bytes in 1.3 seconds tftp> $ md5sum pxeboot #the second file which has overwritten the one from the first try 6d0075598b6672a06dda44498ab7d663 pxeboot # # back on alix server: # md5 /tftpboot/pxeboot MD5 (/tftpboot/pxeboot) = 6d0075598b6672a06dda44498ab7d663 # md5 /usr/mdec/pxeboot MD5 (/usr/mdec/pxeboot) = 6d0075598b6672a06dda44498ab7d663 So everything is in order regarding these connection / firewall / binding to interface aspects. There is no firewall between the alix.3x server and the alix.2d13 target, it's just one cable. -- Peer Janssen - p...@pjk.de
Re: tfdpd doesn't deliver pxeboot file
Le 2016-09-28 10:21, Peer Janssen a écrit : The target system for an OpenBSD 6.0 install, an alix.2d13, is directly connected to an alix.3x box serving dhcp and tftp. alix.3x (Server): # tftp localhost tftp> get pxeboot Received 81965 bytes in 0.1 seconds tftp> Hello, Can you try the LAN ip address instead of localhost ? Maybe it's a firewall issue or tftp not listening on the lan interface regards
tfdpd doesn't deliver pxeboot file
The target system for an OpenBSD 6.0 install, an alix.2d13, is directly
connected to an alix.3x box serving dhcp and tftp.
alix.3x (Server):
# dmesg | head -n 1
OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
# ifconfig vr0
vr0: flags=8b43
mtu 1500
lladdr 00:0d:b9:13:3c:30
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.0.44 netmask 0xff00 broadcast 192.168.0.255
# dhcpd vr0
# cat
/etc/dhcpd.conf
option domain-name "fritz.box";
option domain-name-servers 192.168.0.44;
option routers 192.168.0.44;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
server-name "DHCPserver";
server-identifier 192.168.0.44;
next-server 192.168.0.44;
default-lease-time 600;
max-lease-time 600;
#option bootfile-name "pxeboot";
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.80 192.168.0.254;
filename "pxeboot";
#host alix_2d13 { hardware ethernet 00:0d:b9:33:d4:5c; }
}
# ls -lR /tftpboot/
total 14100
-rw-r--r-- 1 root wheel71824 Sep 26 22:40 boot
-rw-r--r-- 1 root wheel 7173390 Sep 26 22:40 bsd.rd
drwxr-xr-x 2 root wheel 512 Sep 26 22:43 etc
-rw-r--r-- 1 root wheel81444 Sep 28 09:41 pxeboot
/tftpboot/etc:
total 4
-rw-r--r-- 1 root wheel 46 Sep 27 16:03 boot.conf
# cat /tftpboot/etc/boot.conf
stty com0 38400
set tty com0
boot tftp:bsd.rd
# tftp localhost
tftp> get pxeboot
Received 81965 bytes in 0.1 seconds
tftp>
# #transferred byte count doesn't match file lenth, but the locally
delivered file is fine:
# diff -s pxeboot
/tftpboot/pxeboot
Files pxeboot and /tftpboot/pxeboot are identical
# tftpd -d /tftpboot
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
tftpd: 192.168.0.81: read request for 'pxeboot'
tftpd: 192.168.0.81: Operation timed out
# #Corresponding tcpdump:
# tcpdump -i vr0
09:44:29.798240 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c
secs:4 flags:0x8000 [|bootp]
09:44:30.805580 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
09:44:33.800273 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xba33d45c
secs:4 flags:0x8000 [|bootp]
09:44:34.021374 alix.fritz.box.bootps > 255.255.255.255.bootpc:
xid:0xba33d45c secs:4 flags:0x8000 Y:192.168.0.81 S:alix.fritz.box ether
00:0d:b9:33:d4:5c sname "DHCPserver" [|bootp] [tos 0x10]
09:44:34.320566 arp who-has alix.fritz.box tell 192.168.0.81
09:44:34.320671 arp reply alix.fritz.box is-at 00:0d:b9:13:3c:30
09:44:34.320780 192.168.0.81.2070 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:36.326869 192.168.0.81.2071 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:40.337057 192.168.0.81.2072 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:46.324875 192.168.0.81.2073 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:44:54.290322 192.168.0.81.2074 > alix.fritz.box.tftp: 24 RRQ "pxeboot"
09:45:04.454216 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:45:40.489906 192.168.0.81.2076 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:46:52.508530 192.168.0.81.2077 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:48:40.509010 192.168.0.81.2078 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
09:51:04.491359 192.168.0.81.2079 > alix.fritz.box.tftp: 29 RRQ "pxeboot"
# # From /var/log/daemon:
Sep 28 09:44:29 alix dhcpd[89986]: DHCPDISCOVER from 00:0d:b9:33:d4:5c
via vr0
Sep 28 09:44:30 alix dhcpd[89986]: DHCPOFFER on 192.168.0.81 to
00:0d:b9:33:d4:5c via vr0
Sep 28 09:44:33 alix dhcpd[89986]: DHCPREQUEST for 192.168.0.81 from
00:0d:b9:33:d4:5c via vr0
Sep 28 09:44:34 alix dhcpd[89986]: DHCPACK on 192.168.0.81 to
00:0d:b9:33:d4:5c via vr0
# # Now what happens on target? => Output on serial console of alix target:
$ cu -l /dev/ttyS0 -s 9600
Connected.
PC Engines ALIX.2 v0.99m
640 KB Base Memory
261120 KB Extended Memory
01F0 Master 848A SDCFHS-008G
Phys C/H/S 15538/16/63 Log C/H/S 974/255/63 LBA
Intel UNDI, PXE-2.0 (build 082)
Copyright (C) 1997,1998,1999 Intel Corporation
VIA Rhine III Management Adapter v2.43 (2005/12/15)
CLIENT MAC ADDR: 00 0D B9 33 D4 5C
CLIENT IP: 192.168.0.81 MASK: 255.255.255.0 DHCP IP:
192.168.0.44
GATE
