Bug 183 - TFTP client behaves incorrectly when sending file with options
Summary: TFTP client behaves incorrectly when sending file with options
Status: RESOLVED FIXED
Alias: None
Product: Busybox
Classification: Unclassified
Component: Networking (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-11 20:40 UTC by Anton Splovyev
Modified: 2009-05-02 11:36 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Splovyev 2009-03-11 20:40:15 UTC 
Busybox version: BusyBox v1.9.2 (2008-04-28 15:02:50 MDT) multi-call binary

According to RFC 1782 (quote below) the write packet sequence is:

===
 Write Request

      client                                           server
      -------------------------------------------------------
      |2|barfile|0|octet|0|blksize|0|2048|0|  -->               RRQ
                                    <--  |6|blksize|0|2048|0|   OACK
      |3|1| 2048 octets of data |  -->                          DATA
                                                   <--  |4|1|   ACK
      |3|2| 2048 octets of data |  -->                          DATA
                                                   <--  |4|2|   ACK
      |3|3|<2048 octets of data |  -->                          DATA
                                                   <--  |4|3|   ACK
===

(note the typo: WRQ, not RRQ)

That is, the first data block from the client has to come with the block number of one. In reality it comes as 0:

===
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:22:38.813604 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 17, length: 56) 1.1.1.11.3073 > 1.1.1.1.tftp:  28 WRQ "/csp/f" octet blksize 1024
        0x0000:  4500 0038 0000 4000 4011 36a8 0101 010b  E..8..@.@.6.....
        0x0010:  0101 0101 0c01 0045 0024 94bf 0002 2f63  .......E.$..../c
        0x0020:  7370 2f66 006f 6374 6574 0062 6c6b 7369  sp/f.octet.blksi
        0x0030:  7a65 0031 3032 3400                      ze.1024.
14:22:38.817221 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 17, length: 43) 1.1.1.1.5004 > 1.1.1.11.3073: UDP, length 15
        0x0000:  4500 002b 0000 4000 4011 36b5 0101 0101  E..+..@.@.6.....
        0x0010:  0101 010b 138c 0c01 0017 dc60 0006 626c  ...........`..bl
        0x0020:  6b73 697a 6500 3130 3234 00              ksize.1024.
14:22:38.817606 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 17, length: 1056) 1.1.1.11.3073 > 1.1.1.1.5004: UDP, length 1028
        0x0000:  4500 0420 0000 4000 4011 32c0 0101 010b  E.....@.@.2.....
        0x0010:  0101 0101 0c01 138c 040c a43b 0003 0000  ...........;....
        0x0020:  3613 031b 3400 0000 0000 2093 0000 2092  6...4...........
        0x0030:  6d6b 6e62 692d 6c69 6e75 7800 0410 0000  mknbi-linux.....
        0x0040:  0022 0900 000e 0000 0010 0000 0411 0000  ."..............
===
Comment 1 Denys Vlasenko 2009-03-11 21:30:03 UTC 
I remember this bug being fixed. Comparing 1.9.2 and 1.10.4 code, block# handling is different.

Please try latest released version.
Comment 2 Anton Splovyev 2009-03-11 21:35:06 UTC 
(In reply to comment #1)
> I remember this bug being fixed. Comparing 1.9.2 and 1.10.4 code, block#
> handling is different.
> 
> Please try latest released version.
> 

Thanks, I'll check and report if there are issues.
Comment 3 Denys Vlasenko 2009-05-02 11:36:48 UTC 
Apparently it is fixed in 1.10.x