DigitalOcean Referral Badge

Welcome to the Bromley Repeater Group website.

Our VHF & UHF repeaters are located in Beckenham which is a town in the Greater London area of England, within the London Borough of Bromley. It borders Beckenham Place Park and Bellingham in the London Borough of Lewisham.

Our first repeater was GB3OK on 2mtrs. Based mainly on the success of GB3OK a UHF repeater GB3LK was later added.

With the advent of DStar, the 2mtr GB3OK repeater ceased transmitting and was replaced with a DStar repeater using the new callsign of GB7OK.

Shortly afterwards, the 70cms repeater, GB3LK took over the old callsign of GB3OK and was later upgraded to DMR in order to provide the option of both digital systems to our users and its callsign was changed to the current one of GB7LO.

The current setup now looks like this:

GB7LO:  70cms DMR – Tx 439.5125 – Rx 430.5125 (9 MHz split)
GB7OK:  2mtr FM/YSF – Tx 145.7125 – Rx 145.1125 (600 kHz split)

YSF Reflectors:

#20458 GB CQ-LONDON-UK

#20456 GB CQ-GB7OK-UK 

Finally, thanks to some members of Bromley Repeater Group and very good friends of mine Gary, 2E0ULA & Michael, 2E0MRE for their help with the repeaters over years and also Martin, G8ULV for the website support.

Bromley Repeater Group and the future of GB7OK and GB7LO

You may be wondering why I’ve recently taken the step of replacing the repeater hardware… 

After all, the repeater was working quite well to begin with.

Over the past few months I’ve been thinking about the way that ‘digital’ has impacted amateur radio and in particular how it’s affected the ‘local’ amateur radio communities, qso’s and repeaters.

I have always felt that the whole point of putting a repeater on air was to provide a service for fellow amateurs and by doing so, facilitate the building of a community of radio amateurs, clubs and club members within the footprint area of the repeater.

Our repeaters achieved this and have always had a group of loyal users and supporters but over the years things change, people’s priorities and lives change and so does their geographical location in many cases.
The advent of digital modes has also been a change and now with internet gateways connected to repeaters it’s possible to easily connect to more or less anywhere in the world from your shack, mobile or handie which is great !

But this has had a detrimental impact on the community in my opinion, and I believe it’s largely because of the way many repeater keepers run their repeaters.

So I’ve been talking to people and to some of the local clubs and their members to try and find out what they want from the repeater, asking how they want to use it and what facilities they want from it and the answers are interesting.

Many amateurs who have taken to the digital voice modes now connect using hotspots and reflectors making the reflectors the ‘hub’ of the community rather than the repeaters. Having a reflector as a digital community hub is a great idea because it allows users to connect from anywhere in the world so people who move away from the repeater’s home location do not move away from the repeater’s local community.

HUBNET is an excellent example of how this has affected the repeater network and local repeater communities across the UK.

Don’t get me wrong though, HUBNET is an excellent system and concept which works very well. It has acquired its own community and has many followers but many repeater keepers who’s local users have migrated away from their local repeater to the convenience of a hotspot and reflector have responded by simply connecting their repeater to hubnet as well, simply in order to get some traffic on their now deserted repeater.

These repeaters consequently become simply ‘broadcast boxes’ with little or no RF activity as everyone chats on the ‘hub’ reflector.
Another consequence is that the few people still using RF and a repeater to connect are faced with a complete lack of variety as every repeater they connect to carries the same Hubnet ‘channel’ and traffic.

HUBNET’s success means there is plenty of activity on it but it can be difficult to hold a qso and, as the channel (and any repeater connected to it) is so busy, capturing a local repeater in order to move it to a different reflector can also be difficult or at times impossible, so for someone wishing to use the repeater for a local chat rather than broadcasting around the entire country via a large number of repeaters connected to the reflector, becomes impossible.

The result is often that the user turns off his radio, and as his local repeater along with all the other repeaters in range are constantly busy with Hub traffic, and as the simplex channels are largely deserted… he packs his golf clubs into the boot of his car and heads off to play with his balls instead !

Leaving the simplex channels dead and almost every repeater in the country regurgitating HUBNET.

Hey presto, you have witnessed the death of the local repeater communities, not to mention local club nets in the evenings and local group chats during the day.

————————————

So what is the solution ?

GB7OK and GB7LO are going to be run differently. Our intention is to try to get back to local community based amateur radio with all its variety and values.

The new Yaesu repeater has the best of both worlds.

Yaesu System Fusion is the easiest digital mode to use and access with no radio codeplug to program and simple repeater like operation. The new repeater also has good old FM capability using Yaesu’s AMS (automatic mode select) which detects whether an incoming signal is using Analogue FM or Digital YSF.

The repeater’s default digital hub connection will not be HUBNET or another heavy traffic reflector, it will be one of the Bromley Repeater Group’s own reflectors which were created specifically to provide for our own repeaters and our own community of users in London and the Southeast. This doesn’t mean you won’t be able to access Hubnet or any other reflector using our repeater but we hope it will mean that members of the original GB3OK and GB7OK/GB7LO community who have moved away from the area will be able to reconnect with old friends and colleagues, while at the same time allowing the newer generation of amateurs who favour digital access to participate in the fray.

