Block 0 tftpd ошибка

Ошибка при подключении по TFTP TIMEOUT waiting for Ack block #1

Модераторы: GRooVE, alexco

tftp  dgram  udp  wait  root  /usr/libexec/tftpd  tftpd -l -s /var/tftpboot -u user_back

# netstat -a | grep tftp
udp4       0      0 *.tftp                 *.*

# tftp 10.10.10.10
tftp> put dovecot-1.1.11.tar.gz
Error code 3: Disk full or allocation exceeded
Sent 9216 bytes in 5.0 seconds

tftpd[65420]: Filename: 'dovecot-1.1.11.tar.gz'
tftpd[65420]: Mode: 'netascii'
tftpd[65420]: 10.10.10.10: write request for dovecot-1.1.11.tar.gz: error 102
tftpd[65418]: Timeout #0 on DATA block 1
tftpd[65418]: write_file returned 0
tftpd[65420]: Timeout #0 on DATA block 1
tftpd[65420]: Timeout #1 on DATA block 1
tftpd[65420]: Timeout #2 on DATA block 1
tftpd[65420]: Timeout #3 on DATA block 1
tftpd[65420]: Timeout #4 on DATA block 1
tftpd[65420]: Timeout #5 on DATA block 1, giving up

# cd /var
# ls -all | grep tftpboot
drwx---rwx   2 user_back  user_back   512 12 ноя 17:34 tftpboot

# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    135G     82G     42G    66%    /
devfs          1.0K    1.0K      0B   100%    /dev

$ touch /var/tftpboot/dovecot-1.1.11.tar.gz
$ chmod 666 /var/tftpboot/dovecot-1.1.11.tar.gz
$ ls -all | grep dovecot
-rw-rw-rw-   1 user_back  user_back       0 Nov 13 11:52 dovecot-1.1.11.tar.gz

Решение и попытка TFTPD32 не может передавать данные

Предыстория: однажды, чтобы провести эксперимент с топологией GNS3, вам нужно передать файл конфигурации GNS3 на локальный компьютер, поэтому я загрузил TFTPD32. Краткая диаграмма топологии выглядит следующим образом. После настройки его можно пропинговать, но нельзя передать. Это почти сбивает с толку. Такого рода судебное разбирательство длилось 3 часа … действительно глупо (вручную смешно)

Первый способ ошибки: добавить системный TFTP

В случае PING было неизбежно думать, что это проблема TFTP, и я начал думать, что это проблема системы. Я использовал систему GHOST, но я чувствовал, что она оптимизирована. Порт 69 был заблокирован. Через функцию программы панели управления — —Добавить программу WINDOS — TFTP-клиент.


Не работает …

Глупо думать об этом сейчас, как я хочу передавать данные из GNS3 на локальную, это тоже сторона сервера, открытие клиента — это позор!

Вторая попытка ошибки: проблема с программой TFTPD32.

Сделав неправильную попытку, я почувствовал, что завис и проблема с системой решена (Привет!) Поэтому я начал задаваться вопросом, есть ли проблема с настройкой TFTPD32, и я запустил Baidu для поиска правильной настройки TFTPD32, потому что мой был на английском языке, и Зеленого нет, значит, вначале был бардак … Сначала возьмите переводную картинку

Это моя собственная фотография

Не работает …

Неправильная третья попытка — N

Размышляя об этом, можно выделить разные:

1. Очевидно, что PING подключен, но я думаю, что есть проблема с этим адресом класса B, можно ли его изменить на класс C … (крупные компании не используют серию TFTP)
2. Перезагрузите компьютер, он будет работать? Перезагрузите GNS3, перезапустите TFTPD32 (тройное управление сетью)
3. Будет ли 360 заблокирован? Закройте его!

А, 360?

Вот и волшебный поворот

Правильная попытка первая:

Подумав о том, блокирует ли 360 информацию, я наконец вспомнил, что в WINDOS есть брандмауэр, который всегда будет игнорироваться …

