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 ?
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.
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 ?
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.
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).