Jake Thompson

@natuShubham96 any resolution on this

Also to note, I think I have also seen this behavior with a long running S3 client also. Still determining if it is this same problem or something else.

As far as I can tell this is happening on any client that is "idle" for over 60 seconds. If it is then used, it will receive the error. Looking...

And my assumption seems to be correct. The following will allow the client to re-establish the connection and will not throw the error. ```rust let https_connector = HttpsConnector::new(); let cred_prov...

@sitegui Yeah the api changed since I originally posted this, looks like you have it right though. ```rust let cred_prov = DefaultCredentialsProvider::new().unwrap(); let mut builder = HyperClient::builder(); builder.pool_idle_timeout(Duration::from_secs(50)); let http_client...

@silverjam problem with a new client every operation is you get a fairly large overhead to setup the connection. Reusing the client that keeps the connection open can save 100-200ms...

Also, to note in this setup all nodes are behind different NATs on different networks. Hub and spoke with the hub being the lighthouse and spokes going to hosts on...

@nfam similar setup. Public lighthouse on digital ocean, laptop on home nat, and server in AWS behind a NAT. Local and AWS are using different private ranges(though overlap should be...

My Config: `nebula-cert sign -name "lighthouse" -ip "192.168.100.1/24"` `nebula-cert sign -name "laptop" -ip "192.168.100.101/24" -groups "laptop"` `nebula-cert sign -name "server" -ip "192.168.100.201/24" -groups "server"` Lighthouse: ```yaml pki: ca: /etc/nebula/ca.crt cert:...

@nfam similar error, not sure it's the problem > Error while validating outbound packet: packet is not ipv4, type: 6 packet="[96 0 0 0 0 8 58 255 254 128...