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 <p...@pjk.de> 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" >>> 0000: 4500 0034 0002 0000 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 3000 e.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) >>> 0000: 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 00 eboot.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) > 0000: 4500 002c c9e6 0000 4011 b2d8 7f00 0001 E..,....@....... > 0010: 7f00 0001 5d58 0045 0018 9309 0001 7078 ....]X.E......px > 0020: 6562 6f6f 7400 6f63 7465 7400 eboot.octet. > > 13:54:54.649378 localhost.23896 > localhost.tftp: [udp sum ok] 19 RRQ > "pxeboot" (ttl 64, id 50915, len 47) > 0000: 4500 002f c6e3 0000 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 00 eboot.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) > 0000: 4500 002c c65a 0000 4011 32be c0a8 002c E..,.Z..@.2...., > 0010: c0a8 002c 810e 0045 0018 ebac 0001 7078 ...,...E......px > 0020: 6562 6f6f 7400 6f63 7465 7400 eboot.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) > 0000: 4500 002f c970 0000 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 00 eboot.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" > > 0000: 4500 0034 0006 0000 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 3000 e.0. > > 12:16:15.203886 192.168.0.81.2075 > alix.fritz.box.tftp: 29 RRQ "pxeboot" > 0000: 4500 0039 0007 0000 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
