Jump to content











Photo
- - - - -

TFTP client : Blocksize no taken in account ?

client blocksize

  • Please log in to reply
12 replies to this topic

#1 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 08:53 AM

Hello,

I'm developping a TFTP server on an hardware board, and trying to test it with TFTPD64 in client mode. PC directly connected to board with cable.

Works very well when specifying blocksize=512

But if I use value 1024 for example (or 1428), the actual block size received on my server is still 512 bytes, and my server consider this is the end of the file and terminates the transfer.

What's wrong ?

 

Thanks

Aurelien

 



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13694 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2017 - 10:33 AM

Only some semi-random considerations.

Did you try the TFTPD64 in client mode connected to another TFTP server?

What do you mean the block size received on server?

I mean is the TFTPD64 that no matter what size you choose sends anyway only 512 bytes size requests or is the server that truncates it nonetheless to 512 bytes?

 

It is not clear (to me) what sends what, in theory a Server should be able to serve files with a blocksize as requested by the client, see as an example:

https://thwack.solar...om/thread/23944

so there are two sides that can be the cause of the issue:

1) the client not sending an appropriate blocksize request

2) the server not parsing correctly the request and serve nonetheless a 512 byte blocksize packet

 

:duff:

Wonko



#3 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 10:42 AM

Hi,

TFTPD64 works as a client and I want to write files into a remote peripheral acting as a server (contains a SD card). To optimize speed I want to fit maximum data in each frame. I have started with 1024 (easier to begin, I will then switch to 14xx after adapting the SD card write buffer procedure).

 

I set the block size to 1024 on TFTPD64, and then "put", and I'm running my target in debug mode and I can see the variables values on breakpoints. And the data payload size I receive on a packet is still 512 bytes, not 1024.

 

Aurelien



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13694 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2017 - 11:07 AM

Try another client instead of TFTPD64 (just to make sure that the issue lies in TFTPD64 and not in *something else*)

 

This one is freeware (the client only) and explicitly supports different blocksizes according to RFC2348:

http://www.tftp-serv...ftp-client.html

 

Still I am not sure to undestand the setup, usually the server is supposed to serve files and the client is supposed to ask for them and receive them, not the other way around. :unsure:, AFAICU the blocksize is determined by the request.

 

:duff:

Wonko



#5 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 11:40 AM

In my case the server is a stand alone peripheral on which a remote PC can add files. It much easier to code it this way, server is just waiting for write requests...In inversed role where the PC is a server, it should add an auxiliary control channel to trigger the requests from the client...not very efficient :)

I'm surprised when you say that the block size is determined by the request. I looked at the code of the server (I did not write it myself, I'm just doing adjustements), and I see references to block size sent in any packet. It is thereby possible that the stack I'm using does not support this feature and I would need to add it. I look into the RFCxxx and keep you informed.



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13694 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2017 - 12:23 PM

Just a wild guess - mind you - but the generic idea of a server/client setup is (was) that of a very powerful server capable of doing *anything* and the client to be as simple (and as low-power) as possible.

 

So the idea makes sense to me, a server can serve *any* size of packet as requested by the client, that possibly has a given (hardcoded) blocksize only in order to be "simpler".

 

Reading "between the lines" of the RFC2348 (which in itself is a late (1998) extension):

https://tools.ietf.org/html/rfc2348

 the *feeling* I expressed above is reinforced, the TFTP is used because the client side needs to be as simple as possible (but not simpler ;)), the key word here is "negotiate", anything different from the standard 512 bytes block size needs to be negotiated by both parties, but it seems clear enough how the "strong" party in the deal is the server side, that receives a request for blocksize, and then either gives an acknowledgment (OACK) that is equal to OR one that is smaller than the request from the client .

So ultimately, it is the server that determines the actual blocksize to be used in the transfer.[1]

 

Then it is again the client "responsibility" to either accept the equal or smaller than blocksize in the OACK or terminate the connection with error 8.

 

:duff:

Wonko

 

[1] This makes IMHO a lot of sense in another hypothetical scenario, after some specific network tests, a particular TFTP server could be programmed in such a way to accept (say) 8192 bytes blocksize from LAN IP's (or MAC's) known to be on a "fast branch" of the network, but only accept a max of (still say) 2048 bytes blocksize from LAN IP's (or MAC's) knowing to be belonging to a "slower branch" of the network, in order to get a valid compromise between speed and reliability.



#7 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 12:28 PM

Yes indeed, my current server stack does not return the size so the exchanged are done at 512 bytes. I will modify it to handle higher values and return the correct ACK. Next step will be to increase block size > TCP frame size (multiple packets) to speed up again the link.



#8 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 01:54 PM

Tried to modify the answer to the write request.
OACK frame sent is :
<0x00>6<0x00>blksize<0x00>1024<0x00>
 
But host continue to send packets of 512 bytes :(


#9 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 03:11 PM

Using the TFTP client you advised me, it sends the write request but does not handle my answer because timeout elapses and request is re-issued...I miss something, but don't know what :(



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13694 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2017 - 03:58 PM

Semi-random question.

 

Is 1024 a valid value?

 

https://blackfin.ucl...p_a_tftp_server

What happens with 1468? :unsure:

 

As hinted before, can you put together a surely RFC2348 compliant server and test the client against it?

(and viceversa)

 

Then you will have some logs to compare with the ones you are capturing from "your" client.

 

:duff:

Wonko



#11 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 05:31 PM

I can select "1024" in TFTPD64, so I assume this value is supported. Moreover, I looked at the write request sent by the client, it contains the string "blksize 1024". 

I will eventually test with another TFTPD64 PC running in server and read the results with a sniffer...simpler to say that to do.


Edited by aurelienr, 29 June 2017 - 05:31 PM.


#12 aurelienr

aurelienr
  • Members
  • 8 posts
  •  
    France

Posted 29 June 2017 - 05:47 PM

Finally I got it working...just suppress the null character after opcode...

Correct OACK answer is <0x00><0x06>blksize<0x00>1024<0x00>

(in my previous example i wrote '6' in ascii but I was sending it correctly in raw value)



#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13694 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 June 2017 - 06:04 PM

Good catch :), didn't notice the <0x00> inserted after the (1 byte, aka 0x0006) opcode   :blush:

 

:duff:

Wonko







Also tagged with one or more of these keywords: client, blocksize

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users