- 44net - mailman.ardc.net

Re: [44net] RIPv4 security
by Brian Kantor 23 Sep '16

23 Sep '16

Gentlemen, if we cannot discuss a matter calmly and rationally, we should not discuss it at all. What we are after here is light, not heat. Incendiary comments are not welcome on this mailing list. Control yourselves. - Brian

4 3

Portal (was: RIPv4 security)
by Rob Janssen 23 Sep '16

23 Sep '16

It would still be an option to merge the portal and hamnetdb... Hamnetdb is much more capable when managing subnets, and it is open. There is an issue with scalability (it always shows you all the data it has when first opening a page, before you have applied a search filter, which really loads older computers), so there may be surprises when all of the world's data is loaded into it. The "gateways" functionality is not yet there, so it would have to be implemented. But issues like the one that started this discussion are easier to resolve in hamnetdb because every object has a list of maintainers, which the owner or a sufficiently privileged person can modify. So you can easily hand over control over your subnet (e.g. to include it in a gateway) to someone else without sysop involvement. Rob

2 1

RIPv4 security
by Rob Janssen 23 Sep '16

23 Sep '16

> That's fine for YOUR users because you keep a separate database of what > is allocated and what is not in your country's subnet, but I and many of > the other coordinators use the subnet allocations in the portal as the > authority for what is allocated and what is available. It is essential > that all subnets be registered in the portal in order for me to do my job. For me, the portal is not usable as the only registry of information, because it does not do DNS and DNS is essential for the functioning of the network. (not only because you want to name your system, but also because being in DNS is used as a filter to allow traffic through the gateway) So I need to keep two different registries anyway, and it does not matter how much of the information is in the portal and how much is in my own database. Furthermore, for allocating subnets and addresses I need an easily browsable view on the existing allocations including comments like regional names, to be able to decide where to put the new entry. To me, a simple "hosts" file edited in vi gives more overview than most point and click interfaces, including even that of the hamnetdb (which is way better than the portal in this regard). This solution also reduces the effort when making bulk changes like moving an entire subnet, doing cleanups like I did some time ago, or even transfer of the existing allocations into the portal. Sure they would be possible with a tool like this but it would either need a lot more features (and thus coding) or it would have to offer direct access to the database for queries. Rob

2 1

Re: [44net] RIPv4 security
by Bryan Fields 23 Sep '16

23 Sep '16

On 9/23/16 2:59 AM, G1FEF wrote: > I get very fed up with folk like yourself making assumptions. There is a simple way to shut me up. > The reasons > why the code is not yet open has nothing to do with me or my ego, there are > other factors which you are not aware of that keep it like it is for now at > least. State them. > I am an advocate of open source, I have, and do, contribute to open > source. So please stop being so rude and obnoxious to me when a) you don’t > know me and b) you do not know the full circumstance. I see the evidence as presented. What is presented is you have some "mystical" reason you refuse to be open with your code. This is unacceptable. Can you logically argue it is not? > Just take the time to > look at life from someone else’s perspective for a change, how would you > feel if people like yourselves were being so rude to you for trying to help > out without being paid? Having 44net over a barrel with code which we cannot audit or extend is not helping; It's holding us back. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

1 0

Re: [44net] RIPv4 security
by Rob Janssen 23 Sep '16

23 Sep '16

>>/Furthermore, portal.ampr.org allows anybody with valid email address to />>/route any 44/8 subnet through any IP address, not only subnets assigned to />>/account in use. There're no restrictions to do so and it will stay there />>/and get broadcasted until somebody notice. />This is not true. By registering a gateway, you can use your assigned >subnet through your registered gateway. But if that subnet is already >assigned to a gateway, you can not assign it to your own gateway without >deassigning it from the old gateway first.So this is a non-issue unless >there are unassigned subnets floating around in the portal for people to >grab. But these are mostly the result of misconfiguration and lack of >knowledge, not the work of an attacker. And it will disrupt only that >specific subnet. Well, this issue is really there! Recently I found that two users from the Netherlands had setup completely bogus gateway entries, both stealing subnets belonging to others and routing them to the 44.137.x.x address I have them as "the gateway external address". Those were probably not malicious, they just did not understand the portal and fiddled around a bit, and left it as it is once they did not understand anymore what is happening. I think the portal should not allow to route other people's subnets through your own gateway without some consent from the subnet's owner, I think for some time it was impossible to setup such entries, and people complained that they needed this to route for others, and the check was removed again. >So here we may need some improvement tot to allow e.g. assignements of >national or regional subnets assigned to administrators to regular >users, which are the most likely to float since they are not bound to >any gateway. Administering national and regional subnets is a real pain, as it is impossible to manipulate the subnet structure without deleting it first, and ownership of an entry cannot be transferred. We all know how hard it is to get anything improved in the portal. For now, I advise users to not register their subnets unless they want to do IPIP tunneling. W.r.t. the processing of RIP and IPIP traffic, you can do a lot with a properly designed firewall. On my systems I accept only IPIP traffic from gateways that I received before via RIP, and I accept RIP only from 44.0.0.1 on the IPIP interface. Maybe it would be possible to also check if the traffic came from UCSD, I'll have to see how to check that in iptables. (probably can be done with marking packets when they come in from UCSD, then check the mark when they arrive on tunl0) Rob

5 5

RIPv4 security
by Jakub Kramarz 22 Sep '16

22 Sep '16

I hope that I'm not breaking thread continuity, but I've subscribed requesting daily batches and don't know how to change it. > > As it is UDP based and relies on source of UDP packets, which is easy to > > spoof, current routing infrastructure is vulnerable to unrestricted > > injecting of 44/8 routes to it's gateways - anybody can send forged RIP > > updates to them. > Here I don't think the situation is that critical. The RIP updates are > sent via tunnel, and should be accepted only from the ampr-gw tunnel > interface. The attacker needs actually to block out original IPIP > traffic and spoof the IPIP tunnel to get fake RIP data into the network. > This is a little harder than just sending a bunch of UDP packets to a host. It's just as hard as decapsulating these packages in ampr-ripd. There's no need to disturb communication, as IPIP tunnel is not being established - it's just another IP header one can easily spoof, there's no authenticity control. This kind of DoS attack on AMPRnet won't be very interesting, but may be quite annoying to gateway operators. On the other side, it may result in sending unsolicited IPIP traffic to random hosts. Firewalling (by restricting pool of destination hosts for protocol 4) would do the job of limiting such activity, but on the other hand would be one step back, as list of gateways would need maintenance by hand. > I really don't see the point of doing that. Crackers want benefits from > their work: e-mail collecting, snmp access, spamming, not the glory of > sending data to a compromised system to which they are the only ones > having access. And creating a DOS attack like this on an APMPR host is > nothing interesting. So I do. Can't find any other use than a bit creepy SMURF-like DDoS. > So this is a non-issue unless > there are unassigned subnets floating around in the portal for people to > grab. There's a lot of such subnets. I just got banned for routing one of them through 192.168.0.1.

1 0

RIPv4 security
by Jakub Kramarz 22 Sep '16

22 Sep '16

Password authentication mechanism in RIPv2 is meant to protect against accidental misconfigurations and is the only way of configuring ampr-ripd routing. As it is UDP based and relies on source of UDP packets, which is easy to spoof, current routing infrastructure is vulnerable to unrestricted injecting of 44/8 routes to it's gateways - anybody can send forged RIP updates to them. Furthermore, portal.ampr.org allows anybody with valid email address to route any 44/8 subnet through any IP address, not only subnets assigned to account in use. There're no restrictions to do so and it will stay there and get broadcasted until somebody notice. So, there're at last two ways of disrupting whole AMPRnet network topology and both will make nodes send traffic to any hosts. Is it really the way it should be? If changing RIP to some more secure protocol is not an option, maybe at last implementing RFC4822 would do the job?

2 1

Re: [44net] ampr-ripd update 1.14
by Rob Janssen 22 Sep '16

22 Sep '16

> Subject: > Re: [44net] ampr-ripd update 1.14 > From: > Marius Petrescu <marius(a)yo2loj.ro> > Date: > 09/21/2016 06:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu>, "Ana C. Custura" <ana(a)netstat.org.uk> > > > On my server running Debian 8 with kernel 3.16.0-4-amd64 it works > without the '-r' flag. > > I actually wanted to remove that flag, but then it will break the > scripts using it. > > I will make a new release that ignores that flag but still accepts it as > parameter, but runs always in raw mode. > > I think this would be the proper approach. Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode. Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference... Rob

3 4

ampr-ripd 1.15
by Marius Petrescu 21 Sep '16

21 Sep '16

Hello, Another update... To keep everything as simple as possible and since this seem to work on all systems, only raw socket mode is used (parameter -r is ignored, so you don't have to change anything in your startup scripts). Please note that no functionality has actually changed compared to 1.13, so if you are happy with your current setup, no change is needed. These changes are basically aimed to newcomers and will bring nothing new to existing users. Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.15.tgz 44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.15.tgz or from GitHub: git clone https://github.com/yo2loj/ampr-ripd.git Have fun, Marius, YO2LOJ

1 0

Re: [44net] ampr-ripd update 1.14
by Rob Janssen 21 Sep '16

21 Sep '16

I think it is a good idea! The password has often confused newcomers and made it harder to debug an intial setup. How about the -r flag? Some time ago it became necessary for me to use it, apparently due to changes in the kernel around multicasting. Is this still the current situation on the latest Debian release? Or can ampr-ripd again work without -r? Depending on this, it may be good to make some change in that default too. Rob

2 1

Greetings from Poland!
by Jakub Kramarz 19 Sep '16

19 Sep '16

Dear 44net group subscribers, My name is Jakub Kramarz (SP0NGE) and I'm writting on behalf of Hackerspace Kraków foundation (callsign SP9HACK) in Poland and I'd like to say hello to this community :-) We're a group of Linux and networking professionals, web and embedded developers, security researchers and finally radioamatours who has recently started our small, personal war to bring HAM radio back to young people in our country. In recent time, we've successfully: - in cooperation with SP9KGP club, we held 3 comprehensive HAM radio courses in Kraków, converting 40 enthusiasts to fully-fledged radio operators (~ the number of Polish Amateur Radio Union's new members in whole country), - held an important role in securing radio communication during World Youth Day 2016, - operated multiple occasional stations (supporting Great Orchestra of Christmas Charity, promoting Woodstock Festival Poland, ...), - supported Radioreaktywacja (Radio Reactivation) initiative, who "infects" the youngest with our hobby, by sharing hardware and knowledge, - and, finally, contributed to numerous open source and open hardware radio-related projects, eg. mcHF QRP firmware I hope we'll be able also take a part in AMPRNet project and contribute to digital communications over radio. Serdecznie pozdrawiam / Best regards, Jakub Kramarz http://about.me/jkramarz Sent from Makita TD090DWE impact driver

1 0

Posting from HamWAN Tampa @ DCC
by Bryan Fields 17 Sep '16

17 Sep '16

I'm on the 15th floor, 17 Miles from Tampa in St Petersburg, getting 20mbit/s with some refraction through glass in the club here. 73's -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

1 0

rip down ?
by Maiko Langelaar 17 Sep '16

17 Sep '16

Did we loose the rip broadcast ? Maiko

5 5

Re: [44net] getting rip data fron the non ampr address of ucsd gw?
by Rob Janssen 09 Sep '16

09 Sep '16

> Please be aware the protocol is RIP44, **NOT** RIPv2. You must install > and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d). He uses a solution devised by Marius to work around that problem on a MikroTik router. Rob

1 0

Re: [44net] getting rip data fron the non ampr address of ucsd gw?
by lleachii＠aol.com 08 Sep '16

08 Sep '16

Ronen, Please be aware the protocol is RIP44, **NOT** RIPv2. You must install and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d). See: http://wiki.ampr.org/wiki/RIP 73, -Lynwood KB3VWG

1 0

cant get rip in MicroTik
by R P 08 Sep '16

08 Sep '16

