TFTP timeout problem during PXE boot












1















While setting up a PXE boot server on a CentOS 7 machine, I encountered a strange problem with TFTP. I cannot retrieve any files from the TFTP server without encountering a timeout problem. The boot process comes so far that I correctly get an IP address and a file name from the DHCP server. However, when the boot files are to be retrieved from the TFTP server, a "TFTP open timeout" message comes. If I manually make a TFTP connection to the PXE server from a local computer, I immediately get access to the server. But if I try with a "get pxelinux.0" command, I get another timeout message.
My firewall is set up correctly and it also makes no difference if I completely turn off the firewall. SeLinux is also disabled.
If I make a tcpdump on port 69 I get the following message:



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


Unfortunately, the system log shows nothing useful:



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


The rights to the /var/lib/tftpboot directory are 0755.



Here are my setup file:



/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









share|improve this question

























  • in.tftpd[7957]: no user tftp and the server args -u tftp makes me think you need to have a user tftp that the daemon tries to run under, and this is failing

    – Stephen Harris
    2 days ago
















1















While setting up a PXE boot server on a CentOS 7 machine, I encountered a strange problem with TFTP. I cannot retrieve any files from the TFTP server without encountering a timeout problem. The boot process comes so far that I correctly get an IP address and a file name from the DHCP server. However, when the boot files are to be retrieved from the TFTP server, a "TFTP open timeout" message comes. If I manually make a TFTP connection to the PXE server from a local computer, I immediately get access to the server. But if I try with a "get pxelinux.0" command, I get another timeout message.
My firewall is set up correctly and it also makes no difference if I completely turn off the firewall. SeLinux is also disabled.
If I make a tcpdump on port 69 I get the following message:



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


Unfortunately, the system log shows nothing useful:



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


The rights to the /var/lib/tftpboot directory are 0755.



Here are my setup file:



/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









share|improve this question

























  • in.tftpd[7957]: no user tftp and the server args -u tftp makes me think you need to have a user tftp that the daemon tries to run under, and this is failing

    – Stephen Harris
    2 days ago














1












1








1








While setting up a PXE boot server on a CentOS 7 machine, I encountered a strange problem with TFTP. I cannot retrieve any files from the TFTP server without encountering a timeout problem. The boot process comes so far that I correctly get an IP address and a file name from the DHCP server. However, when the boot files are to be retrieved from the TFTP server, a "TFTP open timeout" message comes. If I manually make a TFTP connection to the PXE server from a local computer, I immediately get access to the server. But if I try with a "get pxelinux.0" command, I get another timeout message.
My firewall is set up correctly and it also makes no difference if I completely turn off the firewall. SeLinux is also disabled.
If I make a tcpdump on port 69 I get the following message:



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


Unfortunately, the system log shows nothing useful:



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


The rights to the /var/lib/tftpboot directory are 0755.



Here are my setup file:



/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









share|improve this question
















While setting up a PXE boot server on a CentOS 7 machine, I encountered a strange problem with TFTP. I cannot retrieve any files from the TFTP server without encountering a timeout problem. The boot process comes so far that I correctly get an IP address and a file name from the DHCP server. However, when the boot files are to be retrieved from the TFTP server, a "TFTP open timeout" message comes. If I manually make a TFTP connection to the PXE server from a local computer, I immediately get access to the server. But if I try with a "get pxelinux.0" command, I get another timeout message.
My firewall is set up correctly and it also makes no difference if I completely turn off the firewall. SeLinux is also disabled.
If I make a tcpdump on port 69 I get the following message:



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


Unfortunately, the system log shows nothing useful:



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


The rights to the /var/lib/tftpboot directory are 0755.



Here are my setup file:



/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






linux networking pxe tftp






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 days ago







Søren Sjøstrøm

















asked 2 days ago









Søren SjøstrømSøren Sjøstrøm

184




184













  • in.tftpd[7957]: no user tftp and the server args -u tftp makes me think you need to have a user tftp that the daemon tries to run under, and this is failing

    – Stephen Harris
    2 days ago



















  • in.tftpd[7957]: no user tftp and the server args -u tftp makes me think you need to have a user tftp that the daemon tries to run under, and this is failing

    – Stephen Harris
    2 days ago

















in.tftpd[7957]: no user tftp and the server args -u tftp makes me think you need to have a user tftp that the daemon tries to run under, and this is failing

– Stephen Harris
2 days ago





in.tftpd[7957]: no user tftp and the server args -u tftp makes me think you need to have a user tftp that the daemon tries to run under, and this is failing

– Stephen Harris
2 days ago










1 Answer
1






active

oldest

votes


















3














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.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f494699%2ftftp-timeout-problem-during-pxe-boot%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    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.






    share|improve this answer




























      3














      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.






      share|improve this answer


























        3












        3








        3







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 days ago









        telcoMtelcoM

        16.2k12144




        16.2k12144






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f494699%2ftftp-timeout-problem-during-pxe-boot%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Loup dans la culture

            How to solve the problem of ntp “Unable to contact time server” from KDE?

            ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux