Skip to contentSkip to conversation

commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

U-Boot New Bin Meng 7 participants 20 messages Aug 25, 2015 – Sep 10, 2015 Networking

lore
Share & tools
lore

Bin Meng

author Acked-by Joe Hershberger
#0 lore raw

Hi,

With latest u-boot/master, TFTP is seriously broken.

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

git bisect shows the following commit broke the TFTP

commit 620776d734e4b126c407f636bda825a594a17723

Author: Pavel Machek <[email protected]>
Date:   Tue Aug 18 14:34:26 2015 +0200

tftp: adjust settings to be suitable for 100Mbit ethernet

Adjust timouts and retry counts to be suitable for loaded ethernet network. With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection.

100msec timeout should be suitable for most networks tftp is used on, that is local ethernets. Timeout count really needs to be way higher, as lost packets are normal when TCP is running over the same network.

Enforce 10msec minimum.

Signed-off-by Pavel Machek <[email protected]>
Acked-by Joe Hershberger <[email protected]>

Can we get this fixed ASAP? Thanks,

Regards,
Bin

#1 lore raw

Hi Bin,

Quoted 4 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Quoted 10 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

I'm guessing you are having an issue that the TFTP server you are using for some reason does not allow a timeout as small as 10 ms. What server are you testing against? Can you experiment and find the lowest that it accepts? Maybe there is a compromise we can reach that still works with most (all?) servers and also improves the behavior in a lossy environment.

Quoted 17 lines

git bisect shows the following commit broke the TFTP

commit 620776d734e4b126c407f636bda825a594a17723

Author: Pavel Machek <[email protected]>
Date:   Tue Aug 18 14:34:26 2015 +0200

tftp: adjust settings to be suitable for 100Mbit ethernet

Adjust timouts and retry counts to be suitable for loaded ethernet network. With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection.

100msec timeout should be suitable for most networks tftp is used on, that is local ethernets. Timeout count really needs to be way higher, as lost packets are normal when TCP is running over the same network.

Quoted 6 lines

Enforce 10msec minimum.

Signed-off-by Pavel Machek <[email protected]>
Acked-by Joe Hershberger <[email protected]>

Can we get this fixed ASAP? Thanks,

Hopefully with a little more information about your case we can get this resolved quickly.

-Joe

author
#2 lore raw

Hi Joe,

Quoted 18 lines · Joe Hershberger

Hi Bin,

Quoted 4 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Quoted 10 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 6 lines

I'm guessing you are having an issue that the TFTP server you are using for some reason does not allow a timeout as small as 10 ms. What server are you testing against? Can you experiment and find the lowest that it accepts? Maybe there is a compromise we can reach that still works with most (all?) servers and also improves the behavior in a lossy environment.

I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.

service tftp
{

        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4

}

I don't see an entry to change timeout settings.

Quoted 20 lines
Quoted 20 lines

git bisect shows the following commit broke the TFTP

commit 620776d734e4b126c407f636bda825a594a17723

Author: Pavel Machek <[email protected]>
Date:   Tue Aug 18 14:34:26 2015 +0200

tftp: adjust settings to be suitable for 100Mbit ethernet

Adjust timouts and retry counts to be suitable for loaded ethernet network. With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection.

100msec timeout should be suitable for most networks tftp is used on, that is local ethernets. Timeout count really needs to be way higher, as lost packets are normal when TCP is running over the same network.

Enforce 10msec minimum.

Quoted 8 lines
Quoted 4 lines
Signed-off-by Pavel Machek <[email protected]>
Acked-by Joe Hershberger <[email protected]>

Can we get this fixed ASAP? Thanks,

Hopefully with a little more information about your case we can get this resolved quickly.

Regards,
Bin

#3 lore raw

Hi Bin,

Quoted 43 lines · Bin Meng

Hi Joe,

Quoted 18 lines · Joe Hershberger

Hi Bin,