I tried to follows the instructions that written here http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt www.yo2loj.ro<http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt> www.yo2loj.ro Setup example - please adapt ===== (ASSUMPTIONS: public ip is 89.122.215.236, router's ampr ip 44.182.21.254, WAN interface is PPPoE-In): You ... I have a working tunnel on the router called UCSD (the tunnel interface have no IP adress) my router is in bridge mode because it connect to cable modem before of it and sit on a DMZ address of the cable modem It uses ether1-gateway interface as the 44 net address (4.138.1.1) it uses ether2-master-local as the ip connected to the Cable modem (it uses 192.168.1.180 and default gateway to the cable modem ip which is 192.168.1.1) I have no firewall working and i get no RIP routes I have changed the tunnel interface name in the instructions to meet my interface name .. on the VRF if i chose the tunnel interface the routes (or maybe the tunnel) stop and i cant access anymore the 44 net hosts from the outside world and i see no rip info when i change the interface to the ether1-gateways (the one that have the 44 net address) the routes are ok the hosts are accessible from the outside world but i still not seeing any rip info what is wrong ? how can I debug it ? if needed i can provide password to the router since it is accessible from the outside world Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

2 2

Re: [44net] getting rip data fron the non ampr address of ucsd gw?
by Rob Janssen 08 Sep '16

08 Sep '16

> Let's not forget... > If you are unable to get RIP broadcasts for any reason, you can get the > encap data from the portal as a json file via its API. Sure, but please note that this does not solve the underlying problem of not being able to receive unsolicited IPIP traffic I mentioned. When that is the reason (rather than inability to follow installation and debugging instructions), the result will be a partially-working gateway. That gateway will be usable to contact other stations on the AMPRnet, but those other stations will not be able to contact your systems. Outgoing connects are OK, incoming connects are not. While some people my consider that a usable system, it is not a desirable situation. The AMPRnet is more peer-to-peer than the internet in general, in that anyone is expected to be both a participant and a consumer, not only a consumer as is usual on the internet. Rob

1 0

Re: [44net] getting rip data fron the non ampr address of ucsd gw?
by Rob Janssen 08 Sep '16

08 Sep '16

> So the password is sent from UCSD and compered with the password i put locally and if they identical then the data is processed ? > one more thing i understand the data is sent from UCSD ... how often is it sent ? > I dont see any advertisement here do i need to define something in the portal ? > normal tunneling work well Of course you need to have a gateway entry in the Portal. I.e. you need to have a subnet, and a gateway with external address and that subnet defined. The RIP packets are sent every 5 minutes. When you can manually make a tunnel and ping the remote, but you do not receive anything including RIP broadcasts, the cause often is a stateful firewall inside your internet modem/router. It accepts replies to outgoing packets, but it does not accept unsolicited incoming packets. This is designed as a security feature. To use IPIP tunneling, your modem/router must be able to unconditionally forward protocol-4 traffic to your gateway system. In advanced modem/routers you can forward a protocol, but usually it is only possible to forward TCP and UDP ports. That is something different. It is useless to forward port 4, you have to forward protocol 4. When that cannot be done you can often set a "DMZ host" that is said to get all incoming traffic, however there are examples of modem/routers where this does not work correctly. The DMZ host receives all TCP and UDP traffic but not all other traffic (including IPIP). It does receive (like any host) replies on its own IPIP traffic, but not the unsolicited incoming traffic. When you have such a modem/router, and when it cannot be replaced (e.g. because your provider requires you to use this modem/router), you cannot use IPIP tunnels. Rob

3 2

getting rip data fron the non ampr address of ucsd gw?
by R P 08 Sep '16

08 Sep '16

Hi there can i get the ripv2 data from ucsd gateway by connecting to its non ampr address ? what about from connecting it from my internet (non ampr) adress as well ? any info welcome Thanks forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

3 3

Re: [44net] ip44 argentina
by Rob Janssen 07 Sep '16

07 Sep '16

> Subject: > [44net] ip44 argentina > From: > Eduardo Castillo <lu9dce(a)gmail.com> > Date: > 09/07/2016 06:10 PM > > To: > 44net-owner(a)hamradio.ucsd.edu > > > Hello !! > > we are trying to set up a debian linux pc > > and we fail to find settings > > ip we have is 44.153.32.97 > > PC IP is 192.168.0.50 > > and dynamic IP Internet > lu9dce.dynu.com > > how to make a script > to a ip44 You can find directions on the WiKi: http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Linux

1 0

ip44 argentina
by Eduardo Castillo 07 Sep '16

07 Sep '16

Hello !! we are trying to set up a debian linux pc and we fail to find settings ip we have is 44.153.32.97 PC IP is 192.168.0.50 and dynamic IP Internet lu9dce.dynu.com how to make a script to a ip44 73 --------- Hola !! estamos tratando de configurar un pc con linux debian y no logramos dar con la configuracion la ip que tenemos es 44.153.32.97 la ip del pc es 192.168.0.50 y la ip de internet dinamica a lu9dce.dynu.com como hacer un script para poder unas ip44 73 -- ====================================================================== Yo, el solitario, soy siempre el más rico y el más envidiado porque os he poseído y vosotros me poseéis aún. Friedrich Nietzsche, "Así habló Zaratustra". ====================================================================== __ __ __ __ | / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz |__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300 == power by linux === NODO LU9DCE.DYNU.COM PORT 3694 *** https://www.facebook.com/groups/newpacketradio/ /EX

1 0

Routing
by Paul Middlehurst 06 Sep '16

06 Sep '16

I have configured a Cisco router, duel Ethernet interfaces on on of my static Internet addresses. The IPIP tunnel comes up and with wireshark I can see traffic in both directions to 169.228.66.251 pinging devices in the wider 44. network I never see anything being returned. Does the gateway router automatically have the reciprocal return tunnel / routes added (as per the Encap file) or is this something that needs requesting? Is there a good 44.131.x.x address to test against? 73 Paul - G1DVA

3 2

Re: [44net] DGN2200 ADSL router and IPIP
by lleachii＠aol.com 26 Aug '16

26 Aug '16

Ronen, Most consumer routers only pass TCP and UDP without customized firmware. If you have the Version 1 device, it is compatible with OpenWRT, see: https://wiki.openwrt.org/toh/netgear/dgn2200 I suggest using devices known to pass IPENCAP traffic. 73, Lynwood KB3VWG

3 3

using first and last IP of AMPR subnet for networking
by R P 24 Aug '16

24 Aug '16

hi there One of our gateway got 8 IP ADDRESSES 44.138.0.8/39 Can the first address 44.238.0.8 be used ? or it reserved for networking only ? and i have to choose ip address only in the range of the 9-14 ? if the answer is that it can not be used how the main router at UCSD treat for ping attempts coming for 44.138.0.8 ? does it pass it ? or ignore it ? all is assured that the IP is defined at the AMPR DNS... What about the tunnel itself doesit have any connection to what ip the gateway have ? or it exist anyway and has no meaning for the ip of the gateway ? (because the tunnel defined with only Commercial IP one is local and other is the AMPRGW commercial ip) Its the first time i play with so small network and its not clear to me how its done at the AMPR system I know that on ampr /24 network we didnt use the first and last .. dont know if it was necessary or not but that was the fact Thank for any clarification Regards Ronen-4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

5 5

DGN2200 ADSL router and IPIP
by R P 24 Aug '16

24 Aug '16

Hi there Does anyone know if netgear DGN220 router may pass IPIP to its DMZ ? the router have a fire wall that ca not turned off and one rule in it that can not be deleted as follows any any drop always 10.0.0.20 never log i have placed before it rule as follows any any always pass 10.0.0.20 always log i suspect it know only TCP and UDP and not recognize IPIP on the log there is no sign of AMPRGW IP does anyone have experience with it ? Thanks for any help Regards Ronen - 4Z4ZQ http://www.ronen.org

1 0

ipip tunnel problem for new gateway
by Rob Janssen 24 Aug '16

24 Aug '16

> sorry this is the correct config I think we have explained you many times that this is NOT a correct config. People have helped you with setting up working alternatives, someone has even gone all the way to write software for a commercial router to work as an AMPRnet tunnel router. All that effort seems to have gone to waste. You are still deploying those Cisco routers with only a default route. It's a shame. Rob

2 1

Re: [44net] ipip tunnel problem for new gateway
by R P 24 Aug '16

24 Aug '16

________________________________ Its cisco i tried to send print screen of th show interface tunnel0 but the message didnt go with it ... config is as follows the cisco sit on the DMZ of the DSL router the relevant part of the config is as follows this router was working t my home and only the fellow changes his IP to meet his network the router can ping the 169.228.66.251 interface Tunnel0 ip unnumbered Ethernet0 tunnel source Ethernet0 tunnel destination 169.228.66.251 tunnel mode ipip ! interface Ethernet0 ip address 44.138.1.1 255.255.255.0 secondary ip address 44.138.0.8 255.255.255.0 secondary ip address 10.0.0.20 255.255.255.0 secondary ip address 192.168.2.140 255.255.255.0 ip route-cache flow ip tcp adjust-mss 1360 hold-queue 100 out ! ! ip classless ip route 0.0.0.0 0.0.0.0 Tunnel0 169.228.66.251 ip route 8.8.8.8 255.255.255.255 Ethernet0 10.0.0.138 ip route 169.228.66.251 255.255.255.255 Ethernet0 10.0.0.138 ! ________________________________ From: 44Net <44net-bounces+ronenp=hotmail.com(a)hamradio.ucsd.edu> on behalf of Todor Kandev <todor(a)kandev.com> Sent: Tuesday, August 23, 2016 11:28 PM To: AMPRNet working group Subject: Re: [44net] ipip tunnel problem for new gateway (Please trim inclusions from previous messages) _______________________________________________ Having issues with my crystal ball this morning... :D What is your friend using (openwrt, mikrotik, cisco, linux, washing machine, toaster...?) and how it's configured? 73, LZ1ETE On Wed, Aug 24, 2016 at 9:23 AM, R P <ronenp(a)hotmail.com> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > > > > ________________________________ > > > ________________________________ > > > Hi there > > im helping a local ham to set up a gateway and i get strange behave > > the amprgw is accessible from his router the ipip table at the portal > POINTfor the correct ip > > the router accessible from the outside world > > the tunnell interface according to the cisco is up but it look like that > no data flow to the income > > how can i track where the problem is ? > > any help is appreciated > > thanks forward > > Ronen - 4Z4ZQ > > http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com > > Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> > www.ronen.org<http://www.ronen.org> > ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com > > > >

1 1

ipip tunnel problem for new gateway
by R P 24 Aug '16

24 Aug '16

________________________________ ________________________________ Hi there im helping a local ham to set up a gateway and i get strange behave the amprgw is accessible from his router the ipip table at the portal POINTfor the correct ip the router accessible from the outside world the tunnell interface according to the cisco is up but it look like that no data flow to the income how can i track where the problem is ? any help is appreciated thanks forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

2 1

missing packets in to AMPRGW ?
by R P 23 Aug '16

23 Aug '16

Hi can anyone explain why i get every second ping missing packets from AMPRGW ? it happen not only from my PC also from other places ... Regards Ronen-4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com C:\Documents and Settings\customer>ping 169.228.66.251 Pinging 169.228.66.251 with 32 bytes of data: Request timed out. Reply from 169.228.66.251: bytes=32 time=336ms TTL=40 Request timed out. Reply from 169.228.66.251: bytes=32 time=286ms TTL=40 Ping statistics for 169.228.66.251: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 286ms, Maximum = 336ms, Average = 311ms C:\Documents and Settings\customer>

4 7

Use of 44.128.0.0/16
by DaKnOb 22 Aug '16

22 Aug '16

Hello, as far as I know, 44.128.0.0/16 is reserved for testing and experimentation and should be treated much like an RFC1918 subnet. That means it will not be routable to anyone (although it is advertised on BGP). So I have a few questions about its use: 1. Can an AMPRNet member use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? Note that I am not talking about routing these addresses, just use them in a non-connected place. 2. Can a non-ham use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? 3. Can a company use 44.128.0.0/16 for their intranet, instead of, let’s say, 10.0.0.0/8? Note than in all three cases, nobody is connected to 44net gateways and just use the network like any other private address. I am aware that there’s no technical limitation in doing this and there are hardly any benefits from doing this, however I am asking for informational purposes. Thanks!

5 4

Re: [44net] Use of 44.128.0.0/16
by Rob Janssen 21 Aug '16

21 Aug '16

Bogon filter in use on our gateway (all packets with these source addresses are dropped): # ipset list Bogons Name: Bogons Type: hash:net Header: family inet hashsize 1024 maxelem 65536 Size in memory: 17208 References: 6 Members: 10.0.0.0/8 169.254.0.0/16 172.16.0.0/12 198.51.100.0/24 127.0.0.0/8 192.0.2.0/24 213.222.29.194 224.0.0.0/4 100.64.0.0/10 203.0.113.0/24 240.0.0.0/4 0.0.0.0/8 192.168.0.0/16 44.128.0.0/16

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by lleachii＠aol.com 21 Aug '16

21 Aug '16

Waldek, Have you enabled connection tracking for the relevant bridge/VLANs/tunnels, etc. that pass traffic (as this is disabled by default on some systems for non-masqueraded traffic)? In addition, is your default iptables forwarding policy REJECT or DROP, instead of ACCEPT? 73, Lynwood KB3VWG

3 5

Re: [44net] Security/Wiki Question - Requesting a Block
by Rob Janssen 21 Aug '16

21 Aug '16

That "Requesting a Block" page has a lot of personal opinion it and also contains directives that may be valid for some regions but not for others. This already starts with the first line. Here in the Netherlands we don't use the portal for requesting blocks, only for registering blocks that are to be used for IPIP tunnels. So requesting a block does not start with the portal, but with mailing a request for a block to me and allocation of the block in the hostsfile for 44.137.0.0/16 followed by updating the DNS via the robot. Once that is done, it can optionally be registered in the portal. I recommend users not to do this unless they want to setup a gateway, because registered subnets that are not claimed by a gateway are up for grabs by other gateway operators, and given that we have widely varying skills among out users it has repeatedly happened that users (who often not even understand what it means and requires to run an IPIP gateway) create a gateway entry and add someone else's subnet to it by mistake. This then cannot be corrected by either the owner of the subnet or the coordinator of the IP space. It requires a "contact the portal admin" form entry to correct it and that may take a long time to be acted upon. (I still have two open requests of that type) I also don't agree with the "don't waste space" adagium. I allocate whatever is required for the experiment, and now that we are using BGP internally on the radio network, that also includes /30 and /29 networks for point-to-point links (/30 for links with only a router at each end, /29 when it is desired to have AP managment addresses). Unlike on the internet, we have no lack of IPv4 space on AMPRnet! There is no point in using RFC1918 addresses for this, and it causes problems with ICMP messages returned from those routers, e.g. when using traceroute. I also don't agree with "an ISP uses unroutable addresses for routers". Maybe some ISPs do that, but probably most do not. About RFC1918 filtering: YES, everyone should filter RFC1918 addresses at every entry and exit into the network. There are many configuration mistakes in ham networks, and I often see log results on those filters (which I have configured with logging on our gateway). RFC1918 addresses come in via IPIP tunnels from all over the world and also from radio. Of course it requires detailed knowledge of networking, policy routing, and NAT rules to get a mixed net44/rfc1918 LAN correctly connected to AMPRnet (with NAT or blocking for the RFC1918 systems) and let's face it: many users simply don't have that knowledge and are just trying. So, everyone else should filter that traffic so that at least it does not get propagated far. I sometimes send mail to repeat offenders and they often promise me that they will look at it, but it rarely stops completely. Rob

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by Rob Janssen 21 Aug '16

21 Aug '16

> I have use tcpdump to check how working iptables > I have try block this traffic by > but not working for me Again: you can NOT test it this way! tcpdump will show you all packets even when you are dropping them in the filter. I know this is sometimes a nuisance. It is difficult to test if your filters are working. When your filter has the structure of: - some packets dropped - some other packets dropped - more packets dropped - all remaining packets accepted (note that this is normally not a preferred structure of your blocklist) you can work around it by inserting a rule like this just before the last ACCEPT rule (or at the end of the table when the default setting is ACCEPT, again not a preferred situation): iptables -A INPUT -i tunl0 -j NFLOG --nflog-group 44 This will send the packets to a "netfilter logging" interface where you can trace it with: tshark -i nflog:44 (I don't think tcpdump supports dumping nflog interfaces but this may depend on version) The result of this is that all packets that have already been dropped above that rule will not reach the NFLOG target and will not be traced when you trace nflog:44. However, it is normally preferred to work with a "default drop" setup. You accept all packets that you know you want to accept, and drop everything else at the end of the table. This makes it less likely that things pass by that you did not think about, like other protocols than TCP and UDP. It is still possible to have NFLOG logging of everything that is accepted, by first creating a helper table like this: iptables -N NFLOGACCEPT iptables -A NFLOGACCEPT -j NFLOG --nflog-group 44 iptables -A NFLOGACCEPT -j ACCEPT Then you setup your filter table like this: iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -j DROP Rob

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by Rob Janssen 20 Aug '16

20 Aug '16

> I have try block non 44/8 traffic via tunnel IPIP with iptables but without > success > I have use ampr-ripd to create port 'tunl0' > I have add to firewall rule: > iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > but I have still a lot of traffic via tunl0 non 44/8 ip address and it is > look like this not working for me How did you validate that you still have the traffic? Does such traffic still reach an open port on your system or a system behind it? E.g. when you have telnet or ssh running, can you still telnet or ssh from internet? Note that using a trace tool like "tcpdump" or "tshark/wireshark" is NOT a valid way of testing of those filters work! When you do "tshark -i tunl0" with the above filters in place, you will still see the traffic. This is because tshark and tcpdump trace the real traffic on those interfaces BEFORE the filters have been applied. Rob

1 0

Problem with drop non 44/8 trafic via tunnel
by Waldek Waldek 20 Aug '16

20 Aug '16

Hi I have try block non 44/8 traffic via tunnel IPIP with iptables but without success I have use ampr-ripd to create port 'tunl0' I have add to firewall rule: iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP but I have still a lot of traffic via tunl0 non 44/8 ip address and it is look like this not working for me I have add one more rule like where eth0 is my internet port iptables -A OUTPUT -o eth0 -s 44.0.0.0/8 -j DROP and it is help me to not send to internet 44/8 ip traffic but I would like block incoming non 44/8 IP address via tunnel -- Waldek sp2ong

1 0

Re: [44net] iptables
by lleachii＠aol.com 17 Aug '16

17 Aug '16

It appears the the iptables rule is incorrect. In my previous configuration I had a border device NATing to a downstream device running as my AMPRNet Gateway. When I first set it up, I had THE EXACT SAME ISSUE YOU ARE EXPERIENCING. I could only receive packets after first initiating them. When asking for advice, I continued to receive information that the iptables rules were correct... THEY WERE NOT!!! Why??? As you are receiving this traffic the router interface, IT IS CONSIDERED INPUT since there are no routing rule to forward the packet (this is only done the subsequent DNAT rule added to the iptables firewall). This is an example from my DD-WRT device when I DNATed to a IPIP gateway downstream (so, this is a known working configuration): # iptables -t filter -I INPUT -p 4 -i eth0.1 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT --to-destination 192.168.0.11 Further, on the INPUT rule, you could use the -d argument and the IP address if your WAN interface has a static address. Also, after I added this rule to my device, the issue Rob describes doesn't occur (except when I explicitly added a rule to block Pings). 73, - Lynwood KB3VWG

2 1

Re: [44net] iptables
by Rob Janssen 17 Aug '16

17 Aug '16

> It is behind my ISP cable modem, I had to get it setup in bridging mode > after the last time they upgraded it. My router is showing all the > tunnel traffic (via tcpdump) so I'm fairly certain the modem isn't the > issue. Ok. I heard before from other members of this group that they had a similar setup, yet I was never able to ping them unless they first pinged me. > Central to my confusion at the moment is the rule in the nat PREROUTING > isn't counting packets. Remember that iptables NAT processing in Linux is stateful. It only sees "new" traffic for a connection. Once a connection is in the NAT table, the traffic goes "around" those rules much like Established/Related traffic in the filter tables, but without an explicit visible rule for that purpose. So, when you ping outward over a tunnel, you will not see those rules matching yet the traffic is forwarded as reply to your outgoing pings. Only when you ping from somewhere else, those rules are going to be of influence. But of course they only see traffic when it actually arrives on your router. Rob

2 1

Re: [44net] iptables
by Rob Janssen 17 Aug '16

17 Aug '16

> The latest reboot had me digging deeper to try to find the real problem > and I have discovered that only the rule in FORWARD chain of the filter > table is firing, not the DNAT in the nat table. I suspect the firewall > is only working when some connection (outgoing ?) wakes up the > masquerade rules but haven't actually found the rule that is active. Are you sure the OpenWRT box is actually seeing the incoming packets? Is it directly on the internet, or is there another box before it, e.g. an ISP provided modem/router? Even though you might have forwarded the protocol or even set the OpenWRT box as the "DMZ device", it may still do stateful firewalling on non-TCP/UDP protocols. That is a known problem with NAT routers. Try to run a trace on the OpenWRT box to verify that you can receive IPIP traffic from sources that you have not recently contacted with outgoing traffic. Rob

2 1

Re: [44net] TAPR DCC 2016 - anyone going?
by Rob Janssen 16 Aug '16

16 Aug '16

> I think with much larger address space and the availability of /56 or > larger spaces for many connections means many of us already have excess, > the second approach is worth investigating. Come up with DNS management > and a system for automatically configuring AMPRNET6 routers to share > trust information to tie the network together securely. As I said > before, I could easily allocate part of my /56 to this project. I'm > using less than 1% of my address range (1/256th to be exact :) ). Address space is not an issue with IPv6. Everyone here gets a /48 with their home internet connection. I use only 3/65536 of mine :-) For a "global IPv6 space for amprnet" we would get a /32 and map it 1:1 with the existing net-44 addresses. That will give every net-44 IP user a /56 network on IPv6. However, I too don't think is the way to go. Just use the space you get on your own internet connection for your own purposes on AMPRnet (and nag the ISP when they don't provide IPv6, give you only a /128 or /64, or assign dynamic prefixes - bad concepts in IPv6 rollout!). Extend the current DNS server and robot with AAAA records, and find or design some method of sharing the prefix list. Could be done using a BGP server. (not the internet BGP but a server on AMPRnet that distributes prefixes) Then we can interconnect on internet without the hassle we have now, and still are able to route the same addresses over wireless networks. Rob

2 1

iptables
by Niall Parker 16 Aug '16

16 Aug '16

Hello, I seem to have something broken on my firewall for redirecting incoming ipip packets to my gateway box. It appears to work fine at times but fails periodically, typically after a reset/power failure. Usually it comes back after several reboots of firewall and router but this process is inconsistent. The latest reboot had me digging deeper to try to find the real problem and I have discovered that only the rule in FORWARD chain of the filter table is firing, not the DNAT in the nat table. I suspect the firewall is only working when some connection (outgoing ?) wakes up the masquerade rules but haven't actually found the rule that is active. The firewall is running on OpenWRT using iptables (old version 1.3.8) and the rules as I think they should work are ## for ampr.org tunnels iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT \ --to-destination 192.168.99.66 iptables -t filter -I FORWARD -p 4 -i eth0.1 -j ACCEPT As I understand it, the first re-writes the destination for ipip packets to my gateway and the second allows them to be forwarded however the counter on first stays stuck at 0. A reference to what sounds like a similar problem: https://sourceforge.net/p/ipcop/mailman/message/17780204/ It would be really nice to get this sorted properly, any debugging hints appreciated. In particular, am I correct in expecting both rule counters to match ? thx ... ... Niall

1 0

Connecting to amprnet
by Jon A 16 Aug '16

16 Aug '16

Hi folks, I have a /29 subnet allocated and have been with interconnecting a few systems but want to expand that connectivity to other systems round the world. Last time I experimented with amprnet was 15 years ago and I had a ipip tunnel to a packet node that also had amprnet connectivity. That node is long gone so looking for something else to use. Reading info on the wiki, it sounds like I can now use rip and connect via the UCSD router. Have I under stood this correctly? Any idiot guides out there on how to do this or any suggestions on other ways I can connect to a gateway? Thanks Jon M1CQO

4 4

TAPR DCC 2016 - anyone going?
by Brian Kantor 16 Aug '16

16 Aug '16

I'm unable to attend the 2016 TAPR DCC next month in St Petersburg Florida. If anyone on this mailing list is going to be there, could you please let us know the substance of any discussions relevant to the AMPRNet. Thank you. - Brian

8 13

IPv6 trust model
by Dean Hall 15 Aug '16

15 Aug '16

Hello, I know the people on this maillist work on the real internet infrastructure types of networks, but I was wondering if anyone thought an overlay network, such as CJDNS [1], that uses cryptographic-generated addressing to ensure an FC::/8 address corresponds to a public certificate. would be more practical for everyday hams who only have a behind-the-ISP or dynamic IP connection to the internet. [1] https://en.wikipedia.org/wiki/Cjdns !!Dean KC4KSU

1 0

Re: [44net] TAPR DCC 2016 - anyone going?
by Rob Janssen 15 Aug '16

15 Aug '16

> It's frustrating when one has deployed IPv6 and has to keep battling > with the evils of NAT. :/ But we have a large IPv4 space available so why would we battle with NAT??? It should not be a problem to get an IPv4 address from net-44 for any of your experiments and not have to use NAT. Not that I am against experimenting with IPv6, but I am not sure which way that should go: - somehow get an "own" IPv6 range that we can manage in a similar way as the net-44 space - just use the IPv6 space everyone can get from their local provider and have only DNS support for it in ampr.org and maybe some service for listing of prefixes in use on ampr hosts to be used in firewall address lists. Having an own range appears nice, but it means we will again have the problems with internet tunneling and BGP routing that we are having now. Rob

2 1

time sync in mikrotik
by R P 15 Aug '16

15 Aug '16

I have replaced my cisco with mikrotik the ipip works ok i have two questions (for time being) 1) how do i synchronize the time ? do i need to install ntp client ? i see no ntp under the system in the gui window 2) i want to run the routing script that Marius wrote but it say it need a password ? what is the password for ? how do i get it ? Thanks forward Ronen 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

2 2

Connecting amprnet via openvpn
by R P 14 Aug '16

14 Aug '16

Hi there when Connecting amprnet via openvpn is it limited to USA only users ? what is the IP the one that connect get ? is it a special IP assigned for the vpn server ? or the user get his country IP allocation ...and can a block of ip pass ? or only single ip ? What PC software can be used ? or only linux supported ? thanks forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

2 1

TCP networking code scores own goal
by Brian Kantor 12 Aug '16

12 Aug '16

Because many of the people on this list run Linux, I mention the following article: http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… "Linux security backfires: Flaw lets hackers inject malware into downloads, disrupt Tor users, etc" If you're running Linux kernel 3.6 or later and your system is exposed to the internet, this is something you should consider taking care of. - Brian

1 0

requesting an allocation block problem
by Marcel Neupauer 02 Aug '16

02 Aug '16

Hello, I have some problem with requesting an alocatation block. I sent two alocation request on portal.ampr.org on 44.181.0.0/16 (Slovakia) one week ago. My requests are still in "waiting for coordinator" status. I tried to send "Contact us" message to portal two day ago, but my request is without changes. I am not sure that my coordinator is active on portal. Please, Who can help me with this issue, or give advice, or some mail contact. Is possible to activate some subregion block witout my inactive coordinator to me ? Thanks. 73, Marcel OM0ATE

2 1

ipencap via oprnwrt
by lz4ny＠mail.bg 02 Aug '16

02 Aug '16

Hello, I had a problem to let rip44d after an OpenWrt Chaos Calmer 15.05, but was dropped dmz traffic ipencap 169.228.66.251 not passed to the second router. In openwrt menu: Network -> Firewall -> Custom Rules I add: --- iptables -A INPUT -p 4 -j ACCEPT iptables -A INPUT -p udp --dport 520 -j ACCEPT iptables -t nat -A PREROUTING -p 4 -j DNAT --to 192.168.1.2 --- 192.168.1.2 is ip of second router or 44 gateway with rip44d After adding these lines and reboot the router all problems are corrected. Let's hope it will be useful. 73, Miro, LZ4NY ------------------------------------- P.S Вместо да разпитваш приятели и познати как се прави онлайн магазин, тествай безплатно 14 дни Shopiko – за да започнеш да продаваш. https://www.superhosting.bg/web-hosting-compare-shop-plans.php?utm_source=M…

3 6

Re: [44net] Help setting up a BSD-based gateway?
by Dan Cross 29 Jul '16

29 Jul '16

[Apologies for the repost: I meant to have a useful Subject: header and accidentally omitted that earlier.] [Forgive the top-posting: I include the full text of what I'd written several weeks ago below for refresher and reference.] To recap, I've set up IPENCAP tunnels to AMPRNet networks on a Ubiquiti EdgeRouter Lite running OpenBSD: there is one gif(4) interface per tunnel and routes are kept in a dedicated routing table (like Linux, OpenBSD supports multiple routing domains on a single system); firewall rules are used to go from one routing domain to another. The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others. A couple of quick notes on implementation: 1. The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet. 2. A similar table of tunnels is maintained. 3. Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained. 4. The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket. There is more to do; I'm sure there are a few bugs. I'd also like to query the system state at startup to initialize the routing and tunnel tables. Exporting and/or parsing an encap file would be nice. Logging and error checking can, I'm sure, be improved. It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd Please have a look and let me know what you think! - Dan C. On Fri, Jun 17, 2016 at 5:46 PM, Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote: > > I'm trying to set up an AMPRNet gateway at home and am running into > > some problems. Has anyone successfully configured a BSD-based gateway > > that would be willing to give me some pointers? > > > > [snip] > > > > It seems like what I want to do is configure a gif(4) interface > > for tunnel traffic, but my attempts at doing so all seem to fail, > > and documentation for setting up an IPENCAP tunnel is related to > > setting up IPsec gateways; my attempts at transliterating from the > > examples for e.g. Linux and Cisco et al have failed. > > > > If someone has gone down this road before and has a working > > setup, that would be tremendously helpful. If someone could send > > me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and > > possibly some 'tcpdump' output, I could probably muddle through the > > rest. If there are any caveats in setting up a 'pf' based firewall, > > that would be helpful as well. If not, I suppose my next step will > > be to reinstall RouterOS on the ERL, try and get everything configured, > > and then see if I can replicate under BSD. > > Folks, > > I just wanted to do a quick followup to this for the archives. > I am now successfully transferring traffic between my 44net subnet > (44.44.107.0/24) and the rest of the world using my OpenBSD-based > router. > > A quick recap of my setup: > 1. I have a Comcast business class circuit. > 2. I have a dedicated static IP address to use as an endpoint for > 44net traffic. > 3. My comcast router is just a router; no NATing, no firewalling. > 4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite > running OpenBSD 5.9. It has three ethernet interfaces: > a. cnmac0 is the external interface connected to Comcast's network > b. cnmac1 connects to my internal network > c. cnmac2 is my internal gateway to 44.44.107.0/24. > > On OpenBSD, tunneling interfaces for IPENCAP are provided by > 'gif' pseudo-devices. Unlike Linux, it appears that one creates a > separate 'gif' interface for each tunnel, but one seems able to > create an arbitrary number of such interfaces: I created a thousand > as a test. I'm sure there is a limit but it seems sufficiently > high that practically routing AMPRNet traffic won't run up against > it. (Again, if someone knows of a different way to configure a > single 'gif' interface so that it could support multiple tunnels, > I'd be happy to know about it). In other words, don't worry about > scalability because you are creating a separate 'gif' interface for > each tunnel to another AMPRNet site. > > On AMPRNet, the UCSD gateway *will not* pass traffic for an > IP address that does not have a corresponding entry in the AMPR.ORG > domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's. > Caveat emptor as one tries to test: make sure you have DNS entries > for your addresses and try pinging something other than 44.0.0.1 > or you'll suffer contusions banging your head against a desk trying > to figure out why nothing appears to work.... > > Once I had a tunnel up to UCSD, I found that I could ping my > 44.44.107.1 machine from a host on my internal network, but not > from arbitrary machines. This was interesting; it turns out that > hosts on my internal network get NAT'ed to another IP address on > the small subnet I got from Comcast (through another, completely > separate router -- not comcast's router but another ERL). What was > happening was that as I ping'ed 44.44.107.1 from e.g. my laptop, > ICMP echo request packets got NAT'ed to this other address and > routed over to amprgw.sysnet.ucsd.edu and tunneled back to the > external interface of my AMPRNet gateway. The gateway accepted the > encapsulated ICMP echo requests (I have a PF rule that explicitly > allows ping) and forwarded them across the tunnel interface where > they were unencapsulated; the IP stack saw that the result was > addressed to an IP address on a local interface (i.e., they were > for the router) and generated an ICMP echo response packet with a > *source* address of 44.44.107.1 and a *destination* address of the > external address of my other router (that is, the address the ICMP > echo request was NAT'ed to). This matched the network route for > my local Comcats subnet and so my AMPRNet router realized it could > pass the packet back to my other router directly. It did so and > the other router happily took the packet, matched it back through > the NAT back to the original requesting machine (my laptop) and > forwarded it: hence, I got my ping responses back. But note that > the response was not going through the tunnel back to UCSD: it was > being routed directly through the external interface. > > Now consider what happens when I tried to ping 44.44.107.1 from > a different machine on some other network. The ICMP echo request > packet gets routed through the UCSD gateway and tunneled back to > my gateway as before, but since responses don't go through back > through the tunnel, the response packet matches the default route > of my gateway and get's forwarded to comcast's router. Comcast > would look at it, see that 44.44.107.1 wasn't on one of it's known > networks that it would route floor, and discard the response. Oops. > > The solution was to set up a separate routing table in a different > routing domain specifically for AMPRNet traffic, and tie the two > together using firewall rules. In the AMPRNet routing table, I > could set my default route to point to the UCSD gateway, so any > traffic sent from one of my 44.44.107.0/24 addresses that doesn't > match a route to a known tunnel gets forwarded through > amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway > from random machines. This must seem obvious to a lot of folks > here, but it took me a little while to figure out what was going > on. Things are working now, however. > > So far I have encountered two other caveats: I decided to > configure two tunnel interfaces statically at boot time: 'gif0' > goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for > his 44.88 net. Under OpenBSD, I assumed that the natural way to > do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1 > files and this does in fact create the tunnels at boot time. However, > traffic going out from my gateway doesn't seem to get sent through > the tunnels; I did not bother to track down exactly why, but I > believe it has to do with some kind of implicit ordering dependency > when initializing PF. When I set up the separate routing domain, > it struck me that the language accepted by /etc/netstart in an > /etc/hostname.if file was not sufficiently rich to set up tunnels > in a routing domain, so I capitulated and just set up the static > interfaces from /etc/rc.local; imperfect but it works. > > The second caveat is that I seem to have tickled a kernel error > trying to set up an alias of a second IP address on my 44.44.107.1 > NIC; I get a kernel panic due to an assertion failure. It looks a > bug to me, but I haven't had the bandwidth to track it down. In > the meanwhile, simply don't add aliases to interfaces in non-default > routing domains. > > I'll try to go through my notes and type up something for the > wiki. > > The next step is to write a modified version of rip44d for BSD. > I may take a stab at that this weekend if I can get some time. As > near as I can tell, the wire format of the protocol is strictly > RIPv2; the difference is what the gateway does with the data in the > RIP packet (it sets up tunnels in addition to maintaining routes). > > Anyway, I hope this can be of some small help to someone else > who wants to run an OpenBSD-based gateway!

1 0

(no subject)
by Dan Cross 29 Jul '16

29 Jul '16

[Forgive the top-posting: I include the full text of what I'd written several weeks ago below for refresher and reference.] To recap, I've set up IPENCAP tunnels to AMPRNet networks on a Ubiquiti EdgeRouter Lite running OpenBSD: there is one gif(4) interface per tunnel and routes are kept in a dedicated routing table (like Linux, OpenBSD supports multiple routing domains on a single system); firewall rules are used to go from one routing domain to another. The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others. A couple of quick notes on implementation: 1. The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet. 2. A similar table of tunnels is maintained. 3. Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained. 4. The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket. There is more to do; I'm sure there are a few bugs. I'd also like to query the system state at startup to initialize the routing and tunnel tables. Exporting and/or parsing an encap file would be nice. Logging and error checking can, I'm sure, be improved. It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd Please have a look and let me know what you think! - Dan C. On Fri, Jun 17, 2016 at 5:46 PM, Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote: > > I'm trying to set up an AMPRNet gateway at home and am running into > > some problems. Has anyone successfully configured a BSD-based gateway > > that would be willing to give me some pointers? > > > > [snip] > > > > It seems like what I want to do is configure a gif(4) interface > > for tunnel traffic, but my attempts at doing so all seem to fail, > > and documentation for setting up an IPENCAP tunnel is related to > > setting up IPsec gateways; my attempts at transliterating from the > > examples for e.g. Linux and Cisco et al have failed. > > > > If someone has gone down this road before and has a working > > setup, that would be tremendously helpful. If someone could send > > me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and > > possibly some 'tcpdump' output, I could probably muddle through the > > rest. If there are any caveats in setting up a 'pf' based firewall, > > that would be helpful as well. If not, I suppose my next step will > > be to reinstall RouterOS on the ERL, try and get everything configured, > > and then see if I can replicate under BSD. > > Folks, > > I just wanted to do a quick followup to this for the archives. > I am now successfully transferring traffic between my 44net subnet > (44.44.107.0/24) and the rest of the world using my OpenBSD-based > router. > > A quick recap of my setup: > 1. I have a Comcast business class circuit. > 2. I have a dedicated static IP address to use as an endpoint for > 44net traffic. > 3. My comcast router is just a router; no NATing, no firewalling. > 4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite > running OpenBSD 5.9. It has three ethernet interfaces: > a. cnmac0 is the external interface connected to Comcast's network > b. cnmac1 connects to my internal network > c. cnmac2 is my internal gateway to 44.44.107.0/24. > > On OpenBSD, tunneling interfaces for IPENCAP are provided by > 'gif' pseudo-devices. Unlike Linux, it appears that one creates a > separate 'gif' interface for each tunnel, but one seems able to > create an arbitrary number of such interfaces: I created a thousand > as a test. I'm sure there is a limit but it seems sufficiently > high that practically routing AMPRNet traffic won't run up against > it. (Again, if someone knows of a different way to configure a > single 'gif' interface so that it could support multiple tunnels, > I'd be happy to know about it). In other words, don't worry about > scalability because you are creating a separate 'gif' interface for > each tunnel to another AMPRNet site. > > On AMPRNet, the UCSD gateway *will not* pass traffic for an > IP address that does not have a corresponding entry in the AMPR.ORG > domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's. > Caveat emptor as one tries to test: make sure you have DNS entries > for your addresses and try pinging something other than 44.0.0.1 > or you'll suffer contusions banging your head against a desk trying > to figure out why nothing appears to work.... > > Once I had a tunnel up to UCSD, I found that I could ping my > 44.44.107.1 machine from a host on my internal network, but not > from arbitrary machines. This was interesting; it turns out that > hosts on my internal network get NAT'ed to another IP address on > the small subnet I got from Comcast (through another, completely > separate router -- not comcast's router but another ERL). What was > happening was that as I ping'ed 44.44.107.1 from e.g. my laptop, > ICMP echo request packets got NAT'ed to this other address and > routed over to amprgw.sysnet.ucsd.edu and tunneled back to the > external interface of my AMPRNet gateway. The gateway accepted the > encapsulated ICMP echo requests (I have a PF rule that explicitly > allows ping) and forwarded them across the tunnel interface where > they were unencapsulated; the IP stack saw that the result was > addressed to an IP address on a local interface (i.e., they were > for the router) and generated an ICMP echo response packet with a > *source* address of 44.44.107.1 and a *destination* address of the > external address of my other router (that is, the address the ICMP > echo request was NAT'ed to). This matched the network route for > my local Comcats subnet and so my AMPRNet router realized it could > pass the packet back to my other router directly. It did so and > the other router happily took the packet, matched it back through > the NAT back to the original requesting machine (my laptop) and > forwarded it: hence, I got my ping responses back. But note that > the response was not going through the tunnel back to UCSD: it was > being routed directly through the external interface. > > Now consider what happens when I tried to ping 44.44.107.1 from > a different machine on some other network. The ICMP echo request > packet gets routed through the UCSD gateway and tunneled back to > my gateway as before, but since responses don't go through back > through the tunnel, the response packet matches the default route > of my gateway and get's forwarded to comcast's router. Comcast > would look at it, see that 44.44.107.1 wasn't on one of it's known > networks that it would route floor, and discard the response. Oops. > > The solution was to set up a separate routing table in a different > routing domain specifically for AMPRNet traffic, and tie the two > together using firewall rules. In the AMPRNet routing table, I > could set my default route to point to the UCSD gateway, so any > traffic sent from one of my 44.44.107.0/24 addresses that doesn't > match a route to a known tunnel gets forwarded through > amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway > from random machines. This must seem obvious to a lot of folks > here, but it took me a little while to figure out what was going > on. Things are working now, however. > > So far I have encountered two other caveats: I decided to > configure two tunnel interfaces statically at boot time: 'gif0' > goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for > his 44.88 net. Under OpenBSD, I assumed that the natural way to > do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1 > files and this does in fact create the tunnels at boot time. However, > traffic going out from my gateway doesn't seem to get sent through > the tunnels; I did not bother to track down exactly why, but I > believe it has to do with some kind of implicit ordering dependency > when initializing PF. When I set up the separate routing domain, > it struck me that the language accepted by /etc/netstart in an > /etc/hostname.if file was not sufficiently rich to set up tunnels > in a routing domain, so I capitulated and just set up the static > interfaces from /etc/rc.local; imperfect but it works. > > The second caveat is that I seem to have tickled a kernel error > trying to set up an alias of a second IP address on my 44.44.107.1 > NIC; I get a kernel panic due to an assertion failure. It looks a > bug to me, but I haven't had the bandwidth to track it down. In > the meanwhile, simply don't add aliases to interfaces in non-default > routing domains. > > I'll try to go through my notes and type up something for the > wiki. > > The next step is to write a modified version of rip44d for BSD. > I may take a stab at that this weekend if I can get some time. As > near as I can tell, the wire format of the protocol is strictly > RIPv2; the difference is what the gateway does with the data in the > RIP packet (it sets up tunnels in addition to maintaining routes). > > Anyway, I hope this can be of some small help to someone else > who wants to run an OpenBSD-based gateway!

1 0

Ampr Wiki
by Brian 24 Jul '16

24 Jul '16

Can the person who maintains the "Services" page contact me offlist please? Thanks much. -- I was going to go see a Guns 'n' Roses concert... until the liberals took away ALL the guns. Now I'm only going to see Roses *sigh* ----- 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, New Jersey, Pennsylvania, Rhode Island, and Vermont.

1 0

Running a Binary copy of RIPD on PI ?
by Rob Janssen 18 Jul '16

18 Jul '16

> That is when all work fine without errors > but before you have to grab all the gcc enviourment into the PI That is done with this single command: apt-get install build-essential Maybe you need to type: sudo apt-get install build-essential (when you are logged in as user pi) > I know how hard it was to More experts from me to compile for me the Firmware for the arduino Sometimes these things are hard, but not in the case of ampr-ripd. And when you don't try, you'll never learn... Rob

1 0

Running a Binary copy of RIPD on PI ?
by R P 18 Jul '16

18 Jul '16

Hi Fellows Since compiling is hard task for me Is it possible to take from a working PI the RipD and run it on my pi ? or the only solution is to compile ? I know on Unix some programs can run when taken from another systems ... If that can be done where can I get the RIPD executable ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

2 8

Re: [44net] Running a Binary copy of RIPD on PI ?
by Rob Janssen 18 Jul '16

18 Jul '16

> Hi Fellows > Since compiling is hard task for me Incredible... To compile it, you only need to type: make To install it, you only need to type: make install Rob

2 1

Making Gateway with PI ? and TNC as well ?
by R P 11 Jul '16

11 Jul '16

Hi there Since yesterday I have a Raspberry Pi unit connected to Arduino doing MMDVM (a project that allow making digital repeater from two analog radios) I know that a Gateway can be done with raspberry Pi 1) What exactly needed to be done (some software to add to what i have now ?) in order to deal with IPIP and make a gateway ? can it run on RASPIAN ? 2) what about making TNC from Raspberry ? i know thare is a board that stick to it and make TNC ... Or (preferred) using the Internal sound card for making TNC ? can this be done on Raspian ? and where can i get info how to do it ? Thanks For any Info Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

