Re: tftp protocol

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Tue, Oct 13, 2009 at 07:30:17AM -0700, jscottkasten%yahoo.com@localhost 
wrote:
> Let us know how you come out.

The story so far:

I did a BIOS update - the release notes didn't say what the update changed
so who knows what that was good for (Toshiba). (No change in behaviour.)

I stopped receiving the strange 768 opcode with the following patch:

@@ -924,7 +939,7 @@
                                        dp = r_init();
                                        goto done;
                                }
-                               if (ap->th_block == block)
+                               if (ap->th_block == (u_short)block)
                                        goto done;
                                if (debug)
                                        syslog(LOG_DEBUG, "Resync ACK %u != %u",

(What are you meant to do if the block number no longer fits in 2 bytes?)
(line numbers may be slightly different as I also have the -p flag patch
applied.)

One oddity:

14:01:42.703489 IP 10.111.52.39.6911 > 10.111.52.92.tftp:  32 RRQ 
"\Boot\winpe.wim" octet tsize 0  
        0x0000:  4500 003c 0169 0000 1411 27e8 0a6f 3427
        0x0010:  0a6f 345c 1aff 0045 0028 2cc0 0001 5c42
        0x0020:  6f6f 745c 7769 6e70 652e 7769 6d00 6f63
        0x0030:  7465 7400 7473 697a 6500 3000
14:01:42.706136 IP 10.111.52.92.49376 > 10.111.52.39.6911:  18 tftp-#6
        0x0000:  4500 002e 0000 0000 4011 0000 0a6f 345c
        0x0010:  0a6f 3427 c0e0 1aff 001a 7d8c 0006 7473
        0x0020:  697a 6500 3230 3136 3134 3539 3600
14:01:42.706169 IP 10.111.52.39.6911 > 10.111.52.92.49376:  17 ERROR EUNDEF 
TFTP Aborted"
        0x0000:  4500 002d 016a 0000 1411 27f6 0a6f 3427
        0x0010:  0a6f 345c 1aff c0e0 0019 a356 0005 0000
        0x0020:  5446 5450 2041 626f 7274 6564 0000

Obviously .39 is the client, .92 is the NetBSD tftpd. Why would tftpd emit
a packet with opcode 6?

The next successful transfer also has an opcode 6 initial reply:

14:01:42.709212 IP 10.111.52.39.6913 > 10.111.52.92.tftp:  44 RRQ 
"\Boot\boot.sdi" octet tsize 0 blksize 1420
        0x0000:  4500 0048 016d 0000 1411 27d8 0a6f 3427
        0x0010:  0a6f 345c 1b01 0045 0034 4b45 0001 5c42
        0x0020:  6f6f 745c 626f 6f74 2e73 6469 006f 6374
        0x0030:  6574 0074 7369 7a65 0030 0062 6c6b 7369
        0x0040:  7a65 0031 3432 3000
14:01:42.711909 IP 10.111.52.92.49370 > 10.111.52.39.6913:  29 tftp-#6
        0x0000:  4500 0039 0000 0000 4011 0000 0a6f 345c
        0x0010:  0a6f 3427 c0da 1b01 0025 7d97 0006 626c
        0x0020:  6b73 697a 6500 3134 3230 0074 7369 7a65
        0x0030:  0033 3137 3033 3034 00
14:01:42.711942 IP 10.111.52.39.6913 > 10.111.52.92.49370:  4 ACK block 0
        0x0000:  4500 0020 016e 0000 1411 27ff 0a6f 3427
        0x0010:  0a6f 345c 1b01 c0da 000c a695 0004 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000
14:01:42.711977 IP 10.111.52.92.49370 > 10.111.52.39.6913:  1424 DATA block 1
etc.

but this time the client doesn't treat it as an error.

Cheers,

Patrick