Quoted 4 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Quoted 10 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 6 lines

I'm guessing you are having an issue that the TFTP server you are using for some reason does not allow a timeout as small as 10 ms. What server are you testing against? Can you experiment and find the lowest that it accepts? Maybe there is a compromise we can reach that still works with most (all?) servers and also improves the behavior in a lossy environment.

I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.

service tftp
{

        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
Quoted 3 lines

}

I don't see an entry to change timeout settings.

I didn't mean to change the server settings; I meant can you adjust the U-Boot code until your server doesn't reject the option?

Quoted 30 lines
Quoted 19 lines
Quoted 19 lines

git bisect shows the following commit broke the TFTP

commit 620776d734e4b126c407f636bda825a594a17723

Author: Pavel Machek <[email protected]>
Date:   Tue Aug 18 14:34:26 2015 +0200

tftp: adjust settings to be suitable for 100Mbit ethernet

Adjust timouts and retry counts to be suitable for loaded ethernet network. With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection.

100msec timeout should be suitable for most networks tftp is used on, that is local ethernets. Timeout count really needs to be way higher, as lost packets are normal when TCP is running over the same network.

Enforce 10msec minimum.

Quoted 8 lines
Quoted 4 lines
Signed-off-by Pavel Machek <[email protected]>
Acked-by Joe Hershberger <[email protected]>

Can we get this fixed ASAP? Thanks,

Hopefully with a little more information about your case we can get this resolved quickly.

Regards,
Bin

author
#4 lore raw

Hi Joe,

Quoted 48 lines · Joe Hershberger

Hi Bin,

Quoted 45 lines · Bin Meng

Hi Joe,

Quoted 18 lines · Joe Hershberger

Hi Bin,

Quoted 4 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Quoted 10 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 6 lines

I'm guessing you are having an issue that the TFTP server you are using for some reason does not allow a timeout as small as 10 ms. What server are you testing against? Can you experiment and find the lowest that it accepts? Maybe there is a compromise we can reach that still works with most (all?) servers and also improves the behavior in a lossy environment.

I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.

service tftp
{

        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4

}

Quoted 5 lines
Quoted 1 line

I don't see an entry to change timeout settings.

I didn't mean to change the server settings; I meant can you adjust the U-Boot code until your server doesn't reject the option?

I would like to revert this commit before we find a solution. Even if I find a proper value to get tftp work again in my network environment, we don't know if this commit breaks someone else's board. After all, this timeout value has been there for years (?), and I believe it is a safe value for all the boards that are actively maintained.

[snip]

Regards,
Bin

#5 lore raw

Hi,

i've same problem.

Running tftp-hpa on Linux Mint 17.

cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"

best regards,
Hannes

Quoted 71 lines · Bin Meng

Hi Joe,

Quoted 46 lines · Joe Hershberger

Hi Bin,

Quoted 43 lines · Bin Meng

Hi Joe,

Quoted 17 lines · Joe Hershberger

Hi Bin,

Quoted 4 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Quoted 10 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 6 lines

I'm guessing you are having an issue that the TFTP server you are using for some reason does not allow a timeout as small as 10 ms. What server are you testing against? Can you experiment and find the lowest that it accepts? Maybe there is a compromise we can reach that still works with most (all?) servers and also improves the behavior in a lossy environment.

I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.

service tftp
{

         socket_type             = dgram
         protocol                = udp
         wait                    = yes
         user                    = root
         server                  = /usr/sbin/in.tftpd
         server_args             = -s /tftpboot
         disable                 = no
         per_source              = 11
         cps                     = 100 2
         flags                   = IPv4

}

Quoted 4 lines
Quoted 1 line

I don't see an entry to change timeout settings.

I didn't mean to change the server settings; I meant can you adjust the U-Boot code until your server doesn't reject the option?