6 7

IP allocation in Australia
by Tony Langdon 05 Jul '16

05 Jul '16

Hi, I'm trying to get an allocation of IPs (a /28) for some projects here. The /28 is to be split between the LAN (and perhaps HSMM type wifi), and more traditional low speed RF (i.e. 2 /29s). Looking through the Australian lists, there were no existing regions within VHF range of here that I could see (I'm in Bendigo, central Victoria). Anyway, I applied over 2 weeks ago and haven't heard anything, just wondering what the normal wait time is. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

3 5

wat to do now?
by on4hu 25 Jun '16

25 Jun '16

think the English language is not a problem for the Belgian coordinator but that person is too busy it seems to me it is what emerges from the last conversation that date two year with him what to do to restore our 44net now ??? vy73s André ON4HU http://on4hu.dyndns.org:81/ http://www.on4hu.com/ http://www.on4hu.eu ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/ http://on4hu.eu/ COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING PROPERLY AS SOON AS YOU OPEN WINDOWS.

1 0

44NET
by on4hu 25 Jun '16

25 Jun '16

Coordinateurr for Bekgium NEVER answer deAR Ludovic, i have no contact wIth 44net from more than one year now, our Begium Coordinateur answer ONLY with Flemich people and never with French and do not understood our language André ON4HU http://on4hu.dyndns.org:81/ http://www.on4hu.com/ http://www.on4hu.eu ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/ http://on4hu.eu/ COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING PROPERLY AS SOON AS YOU OPEN WINDOWS.

