-
Notifications
You must be signed in to change notification settings - Fork 25
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
#use of connect() for tftp protocol #75
Comments
Question: Are you trying to write a TFTP client or a TFTP server? A TFTP client in an embedded context is usually some PC where someone is trying to write data to or read data from an embedded device (which is operating as the TFTP server, e.g. serving a file, such as the application image, to the client for modification over the network). It seems odd that the embedded device would be the TFTP client, since that implies it would be requesting data from a PC.
UdpClientStack::connect takes a You mention that you want to write a TFTP client. In this case, you need to:
With this data flow, it seems like you would: // Send a TFTP request to a server
let mut socket = stack.socket().unwrap();
stack.connect(&mut socket, "server:69").unwrap();
server.send(&mut socket, TFTP_REQUEST).unwrap();
// Read the TFTP response from the server.
let (resp_size, server_addr) = server.recv(&mut socket, &mut TFTP_RESPONSE).unwrap();
// Reconnect to the port that the server is using for the transfer now that we have initiated the transaction.
server.connect(&mut socket, server_addr).unwrap(); |
Thank you for reply! |
@ryan-summers said:
We've tried this flow, but (at least with But replacing |
This may come down to the implementation of I'd recommend taking a look at Wireshark captures to see what's happening as well for debugging. |
It would, but the |
Ah indeed I was mistaken. When trying to implement a "TFTP Client", you need to (confusingly) implement UDP server traits. // Send a TFTP request to a server
let mut socket = stack.socket().unwrap();
stack.bind(&mut socket, 8081).unwrap();
stack.send_to(&mut socket, "server:69", TFTP_REQUEST).unwrap();
// Read the TFTP response from the server. This will be an ACK (if writing) or a DAT (if reading).
let (resp_size, server_addr) = stack.receive(&mut socket, &mut TFTP_RESPONSE).unwrap();
// TODO: Service the incoming frames if receiving, produce the outgoing frames if writing That being said, generally an embedded "TFTP Client" is not what a user would want, but rather a "TFTP Server". The TFTP server would make files (on the embedded device) readable and writable by a TFTP client (e.g. a PC). That way, a user on a standard PC could e.g. |
That confusion was created by me. I understood that in the over the air update usecase (which you are describing, i think)the embedded device would download the file (firmware, image etc.) from the PC, therefore act as a client. But it makes more sense as you describe it, since otherwise the embedded device would need to initiate the transfer. |
It seems to me that part of the trouble is that it's not clear from the trait definitions whether it'd even be allowed for a socket to be |
Hello!
I'm trying to write a tftp-client on the basis of embedded-nal UdpClientStack
According to tftp protocol, the client (randomly) chooses its own port, e.g. client:8080. Then the client sends a request to the server on port server:69. The server (randomly) chooses a port as well, e.g. server:8081, and sends an answer to the client on port client:8080. The whole transfer (read or write) will now use the two ports client:8080 and server:8081.
The problem is that according to embedded-nal (and its implementation std-embedded-nal) fn connect() has not the same functions as in std::UdpSocket. It not just connect the socket with remote address (as in std::UdpSocket), but creates a socket by binding with unspecified port and then connect with remote address. So, each time when we use embedded-nal::connect, we create a new socket which is connected with specified remote address. It seems impossible to connect the existing socket with another remote address according to embedded-nal... or i don't understand something :(((
Maybe for tftp-client it is necessary to use create socket without connection with the help of UdpFullStack, then to bind it with specified local port and send messages with the help of send_to()? Or maybe you may advice me a way to change the remote address of the socket according to UdpClientStack?
Thank you for answers
The text was updated successfully, but these errors were encountered: