gRPC errors using ttnctl uplink :- works on some lan networks, not others

I seem to have a strange issue with trying to connect to the TNN backend.

Using ttnctl uplink I was able to send a test packet when my laptop was on my company network.

However, on my home network, on the same laptop, I get

DEBUG grpc: addrConn.resetTransport failed to create client transport: connection error: desc = “transport: authentication handshake failed: context deadline exceeded”; Reconnecting to {discover.thethingsnetwork.org:1900 }

I took a Wireshark capture, and can see packets flowing in both directions between my laptop and 52.178.215.58, so its unlikely to be a NAT/firewall issue.

Any ideas on why ttnctl uplink may work for me on one network, but not the other ?

Thanks

I tried again with my 4G phone hotspot, and that also works when I use ttnctl to send a message to the backend.

So now I wonder if my public IP address for my home network has been blocked somehow ?

Thanks

http://www.yougetsignal.com/tools/open-ports/

Ok port 80 is closed inbound… so are you saying that the server will first check if port 80 is open, and only then respond to a TLS Client Hello on the already established socket ?

Seems a bit weird … but would make sense if the server is checking if the client (GW) can receive inbound connections for downlink data.

uh no… but that seems strange because then you won’t see this page :wink:

you have to check other ports 1900/ 1883

Ok a bit confused here …

I captured all traffic to-from 52.178.215.58 (discover.thethingsnetwork.org) and in the working case, I get a Server Hello back after a client Hello, and the TLS handshake completes.

In the failing case, I do get a TCP ACK back for the client hello, but then many DUP ACKs and finally the connection is closed with a FIN , FIN/ACK ACK.

So in this case, the grpc is failing to make the initial outbound connection … so I don’t see why I need ANY inbound ports to be open ?

well sorry can’t help you … but sure someone else can
https://www.thethingsnetwork.org/docs/network/cli/configuration.html

* the network status doesn’t indicate a problem

No problem …must be something to do with my ISP.

Even curl or a browser to port 1900 does not work… but works instantly when I use a mobile hotspot…

Next I will try with my ISP router set to modem mode… instead of router mode …

Ok, it looks like an. issue with my ISP ! Perhaps they are caching the connection because if I use a VPN, then it works just fine.

If this is really the case, is there a way of bypassing the discovery server by setting some configuration locally?

I have not looked at the code in depth, so I am not sure at present what the role of the discovery server is.

This indeed seems to be a problem with your network/ISP firewall configuration. If you can’t get some admin to click a few buttons there, the only way to “solve” it is to use a VPN or similar workaround.

Circumventing the Discovery server won’t help you, because then you’ll have exactly the same problem connecting to the other components.

My ISP is looking at the issue, but I don’t expect them to resolve it. I suspect a WAN accelarator may be causing the issue.

Does anyone else in the UK use Virgin Media Broadband to connect to TTN ?

Yepp, same here, seems to be VM specific, as it works like a charm on every OTHER network I’ve tested.

32

Thanks @TheBluProject for confirming this… I was going crazy ! I logged a ticket with VM (with trace routes and Wireshark, both with and without vpn) , but don’t expect any response .
For now I am using NordVPN on my yet-to-be built Raspberry PI gateway.

I know this post hasn’t been replied to in two months however I have the same issue and it does indeed some to be a correlation to Virgin Media in the UK. Does anyone else have a solution without a VPN?

None whatsoever, as VM is blocking the outgoing connections to the SSDP port as a “security feature”. I have just moved to Virgin Media Business, and will update the thread once it has been installed (early Jan).

1 Like