1 0

Re: [44net] IP address allocation in Belgium
by Rob Janssen 25 Jun '16

25 Jun '16

> I try to contact him before i create the "44.151belgium subnet" and no > anwer. > ON3LA, ON3LX and ON2CQ had no answer too... O dear... my fears I would get in a similar situation as with PJ2 are becoming true... Yesterday I sent an e-mail in Dutch (should be close enough to Flemish) to the address Brian mentioned, but I have heard nothing yet. I'll try to contact someone who knows people active in the network there (which is quite widely deployed). Rob

2 1

IP address allocation in Belgium
by Rob Janssen 25 Jun '16

25 Jun '16

Is anyone aware of the procedure to allocate addresses in Belgium? I entered a request on the Portal a month ago, but got no reply. Is there some website that explains a local procedure? (like my site for the Netherlands) Rob

4 5

Re: [44net] IP address allocation in Belgium
by Rob Janssen 24 Jun '16

24 Jun '16

> Your portal request should have gone to Robbie,on4sax at on4sax.be <http://hamradio.ucsd.edu/mailman/listinfo/44net> > Perhaps you could write to him and see what's going on. > - Brian Yes I saw he is the contact for that range, but obviously he got my request by e-mail on that same address. So I wonder if there is another method in use there. (e.g. I still process IP allocation requests on my amsat.org mail, and in other countries in EU it is sometimes done via hamnetdb.net) Any users from ON on the list? Hopefully the situation does not turn out to be similar as in PJ2 :-) (but that one is now allocated and working well) Rob