I would like to revert this commit before we find a solution. Even if I find a proper value to get tftp work again in my network environment, we don't know if this commit breaks someone else's board. After all, this timeout value has been there for years (?), and I believe it is a safe value for all the boards that are actively maintained.

[snip]

Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#6 lore raw
Quoted 6 lines · Hannes Schmelzer

Hi,

i've same problem.

Running tftp-hpa on Linux Mint 17.

Quoted 7 lines

cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"

Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog).

Sorry for the trouble,
Pavel

Date: Tue, 25 Aug 2015 13:44:25 +0200
From: Pavel Machek <[email protected]>
To: Bin Meng <[email protected]>
Cc: Joe Hershberger <[email protected]>, Tom Rini <[email protected]>, U-Boot Mailing
List <[email protected]>
Subject: [PATCH] Change default tftp timeout to be rfc-compliant

net/tftp.c +3 -2
index 18ce84c..e919638 100644
@@ -18,8 +18,9 @@
 
 /* Well known TFTP port # */
 #define WELL_KNOWN_PORT	69
-/* Millisecs to timeout for lost pkt */
-#define TIMEOUT		100UL
+/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and
+   some servers will refuse it. */
+#define TIMEOUT		1000UL
 #ifndef	CONFIG_NET_RETRY_COUNT
 /* # of timeouts before giving up */
 # define TIMEOUT_COUNT	1000
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#7 lore raw

Hi Pavel,

this works for me.

many thanks.
I will looking for some patch coming soon.

best regards,
Hannes

Quoted 47 lines · Pavel Machek
Quoted 6 lines · Hannes Schmelzer

Hi,

i've same problem.

Running tftp-hpa on Linux Mint 17.

Quoted 7 lines

cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"

Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog).

Sorry for the trouble,
Pavel

Date: Tue, 25 Aug 2015 13:44:25 +0200
From: Pavel Machek <[email protected]>
To: Bin Meng <[email protected]>
Cc: Joe Hershberger <[email protected]>, Tom Rini <[email protected]>, U-Boot Mailing
List <[email protected]>
Subject: [PATCH] Change default tftp timeout to be rfc-compliant

net/tftp.c +3 -2
index 18ce84c..e919638 100644
@@ -18,8 +18,9 @@
 
  /* Well known TFTP port # */
  #define WELL_KNOWN_PORT	69
-/* Millisecs to timeout for lost pkt */
-#define TIMEOUT		100UL
+/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and
+   some servers will refuse it. */
+#define TIMEOUT		1000UL
  #ifndef	CONFIG_NET_RETRY_COUNT
  /* # of timeouts before giving up */
  # define TIMEOUT_COUNT	1000
#8 lore raw
In reply to Pavel Machek

Hi Pavel,

Quoted 15 lines · Pavel Machek
Quoted 6 lines · Hannes Schmelzer

Hi,

i've same problem.

Running tftp-hpa on Linux Mint 17.

Quoted 7 lines

cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"
Quoted 5 lines

Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog).

Sorry for the trouble,
Pavel

I'm wondering if there's a chance to fix that obvious regression anytime soon?

We're approaching v2015.10 release and with today's master all my boards fail on tftp load with mentioned:
-------------------->8-------------------

# tftp
Speed: 100, full duplex
Using ethernet at f000a000 device
TFTP from server 10.225.15.67; our IP address is 10.225.15.11
Filename 'uImage'.
Load address: 0x82000000
Loading: T T 
TFTP error: 'Unsupported option(s) requested' (8)
-------------------->8-------------------

If there's no proper fix for now then we do need to revert
http://git.denx.de/?p=u-boot.git;a=commit;h=620776d734e4b126c407f636bda825a594a17723

-Alexey

#9 lore raw

Hi Alexey,

Quoted 18 lines · Alexey Brodkin

Hi Pavel,

Quoted 15 lines · Pavel Machek
Quoted 13 lines · Hannes Schmelzer

Hi,

i've same problem.

