A project to provide VPN access to the River System Raspberry Pis to allow WMT Volunteers and Staff to log in from home. Triggered by the COVID19 lockdown
Penri wrote: ↑24/07/2020, 11:51I'll be visiting WMT within the next half hour for a few minutes, I can cycle the big switch then if required.
Penri,
It would be useful to find out if power cycling of the Big Switch does fix this, so I can stop pursuing other issues. Could you text me just before you are going to do it, so I can check that I still can't log in directly? If you then do the cycle and text me again, we can be pretty certain that this is the problem and not a red herring.
OK. It's confirmed, if a Pi is rebooted then the Big Switch must be rebooted (eg Power Cycled) in order that we can log in to that Pi over VPN. I have no idea why this should be and would welcome any suggestions.
Penri rebooted the switch this morning and the two Pis that wouldn't let me in became accessible again.
Then Penri noticed that the river wasn't flowing and the Sump was overflowing. My fault, I forgot to ask Nick to waggle the probes after I rebooted wbuttspi and sumppi. Initially waggling the probes didn't work so after a further reboot of sumppi I lost contact with it again. The Big Switch was rebooted and I got in again.
So lessons learned (or relearned in one case). After a reboot, power cycle the Big Switch and waggle the probes to get readings coming in again.
It is pretty common for ADSL and VDSL connections to have an MTU of less than 1500, usually somewhere in the 1450-1500 range, depending on the type of the physical connection and the exact protocol used to establish it. This value doesn't change over time, but it's often a manual setting, so if the router was not configured by the ISP, then it is the responsibility of whoever installs the router to set the correct MTU based on the ISP's documentation. (Though, ISPs are not always particularly helpful about telling you the MTU.)
If the correct MTU is set for the WAN link, then the router will fragment any oversized packets into smaller ones to make them fit through the link, and all will be well. But it probably won't even have to bother doing that, because the operating system running the VPN will be able to detect the reduced MTU of the WAN link and automatically adjust the VPN's own MTU to make sure that the encrypted VPN packets are always small enough to pass through it without burdening the router with the task of fragmenting them. Magic.
If the router is not configured with the correct MTU for the WAN link, then it may well just silently discard any packets larger than the correct MTU. The router thinks it is forwarding them to the internet, but in reality they are not getting through. The operating system running the VPN won't detect this, and will think it can send 1500 byte packets to the internet. The router doesn't even bother to fragment them, because it's been told those packets will fit through its WAN link. By and large, this will only affect uploads, and only uploads consisting of packets larger than the true MTU of the link. The router at the ISP's end of the WAN link probably has the correct MTU setting, so packets coming down from the internet should be the correct size to get through, regardless of the MTU setting on the office router.
Scenario: The operating system thinks it has 1500 bytes to play with for the VPN. Therefore it thinks it has 1500 bytes minus some overhead for the packets that are going inside the VPN. It uses that size for the SSH packets. The SSH packets fit into the VPN fine. It all works, until those 1500 byte packets reach the router, which gladly accepts them and tosses them over the wall, never to be seen again.
Regarding POS terminals; I think Terry is correct that POS terminals don't need much bandwidth. Remember that they used to use dial-up connections direct to the payment processor, rather than an internet connection. Those dial-up connections cannot possibly have been faster than 56k, and even then the majority of the time was spent dialling and connecting rather than actually transferring data. The terminals probably benefit from a low latency internet connection, but the bandwidth requirements are unlikely to be high. (Internet? Luxury! When I were a lad, we had one telephone line for card payments, telephone calls and faxes.)
Noting that we might not be quite out of the woods here - if I stay connected for a few tens of minutes (say I leave it tailing the logs after an update) , it eventually tends to hang. It did that this morning, but perhaps I was connected at the same time as Terry, or the WMT internet connection was being used by something else.
I'm quite happy to chalk this up to our low bandwidth (assuming this hasn't yet been fixed), but thought I should mention.
I've seen that once or twice too. I'm hoping that it is just the bandwidth too.
When I updated the Lady hanham SAC and V1 Gate Valve Pi this morning, I noticed that the download speed that I was getting was around 700 to 800 kBps (eg around 7 to 8 Mbps. When i installed nmap on the Lady Hanham SAC Pi, I only got 400 to 500 kBps.
The bandwidth issues is going to be with us for a time yet, the ISP have been told that there is not enough capability in the "exchange" to add another (our) FTTC link.
NB: Has any progress been made with the internet connection speed? The VPN is still a bit slow and unreliable. Perfectly usable, but a bit frustrating.
The internet link speed is still as it was, I check with the ISP on a fairly regular basis and they had no good news from OpenReach to share with me this week.
I hope they offer some compensation.