3 2

44/8 routing problem at UCSD
by Brian Kantor 23 Jun '16

23 Jun '16

There appears to be a routing problem with the path to the amprgw router at UCSD. I'm investigating. - Brian

3 3

Help setting up a BSD-based gateway?
by Dan Cross 18 Jun '16

18 Jun '16

Dear Folks, I'm trying to set up an AMPRnet gateway at home and am running into some problems. Has anyone successfully configured a BSD-based gateway that would be willing to give me some pointers? Some details of my setup: * I have a comcast business-class circuit with a static IP address that I've dedicated to 44net traffic (23.30.150.141). * I have an AMPRnet network allocation (44.44.107.0/24). * The Comcast router is configured as simply a router: all NATing and firewalling is disabled and I can see tunneled traffic arriving at the external NIC of my (non-comcast) router (specifically, I see RIPv2 packets with 44net routing information in them). * My "real" router is a Ubiquiti EdgeRouter Lite running OpenBSD 5.9. I have the three ethernet interfaces on the ERL configured as follows: cnmac0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:64 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143 cnmac1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:65 priority: 0 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.129.4 netmask 0xffffff00 broadcast 192.168.129.255 cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:66 priority: 0 media: Ethernet autoselect (none) status: no carrier inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255 Where I'm getting tripped up is in figuring out where to go from here. It seems like what I want to do is configure a gif(4) interface for tunnel traffic, but my attempts at doing so all seem to fail, and documentation for setting up an IPENCAP tunnel is related to setting up IPsec gateways; my attempts at transliterating from the examples for e.g. Linux and Cisco et al have failed. If someone has gone down this road before and has a working setup, that would be tremendously helpful. If someone could send me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and possibly some 'tcpdump' output, I could probably muddle through the rest. If there are any caveats in setting up a 'pf' based firewall, that would be helpful as well. If not, I suppose my next step will be to reinstall RouterOS on the ERL, try and get everything configured, and then see if I can replicate under BSD. Much thanks in advance! 73 de AC2OI, - Dan C.

