[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Bin Meng]

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 <pavel@denx.de>
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 <pavel@denx.de>
    Acked-by: Joe Hershberger <joe.hershberger@ni.com>

Can we get this fixed ASAP? Thanks,

Regards,
Bin

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Joe Hershberger]

Hi Bin,

On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> 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

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.

> git bisect shows the following commit broke the TFTP
>
> commit 620776d734e4b126c407f636bda825a594a17723
> Author: Pavel Machek <pavel@denx.de>
> 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 <pavel@denx.de>
>     Acked-by: Joe Hershberger <joe.hershberger@ni.com>
>
> Can we get this fixed ASAP? Thanks,

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

-Joe

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Bin Meng]

Hi Joe,

On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
<joe.hershberger@gmail.com> wrote:
> Hi Bin,
>
> On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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
>
> 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.

>
>> git bisect shows the following commit broke the TFTP
>>
>> commit 620776d734e4b126c407f636bda825a594a17723
>> Author: Pavel Machek <pavel@denx.de>
>> 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 <pavel@denx.de>
>>     Acked-by: Joe Hershberger <joe.hershberger@ni.com>
>>
>> Can we get this fixed ASAP? Thanks,
>
> Hopefully with a little more information about your case we can get
> this resolved quickly.
>

Regards,
Bin

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Joe Hershberger]

Hi Bin,

On Mon, Aug 24, 2015 at 11:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Joe,
>
> On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
> <joe.hershberger@gmail.com> wrote:
>> Hi Bin,
>>
>> On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> 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
>>
>> 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.

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?

>>> git bisect shows the following commit broke the TFTP
>>>
>>> commit 620776d734e4b126c407f636bda825a594a17723
>>> Author: Pavel Machek <pavel@denx.de>
>>> 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 <pavel@denx.de>
>>>     Acked-by: Joe Hershberger <joe.hershberger@ni.com>
>>>
>>> Can we get this fixed ASAP? Thanks,
>>
>> Hopefully with a little more information about your case we can get
>> this resolved quickly.
>>
>
> Regards,
> Bin

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Bin Meng]

Hi Joe,

On Tue, Aug 25, 2015 at 12:24 PM, Joe Hershberger
<joe.hershberger@gmail.com> wrote:
> Hi Bin,
>
> On Mon, Aug 24, 2015 at 11:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Joe,
>>
>> On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
>> <joe.hershberger@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> 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
>>>
>>> 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.
>
> 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] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[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"


best regards,
Hannes


On 25.08.2015 09:40, Bin Meng wrote:
> Hi Joe,
>
> On Tue, Aug 25, 2015 at 12:24 PM, Joe Hershberger
> <joe.hershberger@gmail.com> wrote:
>> Hi Bin,
>>
>> On Mon, Aug 24, 2015 at 11:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Joe,
>>>
>>> On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
>>> <joe.hershberger@gmail.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> 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
>>>> 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.
>> 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
>
>

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Pavel Machek]

On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote:
> 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"

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 <pavel@denx.de>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>, Tom Rini
<trini@konsulko.com>, U-Boot Mailing
List <u-boot@lists.denx.de>
Subject: [PATCH] Change default tftp timeout to be	rfc-compliant
	

diff --git a/net/tftp.c b/net/tftp.c
index 18ce84c..e919638 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -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

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

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Hannes Schmelzer]

Hi Pavel,

this works for me.

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

best regards,
Hannes


On 25.08.2015 14:19, Pavel Machek wrote:
> On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote:
>> 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"
> 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 <pavel@denx.de>
> To: Bin Meng <bmeng.cn@gmail.com>
> Cc: Joe Hershberger <joe.hershberger@ni.com>, Tom Rini
> <trini@konsulko.com>, U-Boot Mailing
> List <u-boot@lists.denx.de>
> Subject: [PATCH] Change default tftp timeout to be	rfc-compliant
> 	
>
> diff --git a/net/tftp.c b/net/tftp.c
> index 18ce84c..e919638 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -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
>

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Alexey Brodkin]

