Hub Two ssh woes

[#1]

I'm not sure if this was happening before firmware v0.08.00.08297-PN because I am new to the Hub Two (my previous DrayTek having been killed in a lightning strike) but there are strange things afoot with ssh.

After about 40 seconds of an ssh connection, all output ceases and no packets are sent and received. Hitting return a few times causes the buffered output to be returned en masse and then another 40 seconds passes before it all happens again.

This is nothing to do with ssh/sshd version incompatibility, TCPKeepAlilve, IPQoS, ServerAliveInterval or ClientAliveInterval because when I tether the machine to an EE 5G connection it works flawlessly and packets keep flowing. I have also tried fiddling with all these variables to no avail. The firewall is disabled on the Hub and it is a static IP address.

Output:

% ssh user@server "x=0; while true; do echo -e \$x' \c'; x=\$(expr \$x + 1); sleep 1; done"

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118

[#2]

Hi, what device are you attempting to connect to?

[#3]

I have tried a random sample of servers on the internet-at-large that I have accounts on. One is an Amazon EC2 instance, one is a UK2-hosted dedicated server, and a few other cPanel accounts. All seem to exhibit the same behaviour, and we can also rule out port-based chicanery because the cPanel accounts use ssh on port 2233.

Both the EC2 and UK2 daemons are OpenSSH_7.4p1, and the ssh itself is OpenSSH_9.0p1.

[#4]

I have a Hub Two and a static IP address 80.229.nnn.nnn if you want I can try a ssh connection to see if I get to the login prompt. suggest you PM me the host if you want privacy

Dan.

[#5]

@oglord - you seem to have a /29 static IP assignment so I'm somewhat confused to read that you're using a Hub Two.

Exactly how is your network configured?

[#6]

Establishing the connection isn't really the problem. It gets beyond the login prompt, logs in successfully and starts ouputting text fine, until all packets cease. I've verified this with tcpdump at both ends.

See the attached tcpdump. ssh packets flowing happily until time 70.7, then it stops, I hit return a few times and then at 90.6 there is some weirdness, a further 10-second wait, then a retransmission, and things start flowing again. As you can see by the length, packet 2974 contains all the output that hadn't been transmitted for some reason.

[#7]

I used to have it configured with proper IP routing using a DrayTek Vigor 2862ac, but that got killed late last year in an electrical storm (see first post). PlusNet sent a Hub Two, which as we all know just NATs everything to the first available address. It's currently not ideal, but I am waiting for FTTP!

[#8]

When did it start and have you rebooted the hub since? You've a fairly lengthy session at the moment and sometimes the simplest solutions are the ones that work

[#9]

When did it start? That is a very good question! I've had to replace lots of equipment since the lightning strike (and insurance companies take aaaaages to do anything!), so I have only recently got back around to what I was doing last year. It may have always been like this with the Hub Two, it may have been an issue with the firmware update on the 24th of November, I really don't know. I might give the old 'turn it off and back on again' trick a go, but can't really do that at the moment with two people WFH!

[#10]

Well, after restarting the hub the test got beyond 40 seconds, but before I was able to pop the Champagne corks it got stuck again at 80 seconds! Again, pressing return a few times brought it back to life, with the same nonsense in the tcpdump.

% ssh user@host "x=0; while true; do echo -e \$x' \c'; x=\$(expr \$x + 1); sleep 1; done"

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204

[#11]

You look to be using non-default local IP ranges on your LAN so I'm still interested in understanding a little more about how you have your network and hub configured. Am I good to assume that there's nothing local in the chain that is still explicitly configured to use public IPv4 addresses from your 8-block?

I do wonder if the issue would be prevalent using the hub in default configuration with a single client connected to it. I recognise that's probably going to be a pretty disruptive thing to test though.

[#12]

The only real thing I changed was the DHCP range, so it runs from 192.168.1.64 to 192.168.255.253. It has correctly deduced the netmask, because ifconfig reports:

inet 192.168.157.124 netmask 0xffff0000 broadcast 192.168.255.255

I did attempt to manually configure some machines with addresses from the 8-block but the Hub steadfastly refused to route any of them.

I have just changed the DHCP server back to the default 192.168.1.64 to 192.168.1.253 range and renewed the lease, but with exactly the same end result -- see attached -- working fine up to time 55, then nothing until I press return a few times, then weirdness.

New DHCP data:

inet 192.168.1.164 netmask 0xffffff00 broadcast 192.168.1.255