7 18

Re: [44net] disappearing ip alias ?
by Rob Janssen 18 Jun '16

18 Jun '16

> Has anyone else noted problems with the ethernet alias functionality in > recent Linux kernels ? I've just done an update on my tunnel server > (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a > day or so the 44net alias disappears. Nothing I can see in any of the > logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1' > is enough to fix it, might have to hack into a cron job :-/R Why are you still using ethernet aliases? This was originally a hack to be able to have multiple IP addresses on a single interface (using ifconfig) but since the introduction of the iproute2 package (which you apparently use, as it provides the "ip" command) this is really not required anymore. You can add addresses to eth0 without making an eth0:1 alias first. Rob

3 3

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> In any case, your subnet will be connected to the Internet by at most > ONE method: Radio, Tunnel, or Direct, and might not be connected at all, > so select at most ONE of the connection method boxes in the allocation > request. (I have asked that these selections be changed to a pulldown > list or radio buttons so that it is impossible to select more than one; > until that happens, requests having more than one box checked are likely > to be rejected.) > - Brian Why is that?? We have been happily connected on both BGP and Tunnel for some time. The gateways that are part of the tunnel mesh route to us by Tunnel and the remainder of internet routes directly. What is wrong with that? Some gateways do not want to route directly ("only AMPRnet") so it is preferred when they can use the Tunnel to the same network. Rob

8 9

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> The idea here is to support IPIP and BGP concurrently while preferring IPIP. Additionally we also > run BGP over other tunnel protocols ( GRE, SSTP, etc) with more specific preferences depending on the > agreement between the Ops. AFAICT this setup is the only way wich allows both the IPIP-only and the BGP-only > sites to reach our networks. > vy 73 de Marc, LX1DUC I agree, that is the way it works best. We do that here as well, however now we just have a single routing table where routes of different origin are stored at a different metric, so there is no fixed priority between protocols anymore. The first decision is always made on subnet size (smaller subnet has preference), the metric only comes into play when for some reason there are routes over two different protocols for the same subnet, and then the metric decides what path to take (e.g. there is both an IPIP tunnel and a a route announced with internal BGP on HAMNET). Normally these are error conditions. The difference between those methods becomes important when e.g. a /20 subnet is IPIP tunneled and out of that a /28 subnet is routed another way, e.g. over a GRE tunnel. This works without problem for us now. (on systems that are both on the normal internet and on the IPIP mesh reachable from the entire internet, with source address filtering at the provider, I normally have at least two different routing tables and policy routing, but on a directly routed system this is not required) Rob

1 0

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> On Wed, Jun 15, 2016 at 11:46:30PM +0200, Rob Janssen wrote: > >/A quick check returns the following subnets being both BGP and Tunnel routed: / > I stand corrected. > - Brian Well, before I made that list I hoped that it would be much longer... Maybe I made a mistake, it was quick cut-and-paste followed by edit and comm of the list of bgp routed subnets and the routes in my personal gateway. Anyone with a BGP subnet who has a full-featured system as a router should consider to announce the same subnet on the IPIP mesh, I think. (with a tunnel endpoint address outside net-44, certainly outside the subnet) Rob

1 0

Re: [44net] block allocation
by Rob Janssen 15 Jun '16

15 Jun '16

> I'm not saying you can't be connected in more than one way, I'm saying > that it's a special case that is unusual enough that it ought not to be > easy to mistakenly claim you're going to do. As far as I know, Rob, at > the current moment you're the only one doing this. Hmm... disappointing. I would hope everyone who is BGP routing would be doing that. I am not the only one, your gateway is doing the same thing :-) A quick check returns the following subnets being both BGP and Tunnel routed: 44.135.193.0/24 44.136.227.0/24 44.137.0.0/16 44.161.230.0/24 44.161.252.0/22 44.188.128.0/20 44.208.0.0/16 44.48.16.0/24 > Two or three times a week I get applications which have simplemindedly > checked all three boxes. Most of these people have no idea what they're > asking for Most applications of portal registrations I get are wrong or strange. It appears that the thing is confusing to newcomers. > I'm open to any suggestion that will keep me from having to go through > this process over and over again. Perhaps making 'Direct' a link which > brings up an intermediate page which presents a blurb about what checking > Direct actually means and demands that they confirm that they're really > going to get a BGP announcement from their ISP? Other ideas? It could be done with a simple Javascript on the page that presents a pop-up or reveals some explanation on the page when the checkmark is set ON.

3 2

block allocation
by Pierre-Philippe F4MZI 15 Jun '16

15 Jun '16

Hi there, I actually have a /32 IP. I plan to connect a few new machines to the network. So, I would need 3 or 4 new adresses. I went to the web page, the the network tab, and click on 44.0.0.0 / 8 <https://portal.ampr.org/networks.php?a=request&id=1> Global link. the smallest block that I can request through this link is a /24. but I don't need a /24, only a /29 how can I send my request directly from the web site ? thank you -- 73, Pierre-Philippe F4MZI

3 11

Re: [44net] block allocation
by Rob Janssen 15 Jun '16

15 Jun '16

> Subject: > Re: [44net] block allocation > From: > "Bill Buhler - AF7SJ" <af7sj(a)buhlerfamily.org> > Date: > 06/15/2016 06:47 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > > Sorry if I'm unclear, so what I'm envisioning is setting up tunnels to the > other participants of the 44 net who aren't directly internet routed and > using RIP advertisement for them. Then traffic between me and them can > bypass the main AMPR 44 net router, reducing latency and reducing bandwidth > requirements at the root node. > > In other words, if anyone on my subnets access the internet it would route > through our BGP connected uplink. If they were communicating with another > subnet on the AMPRNet it would tunnel directly to them. > > What do you think? > > Bill Buhler > AF7SJ > Indeed that is how we route here as well. Please don't remove that from the Portal! Rob

1 0

Re: [44net] Help MBOX flood
by lleachii＠aol.com 15 Jun '16

15 Jun '16

Pedro, I use the following iptables rules on my router (this will work for any console-based connection using TCP): # DROPS MULTIPLE SSH CONNECTIONS FROM SAME IP iptables -t filter -I FORWARD -p tcp --syn --dport 22 -i tunl0 -m connlimit --connlimit-above 5 -j DROP # DROPS MULTIPLE SSH ATTEMPTS FROM SAME IP WITHIN FIVE MINUTES iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state --state NEW -m recent --name sshconnect --update --seconds 300 --hitcount 5 -j DROP iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state --state NEW -m recent --name sshconnect --set The first rule drops any connections greater then five. The last two rules mark and drop more than five attempts from the same IP, for a period of five minutes. You may wish to increase the time frame. I've also added rules to block IPs that attempt to connect (or portscan) on certain TCP and UDP ports (3389/tcp, 123/udp and 161/udp are common, for example) for which I not post services as available to the AMPR Community or the Public Internet connection. In essence, even if an unauthorized person discovered the the port without being firewalled by the portscan rule, they only get 5 chances, with up to 5 concurrent connections at any given 5 minute interval (the amount of attempts vary by implementation of server and client; but once portscanned or disconnected from a given series of attempts, it counts at one connection). Each reattempt after 5, restarts the 5 minute clock. I also block Bogon IP addresses from entering tunl0: # DROPS BOGONS ENTERING AMPRNet # SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt iptables -t raw -I PREROUTING -s 0.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 10.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 100.64.0.0/10 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 127.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 169.254.0.0/16 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 172.16.0.0/12 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.0.0.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.0.2.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.168.0.0/16 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 198.18.0.0/15 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 198.51.100.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 203.0.113.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 224.0.0.0/4 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 240.0.0.0/4 -i tunl0 -j DROP I should note that in addition to this, console-based connections that I use for administration only are moved to non-standard ports. So I added another layer of protection with Security Through Obscurity (hence a portscan rule). 73, Lynwood KB3VWG

3 4

Re: [44net] Help MBOX flood
by William Lewis 13 Jun '16

13 Jun '16

Pedro: I use Fail2Ban as well, and created my own Jail to help with this. First, you will need to created jail. In the Fail2Ban directory "filter.d" create a new text file called "jnos.conf" In the file called "jnos.conf" place the following text. _____________________________________ # Fail2Ban configuration file # # Author: Wm Lewis - KG6BAJ # # $Revision$ # [Definition] # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "<HOST>" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P<host>[\w\-.^_]+) # Values: TEXT # # # # # failregex = ^.* <HOST>:.*bad login.*$ # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # # ignoreregex = ___________________________________ Next, after creating this file, in the main Fail2Ban directory, add the following to your "jail.local" file. ______________________________ # # Custom Made Bans # [jnos] enabled = true port = anyport filter = jnos logpath = /jnos/logs/nos.log banaction = shorewall action = %(action_mwl)s maxretry = 2 ______________________________ *** Note #1 : Your BANACTION may be different, depending on what your box is using as a default ban method. Look at some of the other jail entries, ( like [postfix] ). You may need to change the BANACTION to match the others. If your other jails are working with Fail2Bans default settings, you could comment out the "banaction = shorewall" with a hash so it reads "#banaction = shorewall" Obviously I use shorewall for my firewall. Your system may be using something else. Note #2 : Your path to your jnos log file may have to be tweaked to something like "/jnos/logs/filename.extension" I am using a version of jnos where I can specify that jnos logs are called "nos.log" and rotated every 24 hours. Your jnos may be custom built to call the logs something else. After you've install the "jnos.conf" jail file, and added the jnos jail settings, then restart Fail2Ban. Assuming you've made any appropriate directory tweaks needed to what I supplied, and assuming you've also adjusted your "jail.local" files email address to be your own, you should start getting emails telling you when Fail2Ban bans an IP address from the jnos logs for a bad login attempt. Note, I put MAXRETRY = 2. This tells the jail to allow 2 bad login tries, and then ban on the third bad attempt. Hope this helps. I currently show over 1300 banned IP addresses from jnos using this method. 73 Bill Lewis / KG6BAJ At 11:39 AM 6/12/2016, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Hello, > >Since last months my JNOS MBOX is being attacked: > >15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login >15:25:07 113.162.86.77:35247 - MBOX (support) bad login >15:25:09 190.140.17.22:53348 - MBOX (root) bad login >15:25:14 92.27.102.224:38887 - MBOX (support) bad login >15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login >15:25:35 190.140.17.22:54146 - MBOX (root) bad login >15:25:50 92.27.102.224:40191 - MBOX (support) bad login >15:26:33 182.184.71.162:41259 - MBOX (root) bad login >15:26:49 182.184.71.162:41259 - MBOX (sh) bad login >15:26:50 89.22.213.165:33979 - MBOX (root) bad login >15:27:52 89.22.213.165:34979 - MBOX (root) bad login > >None of the users tried have granted permit. > >Installed fail2ban but not avail. >Attacking IPs change continuosly, routing to loopback no help >Due heavy load jnos eventually hangs. > >Is it there any way/suggestion to stop this ? > >Appreciate any help. >73, lu7abf, Pedro Converso >44.153.0.1 or conversoft.com.ar >pconver(a)gmail.com >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Help MBOX flood
by Pedro Converso 13 Jun '16