Это оно!（Что я делал раньше ）
Думаю, я могу написать статью «О необходимости отсутствия системного межсетевого экрана》。

Правильная попытка вторая:

Существование разумно, так что лучше найти способ обойти это. Довольно неприятно отключать подсказку в правом нижнем углу.

TFTP — это передача с небольшой пропускной способностью, поэтому это UDP.

Следующий шаг …

Здесь его можно отключить.
Это конец эксперимента, и я оплакиваю одну секунду IQ. OTL …

I am trying to netboot a PC with no CD Drive and no USB Booting options (Available in BIOS but does not recognise USB, broken perhaps somehow).

Anyhow here is the log from TFTP32:

Rcvd DHCP Discover Msg for IP 0.0.0.0, Mac 00:1F:D0:8D:8B:09 [06/12 13:06:48.916]
DHCP: proposed address 192.168.2.1 [06/12 13:06:48.917]
Rcvd DHCP Rqst Msg for IP 0.0.0.0, Mac 00:1F:D0:8D:8B:09 [06/12 13:06:51.113]
Previously allocated address 192.168.2.1 acked [06/12 13:06:51.113]
Connection received from 192.168.2.1 on port 2070 [06/12 13:06:51.125]
Read request for file <netbootpxelinux.0>. Mode octet [06/12 13:06:51.126]
Using local port 53708 [06/12 13:06:51.127]
Connection received from 192.168.2.1 on port 2071 [06/12 13:06:53.125]
Read request for file <netbootpxelinux.0>. Mode octet [06/12 13:06:53.126]
Using local port 53709 [06/12 13:06:53.127]
Connection received from 192.168.2.1 on port 2072 [06/12 13:06:57.136]
Read request for file <netbootpxelinux.0>. Mode octet [06/12 13:06:57.137]
Using local port 53710 [06/12 13:06:57.137]
Connection received from 192.168.2.1 on port 2073 [06/12 13:07:03.122]
Read request for file <netbootpxelinux.0>. Mode octet [06/12 13:07:03.123]
Using local port 53711 [06/12 13:07:03.124]
TIMEOUT waiting for Ack block #1  [06/12 13:07:06.129]
TIMEOUT waiting for Ack block #1  [06/12 13:07:08.129]
Connection received from 192.168.2.1 on port 2074 [06/12 13:07:11.086]
Read request for file <netbootpxelinux.0>. Mode octet [06/12 13:07:11.087]
Using local port 53717 [06/12 13:07:11.088]
TIMEOUT waiting for Ack block #1  [06/12 13:07:12.139]
TIMEOUT waiting for Ack block #1  [06/12 13:07:18.126]
TIMEOUT waiting for Ack block #1  [06/12 13:07:26.090]

Also when I ping the computer I get:

Pinging 192.168.2.1 with 32 bytes of data:
Reply from 10.20.21.188: Destination net unreachable.
Reply from 10.20.21.188: Destination net unreachable.
Reply from 10.20.21.188: Destination net unreachable.
Reply from 10.20.21.188: Destination net unreachable.

Ping statistics for 192.168.2.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
PS C:Windowssystem32>

If anyone has any ideas as to how I might go about rectifying this it would be most appreciated.

Regards

EDIT_>

Additional information that might be useful

1. I am not using a crossover cable; however, the network card on my server computer is a gigabit one, I’m not sure if that means I still need a crossover cable, however. The two PCs are connected by only a fast Ethernet switch.

2. The final objective of the netboot is to install Debian on the client computer. I am currently running an Apache server but I haven’t yet ascertained what the next steps will be. I am booting pxelinux.0 (not really sure yet what it actually is, I got it from the Debian tar.gz file I downloaded from the net following the guide here).

It looks like the tcpdump output contains only requests and not any responses at all. If this is what is actually happening, then a timeout error is to be expected.

