Ao configurar um servidor de inicialização PXE em uma máquina CentOS 7, encontrei um problema estranho com o TFTP. Não consigo recuperar nenhum arquivo do servidor TFTP sem encontrar um problema de tempo limite. O processo de inicialização chega tão longe que recebo corretamente um endereço IP e um nome de arquivo do servidor DHCP. No entanto, quando os arquivos de inicialização devem ser recuperados do servidor TFTP, uma mensagem "TFTP open timeout" é exibida. Se eu fizer manualmente uma conexão TFTP com o servidor PXE a partir de um computador local, terei acesso imediato ao servidor. Mas se eu tentar com um comando "get pxelinux.0", recebo outra mensagem de tempo limite. Meu firewall está configurado corretamente e também não faz diferença se eu desligar completamente o firewall. O SeLinux também está desabilitado. Se eu fizer um tcpdump na porta 69 recebo a seguinte mensagem:
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
12:35:03.384065 IP 172.16.1.202.newlixengine > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
12:35:39.414843 IP 172.16.1.202.newlixconfig > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
12:36:51.422568 IP 172.16.1.202.tsrmagt > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
12:38:39.406732 IP 172.16.1.202.tpcsrvr > tools.dmz.tuxme.dk.tftp: 32 RRQ "pxelinux.0" octet blksize 1456
Infelizmente, o log do sistema não mostra nada útil:
Jan 15 13:13:19 tools xinetd[6993]: EXIT: tftp status=67 pid=7954 duration=0(sec)
Jan 15 13:13:21 tools xinetd[6993]: START: tftp pid=7955 from=172.16.1.202
Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success
Jan 15 13:13:21 tools xinetd[6993]: EXIT: tftp status=67 pid=7955 duration=0(sec)
Jan 15 13:13:25 tools xinetd[6993]: START: tftp pid=7956 from=172.16.1.202
Jan 15 13:13:25 tools in.tftpd[7956]: no user tftp: Success
Jan 15 13:13:25 tools xinetd[6993]: EXIT: tftp status=67 pid=7956 duration=0(sec)
Jan 15 13:13:31 tools xinetd[6993]: START: tftp pid=7957 from=172.16.1.202
Jan 15 13:13:31 tools in.tftpd[7957]: no user tftp: Success
Os direitos para o diretório /var/lib/tftpboot são 0755.
Aqui está meu arquivo de configuração:
/etc/xinetd.d/tftp:
service tftp
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -v -u tftp -p -U 117 -s /var/lib/tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
Parece que a
tcpdump
saída contém apenas solicitações e nenhuma resposta. Se isso é o que está realmente acontecendo, um erro de tempo limite deve ser esperado.Na
server_args
linha de sua configuração TFTP para xinetd, você tem-u tftp
. Isso dizin.tftpd
para executar como usuáriotftp
. À luz disso, esta mensagem registrada porin.tftpd
pode ser importante:Ele diz "sem usuário tftp". A
tftp
conta de usuário realmente existe em seu sistema?A
Success
mensagem no final da mensagem de log requer um pouco de conhecimento de programação C para entender. É provável que venha de uma função minimalista de tratamento de erros que provavelmente apenas chamaperror()
e faz qualquer limpeza necessária antes de sair.A
perror()
função recebe uma mensagem de seu chamador e, em seguida, anexa a ela uma mensagem de erro padrão correspondente ao valor atual daerrno
variável. Ele foi projetado para ser usado em situações em que uma chamada de sistema anterior falhou; a mensagem personalizada deve descrever o que o programa estava fazendo quando o erro foi encontrado e a mensagem padrão deve esclarecer o tipo de problema encontrado.Mas se o programador usou sua função de tratamento de erros para relatar um erro que foi detectado de outra forma, a parte da mensagem de erro padrão lerá
Success
.Meu palpite é que o
in.tftpd
processo é iniciado porxinetd
, se prepara para mudar para usertftp
e descobre que esse usuário não existe. Assim, oin.tftpd
processo gera essa mensagem de log e morre sem enviar nada para o cliente.A mensagem concisa com um enganoso "Sucesso" no final é um exemplo do velho conceito de "se sua única ferramenta é um martelo, você tende a tratar tudo como pregos". Nesse caso, o programador provavelmente usou sua única função de tratamento de erros em uma situação na qual seu formato de saída não se encaixa.
Além disso, esses pedidos parecem um pouco estranhos:
O
tsize 0
indica que o cliente está esperando uma transferência TFTP com um tamanho de arquivo de 0 bytes no total.Você está ciente de que a especificação UEFI PXE, como existia na UEFI versão 2.3, exige que o servidor DHCP informe ao cliente PXE o tamanho do arquivo que deve carregar? Se você estiver usando o servidor DHCP ISC, a opção necessária pode ser especificada como
O
<size value>
deve ser o tamanho do arquivo de inicialização em bytes dividido por 512 e arredondado para cima.Se eu entendi o problema corretamente, encontrei um semelhante.
O servidor PXE funcionou sem problemas e o tftp caiu com "PXE-E32: TFTP Open timeout"
A solução após uma longa pesquisa foi alterar a configuração do tftp /etc/default/tftpd:
Eu adicionei "-r blksize" às opções do tftp.