13 Jun '16

Hello, Since last months my JNOS MBOX is being attacked: 15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login 15:25:07 113.162.86.77:35247 - MBOX (support) bad login 15:25:09 190.140.17.22:53348 - MBOX (root) bad login 15:25:14 92.27.102.224:38887 - MBOX (support) bad login 15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login 15:25:35 190.140.17.22:54146 - MBOX (root) bad login 15:25:50 92.27.102.224:40191 - MBOX (support) bad login 15:26:33 182.184.71.162:41259 - MBOX (root) bad login 15:26:49 182.184.71.162:41259 - MBOX (sh) bad login 15:26:50 89.22.213.165:33979 - MBOX (root) bad login 15:27:52 89.22.213.165:34979 - MBOX (root) bad login None of the users tried have granted permit. Installed fail2ban but not avail. Attacking IPs change continuosly, routing to loopback no help Due heavy load jnos eventually hangs. Is it there any way/suggestion to stop this ? Appreciate any help. 73, lu7abf, Pedro Converso 44.153.0.1 or conversoft.com.ar pconver(a)gmail.com

4 3

Raspberry Pi 3 image
by Brian 12 Jun '16

12 Jun '16

I'm in the process of uploading an image of jessie for the RPI 3 to https://sourceforge.net/projects/uronode/files/?source=navbar If you wish to give it a go, that's where it'll be in approximately an hour from this post. It's made from the kit sold near the TAPR booth at this year's Hamvention at Dayton. You'll need to edit files in /etc/ax25, /etc/postfix, and the file /usr/local/bin/ax25 other than that it should be ready to go. I did notice the main repositories that came with it failed but an apt-get update fixed those issues. It was made using the uronode-pi.tgz script available in the tools section of the same sf.net site. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Banana Pi
by Brian 09 Jun '16

09 Jun '16

Greetings; Is it me or does the Jessie version of the Banana Pi OS fail to include kernel modules for the ax25 stack?.. and if so would a custom compile of the kernel work? Curious as if anyone else has gone through this one before. I know it's fine with the Raspberry Pi but I'm not that familiar with a Banana Pi. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

3 4

Fwd: [Uronode] FCC serves Comcast
by Boudewijn (Bob) Tenty 08 Jun '16

08 Jun '16

Repeat (sorry about the formatting in my previous reposting) -------- Forwarded Message -------- Subject: [Uronode] FCC serves Comcast Date: Tue, 07 Jun 2016 13:19:12 -0400 From: Brian <n1uro(a)n1uro.ampr.org> Reply-To: n1uro(a)n1uro.ampr.org Organization: Amateur Radio Services To: uronode(a)tapr.org, eastnet(a)n1uro.ampr.org With regards to my dealings with Comcast and the faulty firmware installed in their CPE devices, the FCC has informed me that they've officially served Comcast with a direct order to resolve this problem or respond to the complaint within 30 days of receipt of the complaint. Since Comcast has admitted to me about their firmware bugs it'll be interesting to see how this is accomplished and if it's within their 30 day window. A copy of their communication is included below. " Your Ticket No. 950514 was served on Comcast Cable Communications on Jun 7 for its review and response. Comcast Cable Communications will likely contact you in an effort to resolve your issue. A response is due to the FCC no later than 30 days from today. Comcast Cable Communications will respond to you directly by postal mail. You can view a list of frequently asked questions at: https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We appreciate your submission and help in furthering the FCC’s mission on behalf of consumers. This email is a service from FCC Complaints. Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for us on the amprnet. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Fwd: [Uronode] FCC serves Comcast
by Boudewijn (Bob) Tenty 08 Jun '16

08 Jun '16

I repost this from the UroNode list with permission from the author. -------- Forwarded Message -------- Subject: [Uronode] FCC serves Comcast Date: Tue, 07 Jun 2016 13:19:12 -0400 From: Brian <n1uro(a)n1uro.ampr.org> n1uro(a)n1uro.ampr.org With regards to my dealings with Comcast and the faulty firmware installed in their CPE devices, the FCC has informed me that they've officially served Comcast with a direct order to resolve this problem or respond to the complaint within 30 days of receipt of the complaint. Since Comcast has admitted to me about their firmware bugs it'll be interesting to see how this is accomplished and if it's within their 30 day window. A copy of their communication is included below. " Your Ticket No. 950514 was served on Comcast Cable Communications on Jun 7 for its review and response. Comcast Cable Communications will likely contact you in an effort to resolve your issue. A response is due to the FCC no later than 30 days from today. Comcast Cable Communications will respond to you directly by postal mail. You can view a list of frequently asked questions at: https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We appreciate your submission and help in furthering the FCC’s mission on behalf of consumers. This email is a service from FCC Complaints. Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for us on the amprnet. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

1 0

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> On Tue, 2016-06-07 at 13:25 -0400, James Sharp wrote: > >/I haven't run in to 443 "filtering", but I have run into instances where /> >/the ISP will drop TCP connections that are active for more than a few /> >/minutes, forcing openvpn to restart the connection. / > Chances are your issue is the same as mine was. The CPE (router) has a > built in watchdog timer that cuts all sockets after a few minutes. Using > port 443 wouldn't make any difference. To the average web user this > isn't an issue because each time a page is opened/refreshed a new socket > is created, thus a new timer engages. The same may be said for services > such as pop3/smtp/etc. where you're engaging a new socket each time you > pop or send email. As long as the attachments aren't that big where you > may exceed the watchdog's timer you'll never notice this. So you can never download a file that takes more than a few minutes to complete? Terrible! Now I understand why some companies try to enforce a "download manager" to download a file of a measly 30 MB. So I can continue where I left off, yeah sure. Well it is clear that everyone should devise their own solution for tunneling and we should not change the global system to cater for limits that certain users encounter. There will always be a more severe limitation found by someone. It is better to solve these issues locally, where you have fellow users (victims) that can understand what is and what isn't possible. Colocated (virtual) servers with small storage capacity are very cheap today. Usually they are the entry level of server location, the hoster advertises their $3.99/mo server and knows that "everyone" will upgrade to more storage and pay a lot extra. But for a gateway these are perfectly usable, you can perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with the usual tunl0 and ampr-ripd, and then everyone in the area can make their VPN connection to there. Without NAT problems, and working round nasty ISPs. (you can make a VPN over almost anything if you wish) Rob

2 1

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> Ok... all important points to understand and we absolutely rely and > appreciate all your help on running the current AMPRGW solution. Before > even jumping to conclusion, we'd need to know if GRE really would be > more successful than IPIP. In Brian, N1URO's situation, I'm curious if > a Comcast "Business" class service would remove some of these > intentional filtering issues. I don't think it will be an appreciable improvement. I have experimented with GRE as the tunneling protocol (chosen exactly for this reason) to connect local stations to our Dutch gateway, and at first the results looked promising, but it did not take long before I got to the first case where plain GRE would not work over a consumer NAT router. I think it is (at least here) never caused by intentional ISP filtering, it is just caused by limitations of NAT routers that were only designed for typical outgoing TCP and UDP connections only. In the mentioned case the router was not even provided by the ISP, making malice even less likely. I then changed setup to GRE over IPsec which works fine until now when in NAT-T mode, but of course this is only suitable for use in a star configuration with connections initiated from the users to some gateway. Not a replacement for the tunnel mesh. I heard in Germany L2TP is used, I'm not sure if it is over IPsec or not. Anyway, I use L2TP over IPsec (sometimes over NAT-T) at work, it works over any connection but here as well it is a star topology. We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter OpenVPN, certainly not when it would be run in TCP mode on port 443. However, what is common in all these solutions is the star topology where the user behind the crippled router connects outward to a well-connected system. Of course we don't want to make the entire network into a star, but it could be an idea to deploy more regional gateways like our national gateway, that are interconnected by IPIP tunnels and optionally are BGP-routed on internet, and that offer services like mentioned above and discussed before in this thread to regional users who for some reason cannot run IPIP. It works well here. It is possible to deploy these on virtual servers that are quite inexpensive these days, certainly when not doing BGP (not all those hosters will offer BGP of a /16 or similar network via their routers, at an affordable price) In my experience it is possible (although not for "I am not a programmer" types) to get this working well on a Linux box. Setting up the VPN services and routing is quite well described. Setting up a firewall requires some thought and monitoring, see the recent incident with portmap. But this list is available for exchange of such information. Rob

5 4

Suggestions for the portal and the wiki
by Miguel Bahi 07 Jun '16

07 Jun '16

Thanks Brian, for your update. Yes, the Portugese hamnet site is still under construcction. I notice you when this is up and running for update the link. 73’s EB5JEQ Message: 5 Date: Mon, 6 Jun 2016 09:22:08 -0700 From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Suggestions for the portal and the wiki Message-ID: <20160606162208.GA28893(a)UCSD.Edu> Content-Type: text/plain; charset=us-ascii On Mon, Jun 06, 2016 at 02:31:39PM +0200, Miguel Bahi wrote: > Please , I suggest add in this paragraf > http://www.ampr.org/publications/ > add : Spanish hamnet www.hamnet.es I have added the Spanish HAMNET to the list of links on the publications page of www.ampr.org. There is a link on the Spanish hamnet page to the Portuguese hamnet page, but that site is still under construction so I did not add that link to the link list on www.ampr.org. - Brian

1 0

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> A possible option could be SSTP, which works over regular TCP connections > on port 443. But this is not well supported by the Linux world. > Marius, YO2LOJ SSTP is a star as well. In the open world there is OpenVPN over TCP port 443 when you want to run a VPN over TCP (I would not want that, but that is another topic). However what it seems to come down to is that these issues can be solved locally. A local Linux server or (e.g. MikroTik) router can be configured to be part of the IPIP mesh and possibly be BGP routed, and then it can serve as a VPN server for local users using whatever protocol(s) is or are locally preferred due to local situation w.r.t. internet routers and/or filtering. Rob

1 0

Re: [44net] Unable to Receive rip44 Datagram
by lleachii＠aol.com 07 Jun '16

07 Jun '16

I concur with Bob. I've had Comcast before (though, I always used my own device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've never had success using a consumer-grade router, unless it had DD-WRT or OpenWRT installed, or I used a Linux server. Some D-Link devices permit forwarding of protocols other than TCP/UDP, select the 'Other' option, and place the number 4 in the box for IPENCAP. Otherwise, most DMZ settings on consumer routers only forward TCP and UDP traffic. Since 44net (including RIP44) packets are encapsulated within IPENCAP (IP Protocol No. 4), you must forward that protocol. The Iptables Firewall is the same as on other *nix devices. If you are NATing to a device inside your LAN, the commands are similar to: # iptables -t filter -I INPUT -p 4 -i eth0 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -j DNAT --to-destination 192.0.2.8 Ensure that you are in fact seeing IPENCAP traffic entering your Local Network at your device (e.g. the to-destination address specified). Within the IPENCAP packets, you should see the password. I should also note, that I currently use Verizon FiOS; and I noticed when using their router as my border gateway, that the IPENCAP entry I make is administratively removed (Verizon has a back-door into their routers on tcp/4567) from upstream at intermittent times (I've been told this is because it's 'hard' for the carrier to track and/or rate-limit non TCP/UDP traffic). So be certain that your carrier it not removing firewall entires, especially if you were successful in the past. 73, - Lynwood KB3VWG

5 11

Re: [44net] Unable to Receive rip44d Datagram
by Rob Janssen 06 Jun '16

06 Jun '16

