To improve the flexibility of this library, we should find a way to allow the user to configure their signature type, and allow the user to pass I2CP and tunnel options. @bonedaddy did an example of how to do this bonedaddy@8de0ba3 but I haven't reviewed it yet.

I'm not enough of a rustacean to be completely convinced, but Tokio seems to be a widely used asynchronous I/O framework for rust which, according to the examples: https://github.com/tokio-rs/tokio might be very useful for plumbing connections between applications and I2P. Another @bonedaddy contribution, bonedaddy@9cfc260 we need to give some thought to how we expose this functionality if we do it.

I'm trying to store a session (or, its destination) for later reuse, so my b32 address doesn't change all the time. However, this fails with the error "Invalid destination key: " (yes, nothing follows after that colon), which means an invalid key error is returned by the router.

I wrote the following test to reproduce this issue:

#[test]
pub fn from_destination() {
    // Build an I2pListener with a "TRANSIENT" session
    let listener1 = I2pListenerBuilder::default()
        .with_options(SAMOptions::default())
        .build()
        .expect("Failed to build listener1");

    // Extract listener1's `destination`
    let listener1_dest = listener1
        .local_addr()
        .expect("Failed to get local address of listener1")
        .dest()
        .string();

    // Attempt to build a new I2pListener, recovering the previous session
    let listener2 = I2pListener{
        forward: StreamForward::with_session(&Session::from_destination(
            i2p::sam::DEFAULT_API, 
            &listener1_dest, 
            SAMOptions::default()).expect("Failed to create session for listener2")
        ).expect("Failed to create StreamForward for listener2")
    };

}

To be honest, I have no idea what's happening. I traced i2p-rs's code and the value of listener1_dest seems to be exactly what is replied by the router in Session::naming_lookup - thus should be a valid destination with bells and whistles.

This may be a router issue just as well as an i2p-rs issue...

I would like to have access to manually setting the SAMOptions for my I2PListener. Before I go ahead and code something for a PR, would the following approach be okay for you?

Since there are already different functions for creating an I2PListener, I would implement an I2PListenerBuilder where one can first set all options as one likes and then calling a build() function on that builder returns the I2PListener just as the different bind functions do it now.

If you have any other suggestion, I'm happy to hear about it and will try to integrate it. I'm planning on using this lib for a personal project of mine, I'm happy to contribute something as well :)

Overview

I'm running into issues with building a tcp reverse proxy server that services multiple clients. If one of the clients disconnects without properly terminating the session, the I2PListener is unable to accept new incoming connections. As long as all clients disconnect appropriately, the server will be able to accept new connections, but the moment a client disconnects without properly terminating the connection, further calls to accept will return the following error

DEBUG 2022-04-12T01:39:26Z: i2p::sam: -> STREAM ACCEPT ID=Fb4cqmgbQwofVMYg SILENT=false

DEBUG 2022-04-12T01:39:26Z: i2p::sam: <- STREAM STATUS RESULT=INVALID_ID MESSAGE="STREAM SESSION ID Fb...wofVMYg does not exist"

ERROR 2022-04-12T01:39:26Z: server::reverse_proxy::ip: failed to accept incoming connection Error {
    inner: 
    
    Invalid stream id: STREAM SESSION ID Fb...wofVMYg does not exist,
}

Possible Causes

I've been having this issue for a few days now, and have been unable to work out why this is happening. The only inclination i have is from https://geti2p.net/en/docs/api/samv3

This makes the session ${nickname} listen for one incoming connection request from the I2P network. ACCEPT is not allowed while there is an active FORWARD on the session.

However further down the documentation notes

As of SAM 3.2, multiple concurrent pending STREAM ACCEPTs are allowed on the same session ID (even with the same port). Prior to 3.2, concurrent accepts would fail with ALREADY_ACCEPTING.

So I feel like accept should still work.

Reproduction Steps

$> git clone https://github.com/bonedaddy/b0n3r.git
$> cd b0n3r && make build
$> ./boner-cli config new # fill out server settings as needed
$> ./boner-cli utils gen-dest --dest-name <your-dest-name> # generates a destination and stores the information in the config file

Then update your config file with tunnel settings such as this:

    - in_length: 2
      in_quantity: 3
      in_backup_quantity: 6
      out_length: 2
      out_quantity: 3
      out_backup_quantity: 6
      name: yolo

Now start a test tcp socket echo server in one terminal:

$> ./boner-cli server tcp-echo --listen-ip 127.0.0.1:34430

In another terminal start up the tcp reverse proxy server using the previous tunnel and destination configuration names, which forwards requests to the tcp echo server

$>  RUST_LOG=debug ./boner-cli server reverse-proxy --destination-name <..> --tunnel-name <..> --forward-ip 127.0.0.1:34430

Now start the example client which authenticates with the reverse proxy server and solves the VDF captcha (may take upwards of 1->2 minutes).

$> RUST_LOG=debug ./boner-cli client echo --destination <base32-ip-address-of-destination>.b32.i2p:0 

Once the captcha has been solved and the client is authenticated, leave the terminals running for a bit (seems to take maybe 10 -> 15 minutes) and one of the clients will disconnect and the errors start happenign

I recently learned about i2p and would like to play around with it. I have not successfully gotten the i2p-rs eepget example to run.

I apt installed i2p (following instructions here https://geti2p.net/en/download/debian), then ran i2prouter start. I was then able to successfully run eepget http://stats.i2p.

However when I run cargo run --example eepget http://stats.i2p, I get a "Connection refused" error.

Is this crate still in development or is it abandoned