[PATCH v4] net: tftp: Add client support for RFC 7440
Ramon Fried
rfried.dev at gmail.com
Thu Jun 4 18:17:57 CEST 2020
On Wed, Jun 3, 2020 at 5:55 AM Ravik Hasija <rahasij at 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/
More information about the U-Boot
mailing list