From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ramon Fried <rfried.dev@gmail.com>
Date: Thu, 4 Jun 2020 19:17:57 +0300
Subject: [PATCH v4] net: tftp: Add client support for RFC 7440
In-Reply-To: <1591152886830-0.post@n7.nabble.com>
References: <20200519192557.18075-1-rfried.dev@gmail.com>
 <1591152886830-0.post@n7.nabble.com>
Message-ID: <CAGi-RU+nyqjQWqouObKjDtmYn+5bsPMjCvKw-VPW8iHDPNWE4w@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Wed, Jun 3, 2020 at 5:55 AM Ravik Hasija <rahasij@linux.microsoft.com> wrote:
>
> Ramon Fried-4 wrote
> > +                     if (strcmp((char *)pkt + i,  "windowsize") == 0) {
> > For servers that doesnt support windowsize option the above check could
> > result in accessing memory outside of valid range. Please check if (i+11)
> > < len before comparing the strings.
This is the same handling as all other possible configurations,
following the same code.
I agree that this needs reworking, but I'll do it in a different patch
all together.

> >
> >
> > +
> > +             if (ntohs(*(__be16 *)pkt) != (ushort)(tftp_cur_block + 1)) {
> > +                     debug("Received unexpected block: %d, expected: %d\n",
> > +                           ntohs(*(__be16 *)pkt),
> > +                           (ushort)(tftp_cur_block + 1));
> > +                     /*
> > +                      * If one packet is dropped most likely
> > +                      * all other buffers in the window
> > +                      * that will arrive will cause a sending NACK.
> > +                      * This just overwellms the server, let's just send one.
> > +                      */
> > +                     if (tftp_last_nack != tftp_cur_block) {
> > +                             tftp_send();
> > +                             tftp_last_nack = tftp_cur_block;
> > +                             tftp_next_ack = (ushort)(tftp_cur_block +
> > +                                                      tftp_windowsize);
> > +                     }
> > +                     break;
> > +             }
> > +
> > +             tftp_cur_block++;
> >
> > Monotonically increasing the tftp_cur_block will cause error for cases
> > where sequence number wraps around as tftp_cur_block is ulong, thus during
> > wraparound the check ntohs(*(__be16 *)pkt) != (ushort)(tftp_cur_block + 1)
> > will fail and incorrectly generate ACK, and the connection will eventually
> > be terminated once the retry is exhausted. Please modulo the increment
> > with TFTP_SEQUENCE_SIZE.
True, will fix.
Thanks.
> > --
> > 2.26.2
>
> Quoted from:
> http://u-boot.10912.n7.nabble.com/PATCH-v4-net-tftp-Add-client-support-for-RFC-7440-tp412754.html
>
>
>
>
> --
> Sent from: http://u-boot.10912.n7.nabble.com/