Coverage Maps rendering status

In the last month, DAPNET has grown all over the planet. When we designed the network, we didn't really think that this would happen one day. So besides of beeing quite happy about that fact, it also revealed the problem of generating DAPNET transmitter coverage maps for sites all over the world. The map data is predicted using state of the atr science published in this paper: R. Wilke, H. Munz, D. Heberling: "Radio Coverage Prediction for a Wireless IP-based Network in Central Europe". Besides of the transmitter meta data like antenne height and power, the algorithm needs a Digital Elevation Model (DEM). We use the data from https://earthdata.nasa.gov/ and in particular the ASTER2 mission DEM data. I have downloaded already the area of Europe, but as there are now transmitters on other contients, the worldwide coverange iof DEM data is needed. The download and pre-processing of the data has already been starte. but it will take some times be be finished (about 68 GB in compressed version). Afterwards, the prediction process will be executed again to calculate the missing maps for transmitters outside europe.

2018/08/30 09:45 · dh3wr

Connection problems solved

Starting on about 21.08.2018, there have been some serious issues with the DAPNET Server connection regarding the server address dapnet.afu.rwth-aachen.de / Port 43434. The reason was a self induced DDoS scenario caused by the MMDMV DAPNETGateway software. The version from July 2018 had no delay between failing connection attemps. So as DAPNET has now spread over the world, there have been a lot DAPNETGateway installations that have not been configured properly by their operators. This resulted in connection attempts every millisecond from several instances breaking the server with to many on/off connections. At maximum, the server had to deal with 1000s of connections per second. An update of DAPNETGateway was relased with date 20180823. Pi* Systems have got that update already.

If you run an instance of DAPNETGateway without this framework, please update the software immediately.

In order to get the services up and running again, firewall filtering has been introduced based on the Software version the transmitters are sending during the connect procedure. If it contains MMDMV v201807, your IP will be blocked for port 43434 for some time. You can check on https://hampager.de/blocked-ips, if you are on the list and even unblock yourself with a click.

We also see every second connection attemps from clients with either wrong credentials or transmitter callsigns that are not registered. Right now, these are just filling our logs. If the number of such careless installations keeps growing, we may have to add the corresponding IPs also to the block list.

2018/08/25 20:43 · dh3wr

DAPNET goes MMDVM

Durch glückliche Umstände konnte Jonathan Naylor G4KLX (Entwickler der MMDVM Soft- und Firmware) auf der HamRadio 2018 in Friedrichshafen angetroffen werden. Er interessierte sich besonders für das Thema DAPNET. Unter anderem wurde mit Mitgliedern des DAPNET Teams die Idee entwickelt, DAPNET-Aussendungen via MMDVM zu tätigen.

Seit seiner Rückkehr von der HamRadio ist Jonathan damit beschäftigt, das POCSAG Protokoll in die MMDVM Software zu intregieren. Dazu wurde die Host-Software sowie auch die MMDVM Firmware angepasst. Erste Testaussendungen dekodierte Tony, G0WFV mit einem SDR bzw. multimon-ng, um die Entwicklung zu unterstützen.

Heute erfolgte dann der Feldversuch: Florian, DF2ET testete die MMDVM Software auf einem F7M Board von Toufik, F0DEI. Die erste Aussendung konnte erfolgreich auf einem AlphaPoc 602R dekodiert werden.

Die Software befindet sich noch im Beta-Stadium und es müssen sicher noch einige Bugs beseitigt werden bevor der POCSAG Code Teil des Releases wird.

Die Quellen für Host und Firmware finden sich auf github:

2018/06/13 23:58 · df2et

Umfrage zur neuen Netz-Struktur des DAPNETs

Nach dem ganzen Engagement in Sachen MMDVM müssen wir auch im Core mal weiterkommen, was das Clustering angeht. Die aktuelle JGroups-Variante scheint ja für das wackelige hamnet nicht brauchbar zu sein. Es gibt nun 2 Möglichkeiten alternative Ansätze zu verfolgen:

1) Vollständig dezentraler Ansatz: Keine Master-Server, jeder Knoten kann Master sein. (Komplexere Umsetzung, Stablität weiterhin bröckelig, solange das Hamnet nicht zuverlässig ein paar kByte durch Europa transportieren kann)

2) 3 Redundante Server in den 3 HAMCLOUD Standorten, maximal kurze Anbindung von Hamnet-only Knoten (Einfachere Umsetzung, da Top-Down Konzept (Im Zweifel haben die Master-Server bei Datenbank-Konflikten recht)

Dazu folgende Umfrage bis zum 10.6.2018: https://onlinevoten.de/poll/91651-vollstaendige-dezentralisierung-oder-top-down-konzept-im-dapnet/

2018/06/08 13:37 · dh3wr