44net

44net@mailman.ampr.org

1 participants
3200 discussions

Re: [44net] Make Error
by Rob Janssen 17 Apr '17

17 Apr '17

> I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS: IPPORT_ROUTESERVER should be defined in <netinet/in.h> When it isn't, you can work around that by inserting this line near the top of the ampr-ripd.c file near the other #define lines: #define IPPORT_ROUTESERVER 520 Rob

1 0

fbi.gov at i0ojj.ampr.org
by Gustavo Ponza 16 Apr '17

16 Apr '17

Hi all, Just to inform all of you about the special visit at i0ojj.ampr.org/ir0rm-7.ampr.org by using the following references: fbi.gov. 0 IN TXT Dgoogle-site-verification=L8cauHJF4MANoTCkMbrLkAVfHBta28ctva9n1IDekToQ fbi.gov. 0 IN TXT Dgoogle-site-verification=6UEk-jfg1xPNjz_rQGcRFJOBGxMy1aARDZUTXgSNAqw fbi.gov. 0 IN TXT XublrZj1CzpSEiwtiRFKDAyiek8hRqkqaTTApxvhwai14i8JqVBOauW4cA06i39H5Lhl3HnALCM/xfTxIPEXEpA== fbi.gov. 0 IN TXT 625558384-8740534 -- 73 and ciao, gus i0ojj A proud member of linux team Non multa, sed multum

1 0

OpenWRT Upgrade - Linux Bug
by lleachii＠aol.com 16 Apr '17

16 Apr '17

All, I did an upgrade of my OpenWRT device to LEDE 17.01.0. At this time, everything is operation as before; except that I cannot execute the ampr-ripd from the CLI or the scripts that worked in the previous versions. I'm suspecting it may be missing dependencies; but while I troubleshoot, I am only accessible from the Global Internet. If anyone else is interested in upgrading and troubleshooting, I would ask that you make a copy of a list of all your installed packages prior to upgrading. In addition, please make an archive of your config before and after your upgrade. 73 and good weekend, - Lynwood KB3VWG

3 3

Re: [44net] portal down
by Rob Janssen 15 Apr '17

15 Apr '17

> Just to keep everyone in the loop: there have been four DDOS attacks on the portal recently, two against just port 443 and late last night (UK time) two simultaneous attacks against 443 and 25. > I have no idea why anyone is targeting the portal, nor who is behind it - as per your standard DDOS the attacks they mainly came from compromised PCs on the end of home DSL lines. We had a DDoS attack that affected our gateway, but it targeted the "Brandmeister" servers for interlinking digital voice repeaters, that were hosted on our network. (some on the same ESXi server as the gateway and some on another location linked by a radio link) This took down our connectivity as we got >200 Gbit/s of traffic and the gateway only as a 1 Gbit/s connection. The traffic in this case was "DNS reflection", i.e. DNS requests were sent by compromised PCs using a spoofed source address on AMPRnet, and the DNS servers were sending their replies to our gateway. Due to the high packet loss and the large replies these were mainly UDP fragments that would not re-assemble to complete datagrams. Of course it is bad that there still are so many ISPs that do not implement BCP38. But what can we do? However, more interesting is the cause of this attack: the maintainers of the Brandmeister system have a disagreement with the operators of the French gateway in that system and decided to disconnect it. The DDoS was done as a retaliation against that, probably by one or more French amateurs, not necessarily the gateway operators. (the disconnection of that gateway of course affected the repeater users in France, not only the operators) Like in your case, there were several waves of attacks. In the end, the affected addresses were nullrouted and the servers moved elsewhere. It might be that these same people are still looking for things to attack, and maybe they researched a bit how .ampr.org works and decided to attack the portal? (not effective against Brandmeister as our network is BGP routed) It is sad that people act this way, and the network operators do so little to prevent it. Rob

1 0

Re: [44net] portal down
by Rob Janssen 15 Apr '17

15 Apr '17

> Instead of this debate -- why not spec what the software does and start an > open source project to replicate its functionality. Because this is a one-instance project. It does not bring much to opensource it and have 5 different people working on it in 5 directions, because ultimately we need one instance that governs the AMPRnet. Even when we want to replicate it for redundancy, those copies need to run the same code or at least would have to have exactly the same functionality. Having said that, it appears to be a pretty mundane LAMP project and it has taken way more time to discuss about the developments it needs than it would have taken to actually do those developments. Maybe writing the specs and starting from scratch is not such a bad idea, especially when done by someone who can actually spend some time on it. I would have favoured integrating it with another AMPRnet application, HamnetDB, but unfortunately it appears its developer has just as little spare time, so that probably would be a tough project as well. Rob

1 0

Mikrotik ROS script update
by Marius Petrescu 15 Apr '17

15 Apr '17

Hello, I made some updates to the MT ROS script: - The script now maintains an interface list named 'ampr-interfaces' with all ampr tunnel interfaces. The list is persistent, and will be created on first script run. Afterwards it will be maintained by each interface add or remove. Useful for firewall rules. - Corrected an error when tunnel endpoint host routes where not deleted on interface removal. - Added step by step instructions using winbox GUI (inside the zip file). http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.rsc http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.zip 73s de Marius, YO2LOJ

1 0

Re: [44net] portal down
by Brian Kantor 15 Apr '17

15 Apr '17

Appears I was wrong about having to wait until tomorrow; the portal is back up. - Brian

1 0

UCSD gateway outage
by Brian Kantor 14 Apr '17

14 Apr '17

During the night, amprgw fetched a copy of the encap file from the portal which was truncated (it had 259 entries instead of over 600) and one of the entries that was in the copy fetched had no gateway address. Viz: route addprivate 44.131.168.128/29 encap This caused the ipip daemon to segfault and so there was no routing between Internet and tunnel subnets for an hour. The rip sender was similarly affected. Later fetches of the encap file obtained ones that appear to be intact and all routing is again operational. I've modified the code in the daemons to be more robust in the face of a bad encap fetch, and taken steps to ensure that future fetches are checked better. - Brian

8 9

Linux/Android kernel security bug
by Brian Kantor 14 Apr '17

14 Apr '17

The Register reports a Linux/Android kernel flaw that could expose you to remote privileged execution of arbitrary code: http://www.theregister.co.uk/2017/04/14/new_critical_linux_kernel_flaw/ As a lot of the machines and routers on the Amprnet are based on Linux, this may be incentive for you to update to the latest kernel. - Brian

1 0

Re: [44net] UCSD gateway outage
by Rob Janssen 14 Apr '17

14 Apr '17

> During the night, amprgw fetched a copy of the encap file from the portal > which was truncated (it had 259 entries instead of over 600) and one of > the entries that was in the copy fetched had no gateway address. Viz: > route addprivate 44.131.168.128/29 encap > This caused the ipip daemon to segfault and so there was no routing > between Internet and tunnel subnets for an hour. For this particular issue it would help when the encap file had a trailer that the script that fetches it could check for before loading it. Something like: # EOF Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net