TFTP Transfer option negotiation failed error 8 packet trace

Question

Hey guys,

I have been trying to figure out why my netboot TFTP transfers are failing when the client is asking for option negotiation from the TFTP server.

Basically wireshark has helped me determine that the communication goes like this.

Client (port 10545)-> Server (port 69) Read request for file.exe - Transfer type: octet, blksize\000=512\000, tsize\000=0\000
Server (port 52104) -> Client (port 10545) option acknowledgement, blksize\000=512\000, tsize\000=994464\000
Client (port 10545) -> Server (port 52104 Error Code, Code: Option Negotiation failed: Message error code 8 client or user aborted transfer

A 2nd attempt is immediately tried again but this time with out the tsize option.

Client -> Server Read request for file.exe - Transfer type: octet, blksize\000=8192\000
Server -> Client option acknowledgement, blksize\000=8192\000
Client -> Server acknowledgement, Block:0

It is then fine.

So either the client cant get its OACK or options acknowledgement back to the server or the client is just outright refusing the servers option acknowledgement and then cancels the transfer.

I cant do a shark on the client because it is in firmware booting mode, and I dont have a switch that can do port mirroring.

I have scoured the inter webs for some kind of a solution to whats going on. Maybe the experts here can give a helping hand.

Thanks in advance!!!

Answer 1

1

It looks to me that the client first tries to negotiate a blocksize of 512 and requests the filesize. Then when it does receive the filesize, it decides to use a blocksize of 8192 instead of 512. No need to use the tsize option again, as the filesize is already known.

According to the RFC, the tftp server should not return a tsize option in the response to the second request. Did you really see that in the option acknowledgement?

answered 01 Jul '13, 13:43

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

Yes good call and sorry for the typo! You are right the 2nd request looks like this.

Client -> Server Read request for file.exe - Transfer type: octet, blksize\000=8192\000 Server -> Client option acknowledgement, blksize\000=8192\000 Client -> Server acknowledgement, Block:0

What is interesting is that when I fire up my client and ask the server for the same thing.

tftp mode octet tsize on blksize 8192 get file.exe

Client -> Server : Read request for file.exe - Transfer type: octet, tsize\000=0\000, blksize\000=8192\000 Server -> Client : option acknowledgement, tsize\000=994464\000, blksize\000=8192\000 Client -> Server : acknowledgement, Block:0

What i did notice about this one is that the server port is always port 69.

Also according to that link.

If the client rejects the OACK, then it sends an ERROR packet, with error code 8, to the server and the transfer is terminated.

Once a client acknowledges an OACK, with an appropriate non-error response, that client has agreed to use only the options and values returned by the server. Remember that the server cannot request an option; it can only respond to them. If the client receives an OACK containing an unrequested option, it should respond with an ERROR packet, with error code 8, and terminate the transfer.

So according to this its like the server is sending back an OACK with options that the client did not ask for in the first place even though the options look proper in the trace ?

(01 Jul '13, 14:19) ClassicII

Well, there are options for which the value may change between the request and the acknowledgement. tsize is one of them, see RFC 2349

(01 Jul '13, 14:27) SYN-bit ♦♦