Meanwhile, there are still a number of Analogue FM users who will also be able to access and use the repeater and join with the community.

We feel that both digital and analogue systems have their place and we believe both systems can exist side by side serving both sets of users.

 

 

 

Another Seasonal Repeater Upgrade

Bromley Repeater Group News

We have purchased a new Yaesu VHF/UHF C4FM Digital/FM Repeater which we installed today for testing purposes. For the moment it will be operating as a stand alone repeater and not connected to the internet.

The Repeater will operate automatically on C4FM (auto mode select) and Analogue FM with a of CTCSS 82. Hz

We intend to run our initial testing of the repeater over the weekend of 11th and 12th of January and would greatly appreciate any signal, audio and coverage reports submitted either via the group WhatsApp channel, email or in the comments below.

Network connectivity will be added as soon as possible to allow for access and testing of the connection to the GB7OK Community Reflector.

Snitch

https://github.com/yodabytz/snitch

Snitch is a Python tool that monitors Fail2Ban logs, detects abusive activity, and notifies netblock administrators via email. It analyzes jail-specific logs for evidence, supports custom jail configurations, logs actions to /var/log/snitch.log, and ensures professional alerts to help address potential server compromises or misuse.

SecuNX – Nginx Security Automation

Yodabytz just added a Web Application Firewall script to his portfolio.

SecuNX is an automated security solution for Nginx servers, designed to enhance your website’s protection by managing IP blocklists and whitelists. It fetches malicious IP addresses from trusted sources, updates your Nginx configuration automatically, and ensures that trusted IPs are never inadvertently blocked. Additionally, SecuNX provides a custom 403 error page to inform blocked users appropriately.

https://github.com/yodabytz/secunx

 

A new script from my favorite github coder

ModSentry by YodabytzMy fave github coder has added another useful script to his portfolio.

ModSentry is a real-time log monitoring tool for analyzing security events from ModSecurity logs. It provides an intuitive terminal interface to track alerts and highlight critical incidents. IP addresses can be blocked or unblocked using iptables directly from the interface.

https://github.com/yodabytz/modsentry

 

Home Network Security #2

When you’re hosting your website and running your shack using your home network it’s important to keep an eye on the visitor traffic arriving at your site.

There’s a lot of useful info to be gathered by reading your server log files whether they’re your webserver logs or the connection log for your hotspot, mmdvm dashboard or repeater logs.

To begin with there’s the useful meta data such as browser and O/S info which will give you an insight into the software your visitors are using which can help with tailoring your website to work with different browsers and software or with identifying issues and problems.

But these posts are meant to give you a few ideas about maintaining your network integrity and security so first of all, you need to be reading the logs. Log files are usually just plain text files so all you need to read them is a simple text editor. You’ll also need to know where they are stored on your system, most MMDVM’s and many Webservers use a version of the Linux operating system and Linux uses a standardised file structure so for example, your MMDVM log files will probably be stored in /var/log/apache2/ if you’re using Pi-Star or WPSD on your hotspot and the file name will be access.log if you’re using a different system just google to find the location.

Once you have your log file open you will see a line by line breakdown of each request made by a visitor. First is the visitor’s IP address followed by the date and time of the request, this is followed by the type of request “GET” or “POST” for example and then comes the interesting bit which contains the filepath and requested file, the protocol and the code returned. This is followed by the user’s browser info and operating system versions as in this example of a request for the robots.txt file from the Apple search bot.

[27/Sep/2024:17:45:11 +0000] “GET /robots.txt HTTP/1.1” 301 162 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +http://www.apple.com/go/applebot)”

So far so good, but let’s get to the ‘security’ bit and how log files can help identify threats to your system and attempts to exploit weaknesses.

The majority of threats to your system will generally be from malicious bots and not from some guy in a hoodie who is tapping in commands on a keyboard at the dead of night so let’s take a look at bot ‘hits’. Bot hits are easy to spot because they usually come as a block or flood of requests to the server.

Like that. The bot in this case is trying to get a positive ‘hit’ from its list of vulnerable or exploitable resources using curl, it will compile and save a list of positive hits, recording the IP address of the server, if it doesn’t get a positive ‘hit’ it will move on and try the next IP on its list.

So your log file is now useful in two ways, firstly it can now provide you with a list of ‘exploitables’ to avoid using on your system/server and secondly it provides you with an attacker’s IP address which you can block using your system’s firewall.

(Expect more about firewalls later)

Meanwhile, one last tip for viewing log files. You can view your log file in real-time using a Terminal window, just open a terminal on your MMDVM or server and type:-

sudo tail -f /var/log/apache2/access.log

Have fun 🙂

Home Network Security #1

You can’t be too careful when you’re running your shack from your home network.

So here you go, my Network Security Tip #1 for anyone with an Internet connection in the shack.

Don’t get hacked !

Here’s what to do if you find you have been ‘haxored’.

Change all your device and system passwords making sure that they’re all different and make them much bigger/longer with a mixture of symbols randomly arranged, avoid words or names which can be found in a dictionary… use two factor auth when ever you can and read your server logs on a regular basis,

I read mine pretty much everyday, try /var/log/apache2/ if you’re not sure where your webserver log is…

Webserver logs can be a mine of information but I’ll make that part of Tip #2