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../..@[email protected].... >> 0010: c0a8 002c 8f40 0045 001b 75b7 0001 7078 ...,[email protected] >> 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..,[email protected]...., 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 - [email protected]
