oblique/async-tftp-rs

Executor agnostic async TFTP implementation

async-tftp

Executor agnostic async TFTP implementation, written with smol building blocks. Currently it implements only server side.

The following RFCs are implemented:

• RFC 1350 - The TFTP Protocol (Revision 2).
• RFC 2347 - TFTP Option Extension.
• RFC 2348 - TFTP Blocksize Option.
• RFC 2349 - TFTP Timeout Interval and Transfer Size Options.

Features:

• Async implementation.
• Works with any runtime/executor.
• Serve read (RRQ) and write (WRQ) requests.
• Unlimited transfer file size (block number roll-over).
• You can set non-standard reply timeout. This is useful for faster file transfer in unstable environments.
• You can set block size limit. This is useful if you are accessing client through a VPN.
• You can implement your own Handler for more advance cases than just serving a directory. Check tftpd-targz.rs for an example.

Example

use async_tftp::server::TftpServerBuilder;
use async_tftp::Result;

#[tokio::main] // or any other runtime/executor
async fn main() -> Result<()> {
    let tftpd = TftpServerBuilder::with_dir_ro(".")?.build().await?;
    tftpd.serve().await?;
    Ok(())
}

Add in Cargo.toml:

[dependencies]
async-tftp = "0.3"
# or any other runtime/executor
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

Running examples with cargo

There are some examples included with this crate. You can run them from a source checkout with cargo:

$ cargo run --example tftpd-dir
TFTP directory: ...
Listening on: 0.0.0.0:6969
^C

$ cargo run --example tftpd-targz <archive-path>
Listening on: 0.0.0.0:6969
^C

License

MIT

async-tftp-rs's Issues

No way to gracefully ends TftpServer::serve() loop

Would it be possible to add a way to gracefully stop loop in serve() function?

I should be able to prepare a pull-request adding .until(signal: async_channel::Receiver<()>) like this:

use async_tftp::server::TftpServerBuilder;
use async_tftp::Result;
use async_channel::bounded;

fn main() -> Result<()> {
    let (do_shutdown, shutdown_signal) = bounded::<()>(1);
    /*
     * do_shutdown.try_send(()).unwrap(); // for graceful shutdown
     */

    smol::run(async {
        let tftpd = TftpServerBuilder::with_dir_ro(".")?
            .until(shutdown_signal)
            .build()
            .await?;
        tftpd.serve().await?;
        Ok(())
    })
}

Run inside new thread

How can I run the server inside a new thread?

Finalize server WRQ

Write transfer tests - RRQ

Use atftp to test if transfer is done correctly.

Implement TftpServerBuilder

Builder can be use to define some extra options for tftp server.

Possible options:

• set_max_blocksize - This will set a limit to the blocksize
• disable_blocksize - This will ignore blksize option
• set_mtu_blocksize - (Optional) Read MTU value from the network interface and calculate the maximum blocksize value.

By default blocksize is 512 bytes, but client can request bigger. However we should never accept anything bigger than can be handled based on MTU.

A real life example is using U-Boot to retrieve a file from a tftp server that is behind a VPN. U-Boot by default will request blocksize of 1468 which only works for MTU of 1500.

Provide binary

For convenient use, providing an executable binary (available via cargo install async-tftp-rs for instance) from this crate would be great. This would make it immediately useful for most use cases that just want to serve tftp, and are not looking to embed tftp in a larger application.

I think this crate would work great as an application since it implements most of the TFTP-related RFCs.

BIkeshedding topics:

• the binary name: could probably be tftp-server, or serve-tftp, to reserve space for a future tftp-client

I'm willing to add the binary wrapper implementation and make a PR if you're willing to merge it.