> Subject: > Re: [44net] Unable to Receive rip44d Datagram > From: > "Boudewijn (Bob) Tenty" <bobtenty(a)gmail.com> > Date: > 06/06/2016 08:23 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > He can check or dd-wrt or OpenWrt firmware is available for his router as these > can forward ipip or can can be set in bridge mode (dd-wrt and OpenWrt are linux based) > and much more. Well, dd-wrt is available for some commercial ethernet/wifi routers but I don't think it exists for any combo-modem-router as is normally used by cable or dsl providers. The dd-wrt people don't have the drivers/software for the modem chips used in those modem-routers. So in this case (a DOCSIS cable provider) it can only be done when he is already using a separate modem and router. > > Some firmwares in these consumer routers even don't allow to be put in bridge mode at > all. The tabs for it are just missing or they don't have an option for it in their menu. Sometimes the ISP can switch the modem-router into modem mode (bridge) from their central management system on user request. It will probably have some strings attached like "no helpdesk support for network problems". After the switchover, the internal ethernet interface will be plain ethernet or PPPoE or PPTP. So you will need an extra router that indeed can be running dd-wrt. However, with today's internet speeds on cable and dsl you also have to consider the router performance. The typical WRT54 routers from the days dd-wrt was created cannot keep up with the internet speeds of today. Rob

1 0

Re: [44net] Unable to Receive rip44d Datagram
by Rob Janssen 06 Jun '16

06 Jun '16

> I have a strong suspicion that my ISP (Charter Communications) has implemented > some kind of filtering on my home cable-based (DOCSIS) internet connection. My > reception of the RIP44d table broadcase has all but ceased. ip-ip tunnel > communication to a friend's machine in a neighboring county only seems to work > for a limited time, and only AFTER I initiate a connection from my end. It's > as if they're using some kind of NAT or port knocking filter, and only opening > the gate for incoming proto 4 traffic for a limited time after I initiate an > outgoing request to a specific host. It is, as Brian N1URO also wrote, an issue in your home router. Other routers have shown this phenomenon for some time. Even when you set a "DMZ" (meaning: forward all unknown traffic to this host), there still is a stateful firewall in place for all protocols except TCP and UDP, requiring you to send outgoing traffic before incoming traffic is accepted. You will need to have the router put in bridge mode (making it only a modem) and install a better router in front of that. With a suitable router, it can also do the IPIP encapsulation. A Linux system of course is a suitable router as well. Rob

2 1

Unable to Receive rip44d Datagram
by kd4cbm＠charter.net 06 Jun '16

06 Jun '16

Good Morning Guys: I have been working to get my chunk of .44 active for a little while now. I've become quite familiar with the concepts of how the network is set up etc. That being said, no matter what I do I cannot seem to get the RIP password that is supposed to be broadcasted from 44.0.0.1. I have go as far as to monitor, log, and filter every packet coming in the cable modem from anything AMPRNet to verify it is arriving. It just seems like the packet is never making it to my public IP. I've gone through all the basics - protocol 4(IPIP) forwarding, UDP port 520 forwarding etc. Like I said, I've even captured all packets pre firewall and I'm not seeing anything AMPRNet. Is it possible that even though my gateway/public IP is registered, the packets aren't being sent out? The last portion of getting this going is that elusive RIP pass. Any suggestions? Thanks, Jason - KD4CBM '73

4 3

disappearing ip alias ?
by Niall Parker 06 Jun '16

06 Jun '16

Has anyone else noted problems with the ethernet alias functionality in recent Linux kernels ? I've just done an update on my tunnel server (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a day or so the 44net alias disappears. Nothing I can see in any of the logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1' is enough to fix it, might have to hack into a cron job :-/ 44 net tunnels are being setup via a script from KB3VNW/LX1DUC, I suspect a few people out there would be using it ... Ideas ? ... Niall

1 0

Suggestions for the portal and the wiki
by Miguel Bahi 06 Jun '16

06 Jun '16

Please , I suggest add in this paragraf http://www.ampr.org/publications/ add : Spanish hamnet www.hamnet.es and for the wiki http://wiki.ampr.org/wiki/Main_Page in the “how to connect to amprnet” title it would be interesting add one easy guide like “ setting up a Jnos Linux gateway” 73’s ------------------------------------------------------ Miguel Bahi Cruz EB5JEQ Amateur Radio Station www.eb5jeq.es ECB03KBQ "galaxia5" CB RADIO STATION Elche Alicante Spain email y skype : miguelbahi_cruz(a)hotmail.com LOCAL VHF : 144.550mhz / UHF : 436.300mhz Echolink: Conference **ESPAÑA** AX25 Packed VHF 144.950mhz AX25mail eb5jeq#ea5dv.eaa.esp.eu APRS chat: 144.800 mhz, monitoring CQ group WWconv ampr.org **Elche_ES** BPQ32net conv **GENERAL** http://www.hamnet.es eb5jeq(a)piserver.eb5jeq.es.ampr.org http://piserver.eb5jeq.es.ampr.org email/forum/wiki/conference XMPP Sysop of EB5JEQ-1:BPQELX AX25 Node BPQnet BPQ32 144.825MHZ EB5JEQ-6:ELXMPR TCPIP Node Ampr.org Net JNOS, 144.825MHZ ( in test ) QRUEB5JEQ Aprs QRUserver ( APRSIS32 ) EB5JEQ-24/ELXNOD24 node HSMM-mesh 2,4 ghz in test EB5JEQ-50/ELXNOD5 nodo HSMM hamnet.es 5 ghz in test

2 1

Re: [44net] Exploitable portmapper service
by Rob Janssen 02 Jun '16

02 Jun '16

> Same here as there is just too much garbage coming in and it is very > labour intensive, I just block it. > Bob Well, here there is a lot more garbage coming in on other ports like 22 and 23 but I don't block that as there might be the occasional user who actually uses it. For the listed completely-blocked ports there appears to be no valid use from internet to amprnet. Internal to amprnet we are a lot more transparent, but at the gateway I do block all traffic to/from addresses without a registration within 44.137.0.0/16. This cuts the noise as well because currently about 2.8% of the addresses is registered. (after the big cleanup) Rob

1 0

Re: [44net] Exploitable portmapper service
by Rob Janssen 02 Jun '16

02 Jun '16

Thanks Brian, I was already filtering that port for traffic outside AMPRnet. It would not have affected us much because we forward new incoming traffic from internet only to users who have explicitly requested this. This list now includes 10 /28 subnets and 29 individual hosts. (189 addresses out of the 65536 address network) All other users receive new traffic only from 44.0.0.0/8, and replies to their own outgoing traffic. I added this after the SNMP DDOS incident.... in case there are other problems like this. Ports filtered here on input from internet are: 135:139,445,1025:1028 TCP and UDP (SMB) 53 TCP and UDP (DNS) 111 UDP (portmap) 161 UDP (SNMP) 1900 (SSDP) Rob

2 1

Looking for assistance setting up IP Ham system
by Arnold＠rogers 02 Jun '16

02 Jun '16

Can someone please direct me to the right place where I can purchase a complete kit so that I can setup an IP Ham network system. I would like to experiment with using using the 44Net as a fall back network in times of disaster. Any assistance / direction will be very appreciated as I am new at this. Thanks Arnold Villeneuve www.networkologist.com <http://www.networkologist.com> Change is the end result of all true learning.- Leo Buscaglia

11 19

Re: [44net] OVA for ESXi?
by Rod Ekholm 02 Jun '16

02 Jun '16

Thanks Marius. It looks like the instruction are jumbled up a bit to me, and don't include the creation syntax for the tunnel interface, on the Wiki. Maybe someone could make an edit to that?? I will try this when I get home later, and see if I can get it to play!! More to come after that! -- Rod Ekholm kc7aad(a)gmail.com

1 0

Exploitable portmapper service
by Brian Kantor 02 Jun '16

02 Jun '16

Folks, I have begun blocking the portmapper port (UDP 111) at the UCSD amprgw gateway. This is to mitigate a new DDOS exploit that is taking place on the Internet. This would prevent the use of various RPC services across the amprgw gateway, but I don't think anyone is currently using NFS, NIS, or the like in that context. The performance would be very poor in any case. You might consider blocking this port in your firewalls. I recommend that everyone running their own BGP'd subnet insert a blocking filter rule for this port as well. More information: http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-… Thanks. - Brian

4 4

Re: [44net] Looking for assistance setting up IP Ham system
by Rob Janssen 02 Jun '16

02 Jun '16

Where are you located? Most important (unless you want to build a set of portable nodes that you can all deploy yourself during an emergency) is to have others to link to. So you need to check what others are doing in your area, to be compatible with the systems they use. In the old days, everyone built their own modems and sometimes even radios, and connected them to general purpose computers running special software. However, today you can buy ready wireless link and routing equipment from manufacturers like MikroTik and Ubiquiti for prices much below what we spent on homebrew equipment, and if you wish you can build an IP network by just plugging those together and do basic routing and linking configuration. Others have taken existing hardware from Linksys and those same two and replaced the firmware with own developments that e.g. go beyond the point-to-point linking by offering automatic routing in a mesh configuration. This may be more convenient in a temporary deployment during an emergency, but the point-to-point range of such a system is less than with directed links using dish antennas. Rob

3 3

Re: [44net] OVA for ESXi?
by Rod Ekholm 02 Jun '16

02 Jun '16

I get all the way to the section where it says I need to run 'sudo ./findpass.sh', and it gives me output of 'Tunnel Socket: Setting SO_BINDTODEVICE: No suck device'. The instructions I am following are at: http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example#Setting_up_the_Tunne… And I am to the section of ' Finding the password for AMPR-RIPD" The only section that had an issue during this process is the isc-dhcp-server will not start. I don't believe this should make any difference, other than if I have a client on my Ham Network that needs DHCP, but I plan to statically assign those devices.. so I believe that point should be moot. My installation is Ubuntu 14.04.4 LTS I only have 2 interface.. eth0 (outside WAN address from ISP. One of my /29 allocations) and eth1 (inside 192.168.44.0/24) I know enough to make my way around, but am not normally a linux guy!! Let me know what other info would be helpful to share out, so we can get this one going. Thanks guys!! -- Rod Ekholm kc7aad(a)gmail.com

2 1

OVA for ESXi?
by Rod Ekholm 02 Jun '16

02 Jun '16

Thanks for the reply's guys. Lynnwood.. I have Ubuntu installed and working on my network (outside address as to not have anything blocking right now!!), but when it came time for the box to listen to the AMPR RIP broadcasts, I never did see anything. The notes say to let it sit for a little bit.. I let it sit for two days before I got back to it! :) So.. I haven't been diligently working on it, that's on me. But something seemed to go awry. Dangit. That's on me toooooo!! :( I'll try and get back to it over the next few days, and report back again. But if there are any ideas off the tops of ones heads.. Hit me with your best shot.. Fire Away!! Thanks. -- Rod Ekholm kc7aad(a)gmail.com

1 0

Re: [44net] OVA for ESXi?
by lleachii＠aol.com 01 Jun '16

01 Jun '16

Yes, but since the machine is a standard Ubuntu Linux Server machine, I'm not sure how an OVA will help you. You still have to assign your IP addresses, turn on routing, etc. per the instructions in the Wiki. In the time it would take you to transfer it the file, you could simply have the same thing by running the ISO on a fresh VM. Are you having issues with setup? 73, Lynwood KB3VWG

1 0

OVA for ESXi?
by Rod Ekholm 01 Jun '16

01 Jun '16

Has anyone built an OVA of a VM used for an AMPR Gateway yet? Or has anyone Exported their local VM that they would be willing to share? *Disclaimer:* Yes.. I realize it is easy to build a host(though my attempt so far has failed). But If someone has already put in the work to build a VM, I'm willing to piggyback in their expertise in what they've built. Thank you!! -- Rod Ekholm kc7aad(a)gmail.com

2 1

Re: [44net] AMPRNET latency in VOIP connections ?
by Rob Janssen 01 Jun '16

01 Jun '16

> two ways to solve this as well. > 1. NAT the 44. address out the public internet. That is what I am doing > here. That only works when you have made special arrangements (policy routing) to make sure the Echolink traffic is ALWAYS sent to the NAT device and never routed directly. See what I explained to Gustavo. > 2. have the server have two NIC cards. One with a 44 address and the > other a local non-routable which is then NATed ouot your public internet IP. That does not require 2 cards (you can put 2 addresses on 1 card), and it is basically the same as the policy routing method, in this case using the IP address as the base for the policy routing. In practice it can be more difficult to implement because you need to force the Echolink application to bind to the correct card address. Fortunately Svxlink can do that, but many other programs cannot. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net