Block 0 tftpd ошибка

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

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.

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.

Восстановление прошивки маршрутизатора

Hi,

I am beginner with TFTP protocol in Linux. I have been trying to connect a AM335x EVM Board with my Host to make boot. but first I will like to test my TFTP server.

The configuration is the next:
# cat /etc/xinetd.d/tftp

service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}

# cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
TFTP_USERNAME=»tftp»
TFTP_DIRECTORY=»/tftpboot»
TFTP_ADDRESS=»0.0.0.0:69″
TFTP_OPTIONS=»—secure»
RUN_DAEMON=»yes»

the /tftboot has this files:

# ls -l /tftpboot/
insgesamt 3096
-rwxrwxrwx 1 nobody root 174 Dez 4 14:50 test
-rwxrwxrwx 1 nobody root 3163680 Dez 7 08:59 uImage-am335x-evm.bin

However when I like getting locally some file in /tftpboot over TFTP protocol, I obtain that:

# tftp localhost
tftp> get uImage-am335x-evm.bin
Error code 1: File not found
tftp> quit

Then I make that I see the /var/log/syslog and it shows:

Dec 12 15:29:46 sst-virtual-machine tftpd[6987]: tftpd: trying to get file: uImage-am335x-evm.bin
Dec 12 15:29:46 sst-virtual-machine tftpd[6987]: tftpd: serving file from /srv/tftp

I am sure that I miss something out, because my configuration I thing that is good. But the files in TFTP protocol is looked in the /svr/tftp. Why can it be happening that?
Because tftp configuration shows

server_args = /tftpboot. I think that the TFTP protocol should search the files in that directory /tftpboot, doesn’t it? I have not more idea what wrong is, any help would be greatly appreciated.-Regards