Running tftp-hpa on Linux Mint 17.

cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"
Quoted 8 lines
Quoted 5 lines

Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog).

Sorry for the trouble,
Pavel

I'm wondering if there's a chance to fix that obvious regression anytime soon?

This is already in u-boot-x86/master here:
http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=527ba17bfd058bd87d5ed4c65aa6f31bebb25dfe

Quoted 2 lines

We're approaching v2015.10 release and with today's master all my boards fail on tftp load with mentioned:

Sounds like Simon is soon sending a pull request...
http://u-boot.10912.n7.nabble.com/Any-more-patches-for-x86-td227547.html

Cheers,
-Joe

#10 lore raw
In reply to Alexey Brodkin

Hi,

Quoted 40 lines · Alexey Brodkin

Hi Pavel,

Quoted 15 lines · Pavel Machek
Quoted 6 lines · Hannes Schmelzer

Hi,

i've same problem.

Running tftp-hpa on Linux Mint 17.

Quoted 7 lines

cat /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"
Quoted 5 lines

Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog).

Sorry for the trouble,
Pavel

I'm wondering if there's a chance to fix that obvious regression anytime soon?

We're approaching v2015.10 release and with today's master all my boards fail on tftp load with mentioned:
-------------------->8-------------------

# tftp
Speed: 100, full duplex
Using ethernet at f000a000 device
TFTP from server 10.225.15.67; our IP address is 10.225.15.11
Filename 'uImage'.
Load address: 0x82000000
Loading: T T
TFTP error: 'Unsupported option(s) requested' (8)
-------------------->8-------------------
Quoted 2 lines

If there's no proper fix for now then we do need to revert
http://git.denx.de/?p=u-boot.git;a=commit;h=620776d734e4b126c407f636bda825a594a17723

Please test on u-boot-x86/master - I just sent a pull request.

Regards,
Simon

#11 lore raw
In reply to Bin Meng
Quoted 3 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Sorry about that.

Quoted 11 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 1 line

git bisect shows the following commit broke the TFTP

I was not intentionally changing the packets being sent.

Could you try to capture tcpdump, including contents of packet, ideally in both working and broken sessions?

Could you try setting

-#define TIMEOUT 5000UL
+#define TIMEOUT 100UL

in net/tftp.c to something like 1000UL?

Thanks,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
author
#12 lore raw

Hi Pavel,

Quoted 18 lines · Pavel Machek
Quoted 3 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Sorry about that.

Quoted 11 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 7 lines
Quoted 1 line

git bisect shows the following commit broke the TFTP

I was not intentionally changing the packets being sent.

Could you try to capture tcpdump, including contents of packet, ideally in both working and broken sessions?

