-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
read udp [::]:57470: i/o timeout #41
Comments
Hi 860git! Sorry for the long delay with response. Do you still need help debugging your setup? |
Hey Pin, I am getting this error. I am getting tftp files from many devices but for some I am getting this error. Any idea how can I solve it? |
Hiya, I recently build this tftp lib into an https://github.com/purpleidea/mgmt/ resource. The code for that is here: https://github.com/purpleidea/mgmt/blob/master/engine/resources/tftp.go When using this to provision the firmware for some grandstream GXP1625 VOIP phones, it seems to work, but then hang... I eventually get this error:
The server is blocking here Line 303 in 1fd60d6
Line 409 in 1fd60d6
I get the above error inside my readhandler (it looks very much like the example in your README) and in particular, the error comes from this line:
Unfortunately, it seems that for whatever reason (a TFTP protocol misunderstanding or perhaps a bad TFTP client implementation, or ???) something happens which causes us to block at that ReadFrom line. The BAD part about this is that it's not cancellable AFAICT. We need a variant that takes a https://golang.org/pkg/context/ and lets you kill it, since the Shutdown() method of server isn't causing it to unblock. HTH, and please LMK |
This helps for debugging this kind of issue: pin/tftp#41 (comment)
This helps for debugging this kind of issue: pin/tftp#41 (comment)
If somebody else stumbles upon this, as I did.. mine hung on a large file (~100mb). |
The issue occurs when tftp use ramdom port as src port instead of default tftp server port 69. The UDP package is dropped by host machine, then the client in VM/docker container can't get the udp package. |
@purpleidea I quote the TFTP protocol for ports. Normally bi-direction udp connection uses fixed ports, but TFTP is not, The reply package from TFTP server use random port as src port. "In order to create a connection, each end of the connection chooses a TID for itself, to be used for the duration of that connection. The TID's chosen for a connection should be randomly chosen, so that the probability that the same number is chosen twice in immediate Every packet has associated with it the two succession is very low. TID's of the ends of the connection, the source TID and the destination TID. These TID's are handed to the supporting UDp (or other datagram protocol)as the source and destination ports. Are questing host chooses its source TID as described above, and sends its initial request to the known TID 69 decimal(105 octal)on the serving host. The response to the request, under normal operation,uses a TID chosen by the server as its source TID and the TID chosen for the previous message by the requestor as its destination TID. The two chosen TID's are then used for the remainder of the transfer." |
it is passed when the server and the client are all on the same machine.
but other situation,such as between the real machine and the virtual machine, it can't work, and the error returned are:
the client(when send file):
read udp [::]:57470: i/o timeout
the server:
and the other question
what's the effect of the parameter
filename
offunc (c Client) Send(filename string, mode string) (io.ReaderFrom, error)
?The text was updated successfully, but these errors were encountered: