Broadband upgrades

Not long ago a telegraph pole appeared on the street outside our house to take wires between two existing poles. I think it was placed so that those wires didn’t come across our land as they seem to droop quite a lot. Associated with said pole, and others in the area are pole mounted fittings to do with BT’s full fibre offering. Today, a flyer came in the mail offering full fibre service at various speeds. That will make a change to our current 15Mbps ADSL. But there may be issues.

Do we need the speed? Well, currently we can watch fairly good res YouTube on one TV, a BBC program on another, and all the less bandwidth hogging tasks that happen all the time such as Pi-Star, various Internet links to various bits and bobs, email, general web browsing etc. We only notice issues where video games peg out and Windows OneDrive sets off synchronising at full whack. Currently I have OneDrive (not mine, I don’t even use it!) configured to play nicely (honestly, if you’ve ever let it fully loose it’s a real bandwidth hog, quite unlike iCloud which never seems to get in anyone’s way and still does everything it needs to), and the switch port that the gaming PC is on is throttled so it cannot take the full 15Mbps.

So yes, more speed would be useful. We also found that a YouTube rented 4k video will buffer constantly.

But… and this is a big but, will our chosen ISP deploy cg-nat? This is something many of us will face and the issue is that cg-nat makes it very difficult, if even possible to have incoming connections. Some things will (or should!) just work, like SIP phones as the sessions are initiated by the phone constantly polling the server(s) rather than calls actually coming in. But others – things like Echolink, Allstar, 44net and the AXIP connections used on GB7RVB all need connections coming in as well as out, and cg-nat will break those. Some Pi-star configurations will rely on incoming connections too.Some PC games will not play nicely with cg-nat either.

So that is a concern and it is difficult to get an answer from many ISPs as you never talk to a techie. Some do say so, some offer static IP addresses which, provided they mean public IP addresses exclude the use of cg-nat. With BT I can get that but only if I buy their business offering which is more expensive.

Yes, I could set up a VPN to my VPS and do it that way, assuming the VPN will play with cg-nat. But that adds even more complexity.

There is also the issue of the telephone. We still have a landline although these days it sees very little use and only for inbound calls. Do we ditch the number and rely on mobiles, will SIP phones really work, can I move our number to a SIP service or just get a new number?

And let’s not forget the issue regarding the inability to dial 999 (the emergency number, the UK’s version of 911) in a power cut. With the current switched copper telephone network the phones are powered all the way from the exchange. Not so with fibre as if your in-house fibre modem has no power you have no phone. But for us that is less of an issue really, we have at least one mobile phone in the house at all times, and, hey, I have at least one 2m/70cm FM HT charged at all times. We – collectively, radio amateurs – are generally better off that way.

Anyway, as it stands the flyer only just arrived and I will probably wait for one of the neighbours to take the plunge first! I can’t even remember if I am still on contract with our current ISP as they never called to confirm and it is not possible to find out online (which I find rather stupid for an ISP but there you are).


I have an allocation within 44net (aka AMPRnet) and so I set up a gateway based on a Raspberry Pi 4B – well, I had one unused one! My allocation is a /29, so 6 IP addresses. The Pi setup is the Pi 4, a PoE HAT, an Ethernet USB dongle for the second Ethernet interface, and a neat 3D printed case that I have used before and which has the height for the HAT.

Software-wise it’s just Raspberry Pi OS, plus a daemon called ampr-ripd which listens for gateway announcements and sorts out routing tables. My link is to the IPIP mesh so I am not doing BGP or anything fancy.

My initial experiment used the wifi interface and I could connect to 44net via the phone / wifi AP software running on the Pi. That worked ok but really I wanted to be able to connect a couple of systems and not bother with wifi. As I had an Ethernet dongle left over from the dismantled QO100 transceiver that did the job nicely. The plan is to connect this to a small network switch offering a couple of Ethernet ports to be used on 44net. So far, the only system connected is my ageing Samsung Netbook which is is horribly slow even with Lubuntu and has a weird screen xy format. But it works nicely using telnet to access a chatroom on 44net.