Yep, I will do that. I also tested a tftpd Windows server
(http://tftpd32.jounin.net) and it looks that this Windows server is immune to this commit.

Quoted 7 lines

Could you try setting

(quoted diff) +1 -1
-#define TIMEOUT                5000UL
+#define TIMEOUT                100UL

in net/tftp.c to something like 1000UL?

Could you please elaborate more on what this commit is trying to fix, or improve? From the commit message, I don't quite understand "With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection".

Regards,
Bin

author
#13 lore raw
Quoted 38 lines · Bin Meng

Hi Pavel,

Quoted 18 lines · Pavel Machek
Quoted 3 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Sorry about that.

Quoted 11 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 7 lines
Quoted 1 line

git bisect shows the following commit broke the TFTP

I was not intentionally changing the packets being sent.

Could you try to capture tcpdump, including contents of packet, ideally in both working and broken sessions?

Yep, I will do that. I also tested a tftpd Windows server
(http://tftpd32.jounin.net) and it looks that this Windows server is immune to this commit.

Quoted 5 lines

Could you try setting

(quoted diff) +1 -1
-#define TIMEOUT                5000UL
+#define TIMEOUT                100UL
Quoted 8 lines
Quoted 2 lines

in net/tftp.c to something like 1000UL?

Could you please elaborate more on what this commit is trying to fix, or improve? From the commit message, I don't quite understand "With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection".

OK, I am now pretty sure this commit should be reverted. This commit is a spec violation to RFC 2349 in which it defines the timeout minimum value should be 1.

With this commit change, we set timeout to 100ms which creates a wrong option timeout value = 0, when sending tftp read request to the server. The Linux xinitd server strictly follows the RFC and reports 'Unsupported option(s) requested' (8) while the Windows server is quite forgiving.

Regards,
Bin

#14 lore raw
In reply to Bin Meng
Quoted 38 lines · Bin Meng

Hi Pavel,

Quoted 18 lines · Pavel Machek
Quoted 3 lines · Bin Meng

Hi,

With latest u-boot/master, TFTP is seriously broken.

Sorry about that.

Quoted 11 lines

=> tftp 100000 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x100000
Loading: T
TFTP error: 'Unsupported option(s) requested' (8) Starting again

Quoted 7 lines
Quoted 1 line

git bisect shows the following commit broke the TFTP

I was not intentionally changing the packets being sent.

Could you try to capture tcpdump, including contents of packet, ideally in both working and broken sessions?

Yep, I will do that. I also tested a tftpd Windows server
(http://tftpd32.jounin.net) and it looks that this Windows server is immune to this commit.

Quoted 5 lines

Could you try setting

(quoted diff) +1 -1
-#define TIMEOUT                5000UL
+#define TIMEOUT                100UL
Quoted 7 lines
Quoted 2 lines

in net/tftp.c to something like 1000UL?

Could you please elaborate more on what this commit is trying to fix, or improve? From the commit message, I don't quite understand "With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection".

Well, with 10 retries maximum, I get enough packet loss on local network that tftp fails.

Now, longer timeout will make it slower, but not fail. So "max retries" is really critical.

If rfc says minimum is 1sec, we should not really default to 100msec, sorry about that. Can you try with 1sec if it works for you?

Thanks and best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#15 lore raw

PATCH 1/1 Change default tftp timeout to be rfc-compliant

In reply to Bin Meng

tftp timeout of 100msec gives good performance on local ethernet, but some servers (Centos) refuse to operate, and it is against RFC 2349.

This fixes regression caused by
620776d734e4b126c407f636bda825a594a17723 .

Signed-off-by Pavel Machek <[email protected]>
net/tftp.c +3 -2
index 18ce84c..e919638 100644
@@ -18,8 +18,9 @@
 
 /* Well known TFTP port # */
 #define WELL_KNOWN_PORT	69
-/* Millisecs to timeout for lost pkt */
-#define TIMEOUT		100UL
+/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and
+   some servers will refuse it. */
+#define TIMEOUT		1000UL
 #ifndef	CONFIG_NET_RETRY_COUNT
 /* # of timeouts before giving up */
 # define TIMEOUT_COUNT	1000
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
author
#16 lore raw

PATCH 1/1 Change default tftp timeout to be rfc-compliant

Hi Pavel, Joe,

Quoted 8 lines · Pavel Machek

tftp timeout of 100msec gives good performance on local ethernet, but some servers (Centos) refuse to operate, and it is against RFC 2349.

This fixes regression caused by
620776d734e4b126c407f636bda825a594a17723 .

This patch does not fix the issue properly. As the commit 620776d also changed the "<1000" test logic to "<10", which should not be. See my comments below.

Quoted 7 lines
Signed-off-by Pavel Machek <[email protected]>
net/tftp.c +0 -0
index 18ce84c..e919638 100644

net/tftp.c line 22

Quoted 7 lines
net/tftp.c +2 -2
@@ -18,8 +18,9 @@
 
 /* Well known TFTP port # */
 #define WELL_KNOWN_PORT        69
-/* Millisecs to timeout for lost pkt */
-#define TIMEOUT                100UL
+/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and
+   some servers will refuse it. */

Nits: please use correct multi-line comment format.

net/tftp.c

Quoted 6 lines
net/tftp.c +1 -1
+#define TIMEOUT                1000UL
 #ifndef        CONFIG_NET_RETRY_COUNT
 /* # of timeouts before giving up */
 # define TIMEOUT_COUNT 1000
 
--

I still would like to revert commit 620776d (IOW, apply my revert patch @ http://patchwork.ozlabs.org/patch/510389/). Then Pavel to submit a new patch to change only TIMEOUT_COUNT to something larger (I am still not convinced that we need change the retry count from 10 to 1000). Perhaps with a better comment in the codes to explain why a larger TIMEOUT_COUNT is needed.

Regards,
Bin

#17 lore raw

PATCH 1/1 Change default tftp timeout to be rfc-compliant

Quoted 8 lines · Bin Meng

Hi Pavel, Joe,

Quoted 5 lines · Pavel Machek

tftp timeout of 100msec gives good performance on local ethernet, but some servers (Centos) refuse to operate, and it is against RFC 2349.

Quoted 7 lines
Quoted 3 lines

This fixes regression caused by
620776d734e4b126c407f636bda825a594a17723 .

This patch does not fix the issue properly. As the commit 620776d also changed the "<1000" test logic to "<10", which should not be. See my comments below.

Yes, I know.. and I'd like the test logic to stay. Some tftp servers can handle that, and performance is significantly better that way.

Best regards,
Pavel

Quoted 9 lines

I still would like to revert commit 620776d (IOW, apply my revert patch @ http://patchwork.ozlabs.org/patch/510389/). Then Pavel to submit a new patch to change only TIMEOUT_COUNT to something larger (I am still not convinced that we need change the retry count from 10 to 1000). Perhaps with a better comment in the codes to explain why a larger TIMEOUT_COUNT is needed.

Regards,
Bin

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#18 lore raw

PATCH 1/1 Change default tftp timeout to be rfc-compliant

Quoted 13 lines · Pavel Machek
Quoted 12 lines · Bin Meng

Hi Pavel, Joe,

Quoted 8 lines · Pavel Machek

tftp timeout of 100msec gives good performance on local ethernet, but some servers (Centos) refuse to operate, and it is against RFC 2349.

This fixes regression caused by
620776d734e4b126c407f636bda825a594a17723 .

Quoted 6 lines
Quoted 3 lines

This patch does not fix the issue properly. As the commit 620776d also changed the "<1000" test logic to "<10", which should not be. See my comments below.

Yes, I know.. and I'd like the test logic to stay. Some tftp servers can handle that, and performance is significantly better that way.

Well, what does the RFC say we can and cannot do here?

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150825/49648c18/attachment.sig>
#19 lore raw

PATCH 1/1 Change default tftp timeout to be rfc-compliant

Quoted 14 lines · Tom Rini
Quoted 13 lines · Pavel Machek
Quoted 12 lines · Bin Meng

Hi Pavel, Joe,

Quoted 8 lines · Pavel Machek

tftp timeout of 100msec gives good performance on local ethernet, but some servers (Centos) refuse to operate, and it is against RFC 2349.

This fixes regression caused by
620776d734e4b126c407f636bda825a594a17723 .

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

This patch does not fix the issue properly. As the commit 620776d also changed the "<1000" test logic to "<10", which should not be. See my comments below.

Yes, I know.. and I'd like the test logic to stay. Some tftp servers can handle that, and performance is significantly better that way.

Well, what does the RFC say we can and cannot do here?

According to RFC, we should not be putting 0 there.

Best regards,
Pavel

http://www.rfc-base.org/txt/rfc-2349.txt

#secs
The number of seconds to wait before retransmitting, specified
in ASCII. Valid values range between "1" and "255"
seconds,
inclusive. This is a NULL-terminated field.

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html