In the server_args line of your TFTP configuration for xinetd, you have -u tftp. That tells in.tftpd to run as user tftp. In light of that, this message logged by in.tftpd might be important:

Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success

It says «no user tftp». Does the tftp user account actually exist on your system?

The Success at the end of the log message requires a bit of C programming knowledge to understand. It is likely to come from a minimalist error-handling function that probably just calls perror() and then does any necessary clean-up before exiting.

The perror() function takes a message from its caller and then appends to it a standard error message corresponding to the current value of the errno variable. It is designed to be used in situations where a previous system call has failed; the custom message should describe what the program was doing when the error was encountered, and the standard message should then clarify the type of problem encountered.

But if the programmer has used their error-handling function to report an error that has been caught some other way, the standard error message part will read Success.

My guess is that the in.tftpd process gets started by xinetd, prepares to switch to user tftp, and finds out that such user does not exist. So the in.tftpd process outputs that log message and dies without sending anything to the client.

The terse message with a misleading «Success» at the end is an example of the old concept of «if your only tool is a hammer, you tend to treat everything as nails.» In this case, the programmer has probably used their only error handling function in a situation to which its output format does not quite fit.

Also, these requests look a little odd:

12:34:33.477401 IP 172.16.1.202.ah-esp-encap > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:35.481131 IP 172.16.1.202.acp-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:39.490793 IP 172.16.1.202.msync > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:45.477712 IP 172.16.1.202.gxs-data-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:53.441801 IP 172.16.1.202.vrtl-vmf-sa > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0

The tsize 0 indicates the client is expecting a TFTP transfer with a file size of 0 bytes total.

Are you aware that the UEFI PXE specification, as it existed in UEFI version 2.3 or so, requires the DHCP server to tell the PXE client the size of the file it’s supposed to load? If you’re using ISC DHCP server, the required option could be specified as

option boot-size <size value>; 

The <size value> should be the size of the boot file in bytes divided by 512, then rounded up.

FreeBSD v13 9.1-RELEASE

Исправили параметры при запуске и перестартовали сервис inetd:

[[email protected] /]# cat /etc/inetd.conf | grep tftp
tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -ldw -s /var/tftp

Пробуем от клиента 192.168.112.36 отправить файл 888.cfg:

[[email protected] /]# tail -f /var/log/xferlog
Oct  6 14:42:50 v13 tftpd[5533]: Filename: '888.cfg'
Oct  6 14:42:50 v13 tftpd[5533]: Mode: 'octet'
Oct  6 14:42:50 v13 tftpd[5533]: 192.168.112.36: write request for 888.cfg: error 102
Oct  6 14:42:55 v13 tftpd[5533]: Timeout #0 on DATA block 1

Не заработало! По сообщениям об ошибке ничего толкового найти не смог.

Ставлю /usr/ports/ftp/tftp-hpa
Далее конфигурим по инструкции из интернета.

[[email protected] /]# pw groupadd tftpd
[[email protected] /]# pw useradd tftpd -c tftp_manager -d /nonexistent -g tftpd -s /usr/sbin/nologin
[[email protected] /]# chown tftpd:tftpd /var/tftp
[[email protected] /]# chmod 750 /var/tftp
[[email protected] /]# touch /usr/local/etc/tftpd-remap.conf
[[email protected] /]# chmod 440 /usr/local/etc/tftpd-remap.conf
[[email protected] /]# chown tftpd:tftpd /usr/local/etc/tftpd-remap.conf

Скрипт запуска /usr/local/etc/rc.d/tftpd (.sh) после make install уже был. По инструкции его раньше делали с нуля:

 
[[email protected] /] touch /usr/local/etc/rc.d/tftpd
[[email protected] /] chmod +x /usr/local/etc/rc.d/tftpd

[[email protected] /]# cat /usr/local/etc/tftpd-remap.conf
# Rename all files
# If WRQ: filename -> IP-filename
# If RRQ: IP-filename -> filename

# Полученные файлы будут переименовываться в -<имя файла>
r .* i-