Hi Pavel,

On Tue, 2015-08-25 at 14:19 +0200, Pavel Machek wrote:
> On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote:
> > 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"
> 
> 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

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Joe Hershberger]

Hi Alexey,

On Thu, Sep 10, 2015 at 5:26 PM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hi Pavel,
>
> On Tue, 2015-08-25 at 14:19 +0200, Pavel Machek wrote:
>> On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote:
>> > 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"
>>
>> 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

> 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

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Simon Glass]

Hi,

On 10 September 2015 at 15:26, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hi Pavel,
>
> On Tue, 2015-08-25 at 14:19 +0200, Pavel Machek wrote:
>> On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote:
>> > 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"
>>
>> 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

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

Regards,
Simon

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Pavel Machek]

On Tue 2015-08-25 10:25:35, Bin Meng wrote:
> Hi,
> 
> With latest u-boot/master, TFTP is seriously broken.

Sorry about that.

> => 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

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
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Bin Meng]

Hi Pavel,

On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek <pavel@denx.de> wrote:
> On Tue 2015-08-25 10:25:35, Bin Meng wrote:
>> Hi,
>>
>> With latest u-boot/master, TFTP is seriously broken.
>
> Sorry about that.
>
>> => 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
>
> 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.

> Could you try setting
>
> -#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

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Bin Meng]

On Tue, Aug 25, 2015 at 4:58 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Pavel,
>
> On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek <pavel@denx.de> wrote:
>> On Tue 2015-08-25 10:25:35, Bin Meng wrote:
>>> Hi,
>>>
>>> With latest u-boot/master, TFTP is seriously broken.
>>
>> Sorry about that.
>>
>>> => 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
>>
>> 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.
>
>> Could you try setting
>>
>> -#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".
>

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

[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Pavel Machek]

On Tue 2015-08-25 16:58:58, Bin Meng wrote:
> Hi Pavel,
> 
> On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek <pavel@denx.de> wrote:
> > On Tue 2015-08-25 10:25:35, Bin Meng wrote:
> >> Hi,
> >>
> >> With latest u-boot/master, TFTP is seriously broken.
> >
> > Sorry about that.
> >
> >> => 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
> >
> > 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.
> 
> > Could you try setting
> >
> > -#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".

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant

[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 .

Signed-off-by: Pavel Machek <pavel@denx.de>

diff --git a/net/tftp.c b/net/tftp.c
index 18ce84c..e919638 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -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

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

[U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant

[Bin Meng]

Hi Pavel, Joe,

On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek <pavel@denx.de> wrote:
>
>
> 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.

> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> diff --git a/net/tftp.c b/net/tftp.c
> index 18ce84c..e919638 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -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.

> +#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

[U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant

[Pavel Machek]

On Tue 2015-08-25 21:03:26, Bin Meng wrote:
> Hi Pavel, Joe,
> 
> On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek <pavel@denx.de> wrote:
> >
> >
> > 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.

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

> 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

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

[U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant

[Tom Rini]

On Tue, Aug 25, 2015 at 04:32:48PM +0200, Pavel Machek wrote:
> On Tue 2015-08-25 21:03:26, Bin Meng wrote:
> > Hi Pavel, Joe,
> > 
> > On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek <pavel@denx.de> wrote:
> > >
> > >
> > > 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.
> 
> 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?

-- 
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>

[U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant

[Pavel Machek]

On Tue 2015-08-25 10:49:10, Tom Rini wrote:
> On Tue, Aug 25, 2015 at 04:32:48PM +0200, Pavel Machek wrote:
> > On Tue 2015-08-25 21:03:26, Bin Meng wrote:
> > > Hi Pavel, Joe,
> > > 
> > > On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek <pavel@denx.de> wrote:
> > > >
> > > >
> > > > 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.
> > 
> > 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.
		   



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