The basic configuration and ideas came from In particular, the scripts there set up the IPIP tunnel and add iptables rules.

The Pi has been set as the default DMZ host via the ISP broadband router (at which point it began to get hammered with ssh attempts which reminded me to disable password authentication!).

I have yet to get DNS names allocated so I cannot route over the wider Internet, not that this matters in particular as I can access other 44net services anyway.

A GPS based Raspberry Pi Stratum 1 NTP server

I decided to make my own Stratum 1 NTP server for the home. No, I don’t need the accuracy, but localising stuff like that is always interesting. So, I recently purchased an Uputronics GPS HAT from Pi Hut which is marked Raspberry Pi GPS+RTC Rev 6.4. It arrived next day along with some other bits. I also got another PoE HAT and already had a Pi 4. Raspbian installed on an SD card – this time I remembered to first set it up to work via ssh – and the Pi booted ok with the GPS board flashing it’s ‘time pulse’ LED once per second.

I followed instructions on the web, in particular from the two websites shown at the bottom of this post. Initial setting up of the Pi involves the use of raspi-config to stop the serial port login shell but leaving the port enabled, and disabling serial getty and bluetooth. At this point, doing cat /dev/ttyAMA0 should return data from the GPS receiver but all I got was garbled characters. More on that later.

The next step was to enable PPS support which involves modifications to /boot/config.txt and a module adding to /etc/modules, plus downloading pps-tools. Running sudo ppstest /dev/pps0 looked ok but again, more on that later.

Next was to install gpsd and modifying /etc/default/gpsd plus setting it up to run at boot time. After a reboot running sudo service gpsd status returned valid information.

The gpsd-clients package was installed which includes gpsmon. Running gpsmon showed that all was not well. It generated a few lines but nothing that meant any sense.

I then returned to sudo ppstest /dev/pps0 and noticed this time that all it was giving was timeouts. I may well have missed this in my haste earlier as it reports ok, but then gives timeouts. An, unfortunately not recorded web page suggested adding arm_64bit=0 to /boot/config.txt and after rebooting sudo ppstest /dev/pps0 now produced a valid line, once per second. Ok.

Retracing my steps I ran gpsmon again to take a closer look and noticed that in the few lines it managed to display was the entry ‘”bps”:9600’.

That was the lightbulb moment.

The GPS board defaults to 115200. Stopping gpsd and running minicom -b 115200 -o -D /dev/ttyAMA0 produced valid GPS data. Modifying /etc/default/gpsd to set the baud rate to 115200 (GPSD_OPTIONS=“-n -s 115200”) fixed the issue.

But, gpsmon still does not produce all the output that I had expected, in particular it does not populate the time and date fields. Running cgps does show valid information and suggests that all is well and there is something I am missing regarding gpsmon. At the end of the day it all appears to be working fine.

The next package installed was chrony. This all went to plan and running chronyc and its sources and sourcestats options showed valid data after the system had settled down for a couple of minutes after boot.

The final leg of this journey was to set up various systems to use the new NTP server. On the Pi systems this is typically done via /etc/systemd/timesyncd.conf and then restarting systemd-timesyncd; the Mac was done via System settings –> General –> Date & Time, and the various network switches and wi-fi APs each had their own way but each was obvious. Of course one thing to remember is these are all static systems that never leave the house. Setting a local IP into a mobile system would not be that great an idea.

The final thing that tripped me up was that in chronyc options such as clients would give an error. Running chronyc under sudo fixed those.

And there it is in a tall metal Pi case also from Pi Hut and rather unceremoniously chopped with some cutters to enable the SMA connector to fit. This case has plenty of vertical space for the Pi, the PoE HAT and the GPS HAT.




Recent Posts