[[email protected] /]# cat /usr/local/etc/rc.d/tftpd
#!/bin/sh
#
# tftp-hpa init script
# Copyright ╘ 2006 by Alexey Tsvetnov, [email protected]
#
# PROVIDE: tftpd
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: shutdown
#
# Define these tftpd_* variables in one of these files:
#       /etc/rc.conf
#       /etc/rc.conf.local
#       /etc/rc.conf.d/tftpd
#
# tftpd_enable (bool):          Set it to "YES" to enable tftpd.
#                                           Default is "NO"
# tftpd_pidfile (path):           Set full path to tftpd.pid.
#                                           Default is /var/run/tftpd.pid
# tftpd_remapfile (path):      Set full path to remap file.
#                                           Default is /usr/local/etc/tftpd-remap.conf
# tftpd_datadir (path):         Set full path to directory with data.
#                                           Default is /var/tftp
# tftpd_flags (str):                Extra flags passed to start command.
#                                           Default is "-cps -u tftpd -U 037 -B 14682"
#

. /etc/rc.subr

name="tftpd"
rcvar=tftd_enable

load_rc_config $name

# DO NOT CHANGE THESE DEFAULT VALUES HERE

: ${tftpd_enable="NO"}
: ${tftpd_pidfile="/var/run/tftpd.pid"}
: ${tftpd_remapfile="/usr/local/etc/tftpd-remap.conf"}
: ${tftpd_datadir="/var/tftp"}
: ${tftpd_flags="-vcps -u tftpd -U 037 -B 1468"}

extra_commands="reload"
start_cmd="tftpd_start"
stop_postcmd="tftpd_poststop"
reload_cmd="tftpd_reload"
required_files="/usr/local/etc/tftpd-remap.conf"
pidfile=$tftpd_pidfile
procname="/usr/local/libexec/in.tftpd"

tftpd_start() {
      /bin/echo -n "Starting tftpd"
      /usr/local/libexec/in.tftpd $tftpd_flags -l -m $tftpd_remapfile $tftpd_datadir
      /bin/ps x | /usr/bin/grep in.tftpd | /usr/bin/grep -v grep | /usr/bin/awk '{print $1}' > $tftpd_pidfile
      /bin/echo "."
}

tftpd_poststop() {
    /bin/rm -f $tftpd_pidfile
}

tftpd_reload() {
    /bin/kill -1 `cat $tftpd_pidfile`
}

run_rc_command "$1"

[[email protected] /]# cat /etc/rc.conf | grep tftp
tftpd_enable="YES"
tftpd_flags="--ipv4 -vcps -u tftpd -U 037 -B 1468"

Стартуем:

[[email protected] /]# /usr/local/etc//rc.d/tftpd start
Starting tftpd.

Проверяем:

[[email protected] /]# ps -ax | grep tftpd
 8641 ??  Is       0:00.00 /usr/local/libexec/in.tftpd --ipv4 -vcps -u tftpd -U 037 -B 1468 -l -m /usr/local/etc/tftpd-remap.conf /var/tftp
 8649  0  S+       0:00.00 grep tftpd

[[email protected] /]# sockstat | grep 69
root     in.tftpd   8641  4  udp4   *:69                  *:*

Загрузаем файл 555.cfg c хоста 192.168.112.36:

[[email protected] /]# tail -f /var/log/xferlog
Oct  6 16:56:40 v13 in.tftpd[8676]: WRQ from 192.168.112.36 filename 555.cfg remapped to 192.168.112.36-555.cfg

После этого заккоментарил строку /usr/local/etc/tftpd-remap.conf
Загрузаем файл 555.cfg c хоста 192.168.112.36 повторно:

[[email protected] /]# tail -f /var/log/xferlog
Oct  6 17:22:38 v13 in.tftpd[8937]: WRQ from 192.168.112.36 filename 555.cfg

Теперь так как нужно. Вопрос закрыт.

Просмотров:
442