- 44net - mailman.ardc.net

API new endpoint
by G1FEF 02 Oct '15

02 Oct '15

By request a new endpoint has been added to the API: GET encapSerial This returns the current serial number for the encap file, so you can poll this and decide whether you need to download the encap data. Regards, Chris

2 1

BGP announcements - where to send consent letter?
by Jim MacKenzie 25 Sep '15

25 Sep '15

Hi, I've gotten my ISP to provide me a letter to authorize advertising of my 44net subnet. Nowhere on the Wiki can I find where to send this document. Where do I send it? I glean that I need to mail it (do I need an original document from my ISP? They have given me a signed but scanned document for now). Thanks! Jim VE5EIS

4 8

Donations
by Tom Hayward 16 Sep '15

16 Sep '15

On Wed, Sep 16, 2015 at 1:44 PM, K7VE - John <k7ve(a)k7ve.org> wrote: > And don't forget to donate http://www.ampr.org/donate.html What exactly do donations fund? I'm pretty critical of the non-profits I donate to. I like to see that a minimal percentage is used for administration and that board members are elected in a democratic manner. Tom KD7LXL

3 3

Georgia Tech club
by Sam Kuonen 16 Sep '15

16 Sep '15

I've been looking at ways to get the W4AQL shack and repeater building fully internet connected and online. The current systems sit behind a departmentally managed firewall and associated network stack. Recently discovered AMPRNet... How would we go about requesting an SWIP allocation? I had an informal discussion with a senior member of the campus network team, and they do have the capability to announce using BGP to our interconnection peers on our current ASN. Respectfully, Sam Kuonen, KK4UVL

5 5

2e1avx.ampr.org / 44.131.176.32/29 sunbet and rip2 routing issues
by James Preece 15 Sep '15

15 Sep '15

Hello 44 net list, I hope there are some people still here. I am again trying to set up my gateway and route mine and a few others blocks of 44.x addresses. I have a static IP address at home and have set this up in the portal, however I am monitoring the linux pc by tcpdump and I am not seeing any RIP2 broadcast being sent to me. >From my previous testing I can confirm the Linux PC is in the DMZ and no firewall, it responds to ICMP ping packets too. My public IP is 92.234.91.114 Is anyone able to help me out here or is there a way to force a rip2 broadcast (how often are these sent?) Looking forward to catching up with you all soon Best regards James Preece M0JFP / 2e1avx James Preece | Global Services D 01932 582 063 M 07584 480 694 f5.com<https://www.f5.com> | synthesis.f5.com<https://synthesis.f5.com> [Twitter]<https://twitter.com/f5networks>[LinkedIn]<http://www.linkedin.com/company/f5-networks>[Facebook]<https://www.facebook.com/f5networksinc>[YouTube]<http://www.youtube.com/f5networksinc>[DevCentral]<https://devcentral.f5.com/> [F5 Logo and Tagline]

6 10

va7dgp.ampr.org
by Don Poaps 14 Sep '15

14 Sep '15

Greetings.. I'm running a Windows based BPQ32 BBS. John Wiseman GB8BPQ has made it possible that we can use the AMPRnet. I have gotten my 44.135.192.160/29 listed in the Encap. What I need is to add four more. va7dgp.ampr.org 44.135.192.160 Subnet va7tsa.ampr.org 44.135.192.161 bpq.va7dgp.ampr.org 44.135.192.162 bpq.va7tsa.ampr.org 44.135.192.163 I see a menu to add a Subnet but I don't the capability to add the above. I've bombarded Luc ve3jpl email. He must be on vacation or away.. I know we are all Hams/Volunteers 73 Don va7dgp *Don Poaps* *New Westminster, BC* *VA7DGP*

4 6

Re: [44net] 2e1avx.ampr.org / 44.131.176.32/29 sunbet and rip2 routing issues
by Steve L 05 Sep '15

05 Sep '15

James, A few of us have web based tools that will allow you to ping. Which for testing purposes is the same as receiving RIP as it all rides on protocol 4 (ipencap). http://44.92.21.1/tools/php-ping/php-ping.php

1 0

Description of specific use the RIPv2 in AMPR-Net.
by Richard RU3DSH 03 Sep '15

03 Sep '15

Dear colleagues! From the information on the site wiki.ampr.org, implies that the construction of the AMPR-Net node require support of protocol RIPv2. At the same time, from the same source, it follows that the standard systems with support RIPv2 are not suitable for this case. From this we can conclude that RIPv2 used in an unusual way. *Where can I get an introduction to this non-standard system that allows to understand the technical sense?* Looking archive mailing list, I received some fragmentary information. I realized that RIP is not used to compare alternative routes for efficiency, but for accounting for the dynamic addresses. However, all the circumstances I not grasped. I think that every first administrator, thinking through the design of the node, asks this question. And surely, somewhere there must be a document drawn up for those interested. I was very surprised, when not to find the answer to this question in the FAQ. If he's still there, and I was looking bad, forgive me, and specify its location. If not - please help me and tell me about this non-standart solution. Advance very grateful. -- 73! Yours faithfully, Rihard RU3DSH.

5 8

Check...
by Marius Petrescu 26 Aug '15

26 Aug '15

It seams extremely quiet for some time. Do I have a mail filter/setup problem? Marius, YO2LOJ

2 2

Re: [44net] ENCAP ro BGP
by Rob Janssen 19 Aug '15

19 Aug '15

> Subject: > Re: [44net] ENCAP ro BGP > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 08/19/2015 05:31 AM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > Brian Kantor, > > Concerning hosts with no DNS entries can only use the IPIP mesh system. > > Couldn't this be tweaked at UCSD to allow only 44net traffic for hosts > with no DNS entries? Thus letting BGP'd 44 hosts be able to > communicate with IPIP 44 hosts regardless of DNS entries? What would be the advantage? Why not just register a DNS entry for any address you want to use? In fact, I constructed the same filter as UCSD has in our gateway (which is BGP routed), just to cut out most of the crap before it enters the radio network. Anyone who wants to use an address can always have it registered. Rob

1 0

Re: [44net] ENCAP ro BGP
by Steve L 19 Aug '15

19 Aug '15

Brian Kantor, Concerning hosts with no DNS entries can only use the IPIP mesh system. Couldn't this be tweaked at UCSD to allow only 44net traffic for hosts with no DNS entries? Thus letting BGP'd 44 hosts be able to communicate with IPIP 44 hosts regardless of DNS entries? And of course if there is a DNS entry then (like now) allow general/all inbound traffic. Just a thought, not sure if it raises any other issues. Steve, KB9MWR marius at yo2loj.ro wrote: >John, > >Yes, you should be able to send encapsulated data via amprgw and get the >correct replies, but only for specific BGP announced and registered >subnets. > >Arbitrary 44net targets not in those BGP announced networks are NOT >forwarded via amprgw, and only DNS registered hosts will be able to use >the gateway (as you correctly assume). > >Hosts with no DNS entries can only use the IPIP mesh system, since there >is usually no check for that criteria on the gateways, and any subnet >match is accepted. > >Marius, YO2LOJ

2 1

Re: [44net] OpenWRT
by Steve L 16 Aug '15

16 Aug '15

Bill, I don't know what Lynwood has, but as a winter project I was going to attempt the same thing on a Netgear WNR3500Lv2 running OpenWRT. It too has: 5 GigE Ports, and a USB 2.0 Port 128 MB NAND flash and 128 MB RAM Steve, KB9MWR

4 3

OpenWRT
by lleachii＠aol.com 15 Aug '15

15 Aug '15

Also, I forgot one step - I created a bridge interface between tunl0 and a new VLAN, I named it 'amprnet'. I assigned the bridge 44.60.44.1. - Lynwood KB3VWG

1 2

OpenWRT
by lleachii＠aol.com 15 Aug '15

15 Aug '15

Dani, That is EXACTLY what I'm seeking...! Has anyone compiled ampr-ripd v1.13 for MIPS 74Kc - Linux? - Lynwood KB3VWG On 08/13/2015 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > My router happens to be PPC instead of the more common MIPS. If your > router is also PPC by chance, then I can send you the ampr-ripd binary > to save you the process of cross-compiling.

3 6

New Linux Boot Scripts for Testing
by Steve L 08 Aug '15

08 Aug '15

Should anyone care for more tools for their own testing. feel free to use: http://44.92.21.1/tools/

3 3

GB7CIP
by Brian 06 Aug '15

06 Aug '15

Anyone know the status of G4APL's node? I haven't seen it on for a couple weeks now. -- A computer once beat me at chess, but it was no match against me in kick-boxing - Emo Phillips 73 de Brian Rogers - 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.

8 17

DNS question
by Christopher Munz-Michilein 06 Aug '15

06 Aug '15

Howdy all, I’ve got a question about DNS and rDNS - I submitted a request to the portal to have DNS addresses added for my subnet a couple of months back and have not received any feedback regarding the status and was just wondering if there was something else I needed to do to move things along. I’ve also noticed recently that there appears to be an incorrect rDNS record associated with the subnet and was wondering if that was just old info or if some DNS records had been added incorrectly. The subnet in question is 44.135.193.0/24 and the DNS record I found is ve8jl.ampr.org <http://ve8jl.ampr.org/> Cheers, Chris VE7ALB & VA7OL

2 1

Scripts
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > [44net] Scripts > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 08/05/2015 03:57 AM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > So that got me thinking maybe this same concept could be applied to > the BGP'd subnets, forcing them to use masquerading. But rather a > rule on the source address, we set it for destinations. > > Here is what I came up with. (Untested) > > http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-bgp > > Basically I download a list of all the BGP'd subnets, and set a flag > like before and force them out as masqueraded. > I think it is preferable to IPIP encapsulate the traffic to a place where it can be sent with its original source address, over masquerading it to the public IP. When you have a default route in table 44 pointing to AMPRGW it will work OK without requiring exceptions for BGP routed subnets and it will also work to public internet. When you want to route only to AMPRnet you can use a 44.0.0.0/8 route to AMPRGW instead. (instead of AMPRGW, you can also use a more specific gateway that is on a not source-address filtered host and is closer to you, when they want to provide that service. e.g. for 44.137.0.0/16 hosts our gateway can be used for that) Unfortunately this still breaks in case an IPIP gateway is using an endpoint address within 44.0.0.0/8 Rob

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > lleachii(a)aol.com > Date: > 08/04/2015 11:17 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Nigel, > > - I should be a properly configure IPIP gateway. > > Can you reach me? > > 44.60.44.0/24 > 44.60.44.1 - router > 44.60.44.3 - DNS > 44.60.44.10 - HTTP At the time you wrote that it was not yet working, but now I can reach you from here! So it appears you have fixed it. Good! Rob

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 08/04/2015 09:34 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Tue, Aug 4, 2015 at 12:19 PM, Rob Janssen<pe1chl(a)amsat.org> wrote: >>> >>The hamwan.org remain unreachable >> > >> >It goes via radio to our 44.137.0.0/16 gateway and from there over plain >> >internet (it is BGP routed). >> >You may have trouble trying to access this with some of the typical tunnel >> >setups because they provide no tunnel endpoint. > Indeed, this is what you should be seeing for hamwan.org at the > moment. Since our gateway was deleted from the portal we have not gone > in and rebuilt things. > > We are properly BGP routed, so any machine on the internet (and not > behind amprgw) should be able to access it. The system where I tested this (our gateway system) can send internet traffic from 44.137.0.0/16 without source address filtering issues. However, the typical ISP line here is source address filtered, so I cannot send traffic from a 44.137.x.x address directly from my home line to you on your BGP routed network. Traffic to other IPIP gateways is encapsulated in an outer header with my public IP and the public IP of the tunnel endpoint I route to, so my ISP does not filter such traffic. However, when I want to send from my 44.137.x.x address to any other system, either outside 44.x.x.x or in the 44.x.x.x network but not routed via IPIP, I need to encapsulate it and send it to some system that can send that traffic without source address filter. Before we had our own gateway, it was usual to send this traffic to AMPRGW. But that did not work for this case. That appears to have been resolved now. Our own gateway could already do this. However, there is still the issue of "what to do with traffic" (encapsulate it or not, what source address to use) sent to 44.x.x.x. It was difficult to do it right when the tunnel endpoint falls within the 44.x.x.x network. This was the actual reason why your tunnel endpoint was removed after discussion here. I think when you bring back the tunnel endpoint (which of course is preferable), you should try to get an IP outside 44.x.x.x for the tunnel endpoint, as most users have done. That reduces the risk of problems. I do not believe in setting up exception lists for ranges that are BGP routed or are used as tunnel endpoints but are within 44.x.x.x, that is just making everything complicated and makes it break down when people are not always on the watch for changes in the network. The automatic handling provided by (ampr-)ripd is much preferred over such manually maintained configuration. Rob

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > Gustavo Ponza <g.ponza(a)tin.it> > Date: > 08/05/2015 01:52 AM > > To: > 44net(a)hamradio.ucsd.edu > > > > The following is the routing situation seen from here; the 44.137 IPIP routes > result correctly addressed toward the commercial GW IP addresses according > to the above statements. > The routes are collected from the gw.ampr.org and so only that setup there. > Now, as per my understanding, all the whole 44.137 GWs should be setup > on the same way of that (above) pingable GWs to be reached via tunl0. > > root@ir0rm-7:/# route -n|grep 44.137 > 44.137.2.138 84.106.127.22 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.24.1 88.159.160.228 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.24.5 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.25.62 88.159.83.58 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.32.50 84.83.147.249 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.0.49 77.175.246.216 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.2 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.1 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.10 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.40.20 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0 > 44.137.1.160 46.21.164.170 255.255.255.240 UG 0 0 0 tunl0 > 44.137.1.208 195.240.133.194 255.255.255.240 UG 0 0 0 tunl0 > 44.137.33.16 84.83.147.249 255.255.255.240 UG 0 0 0 tunl0 > 44.137.33.32 62.45.244.128 255.255.255.240 UG 0 0 0 tunl0 > 44.137.51.64 130.255.72.61 255.255.255.240 UG 0 0 0 tunl0 > 44.137.37.160 82.161.55.187 255.255.255.240 UG 0 0 0 tunl0 > 44.137.37.176 82.139.110.195 255.255.255.240 UG 0 0 0 tunl0 > 44.137.37.192 31.151.69.80 255.255.255.240 UG 0 0 0 tunl0 > 44.137.41.128 83.160.55.17 255.255.255.240 UG 0 0 0 tunl0 > 44.137.27.112 88.159.160.228 255.255.255.240 UG 0 0 0 tunl0 > 44.137.31.32 82.176.45.37 255.255.255.240 UG 0 0 0 tunl0 > 44.137.0.0 213.222.29.194 255.255.0.0 UG 0 0 0 tunl0 > >> For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute, >> you should see a couple more hops after the tunnel that are radio hops. > > That IP address doesn't appear on the above list but it is positively > pingable That is correct, Gus. The above list except the last line are routes to individuals that are directly on the IPIP tunnel mesh. The last line is a route for everyone in NL that is not on the IPIP mesh, via a gateway system that is both on IPIP and BGP and also routes to radio networks inside the country. The address 44.137.41.97 is on such a radio network, so you get the route to 44.137.0.0 (because it does not appear in the list of more specific entries) and from there via 2 more hops to my station. I think there is no problem with this routing, but the fact that I cannot reach some stations even though all routing is correct is caused by problems with home routers. Some people are behind NAT routers providerd by their ISP, and they have difficulty forwarding the IPIP packets we are using. Some of those routers incorrectly apply stateful firewall rules to (part of) the IPIP incoming traffic. When such a user sends traffic outward, the router puts the temporary rule in place that allows incoming traffic from the tunnel endpoint they route to, and the link works both ways. But when the first traffic is from outside, the IPIP packet never makes it through the router and there is no reply. I have been trying to help a local user who has this problem, and it looks like IPIP is just not possible with them. At least not when the user wants to accept incoming connections. The strange thing is that it appears to work from some systems, and not from others. I have not yet found a clue why this is. Others? Rob

1 0

Scripts
by Steve L 05 Aug '15

05 Aug '15

Well I think maybe Brian Kantor has simplified the IPIP <-> BGP connectivity dilemma for everyone. I was able to ping hamwan.org earlier. It's not working right now, so I'll assume there are some bugs still being worked out. So really what I am about to share may no longer be needed, but I'll share it for informational purposes. Recap: Last month I shared an idea for someone where I had cooked up a way for some hosts on his RF LAN to be reachable via UCSD, and the rest masq'd. http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-n3fe To which PE1CHL replied he does something similar, but he use the mark to enable the masquerading So that got me thinking maybe this same concept could be applied to the BGP'd subnets, forcing them to use masquerading. But rather a rule on the source address, we set it for destinations. Here is what I came up with. (Untested) http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-bgp Basically I download a list of all the BGP'd subnets, and set a flag like before and force them out as masqueraded.

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 05 Aug '15

05 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > Gustavo Ponza <g.ponza(a)tin.it> > Date: > 08/04/2015 02:10 PM > > To: > 44net(a)hamradio.ucsd.edu > > > As per the 44.88.0.9: > > As per my tests since this morning (local time) for the first time > I can ping and connect the http and ftp facilities at 44.88.0.9 and > downloaded some files... never happened since years to now!!! > Hope that Brian will share his actual GW setup, TNX. > > As per the 44.137.0.1 and subnets: > > Report is that the 44.137.0.1 GW is promptly pingable, but regarding > their subnet only the following are *correctly* pingable, namely: > > 44.137.24.5 > 44.137.40.1 > 44.137.40.10 > 44.137.40.2 > 44.137.40.20 > > all the other not. Those addresses are not on the 44.137.0.1 gateway but on two different private gateway systems that advertise only those addresses. I hope everyone correctly implements a "most specific route first" policy that means that traffic to such addresses goes to the indicated tunnel endpoint (89.18.172.155 and 89.18.172.156) while other addresses in the 44.137.0.0/16 network are routed to tunnel endpoint 213.222.29.194. That should be no problem on e.g. a Linux system. For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute, you should see a couple more hops after the tunnel that are radio hops. > > As per the 44.60.44.10: > > Remain not pingable > Same for me! > The hamwan.org remain unreachable That one is reachable for me: traceroute hamwan.org traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets 1 gw.pe1chl.ampr.org (44.137.41.110) 0.248 ms 0.337 ms 0.428 ms 2 cisco1.pi1utr.ampr.org (44.137.41.254) 2.254 ms 20.621 ms 21.124 ms 3 pi1utr.pi9noz.ampr.org (44.137.60.1) 22.615 ms 34.658 ms 34.694 ms 4 213.222.29.193 (213.222.29.193) 68.524 ms 68.560 ms 68.582 ms 5 0.xe-7-0-1.xr4.1d12.xs4all.net (194.109.12.5) 68.636 ms 70.600 ms 71.415 ms 6 0.ge-0-2-0.xr1.sara.xs4all.net (194.109.5.2) 73.308 ms 77.651 ms 77.645 ms 7 er1.ams1.nl.above.net (80.249.208.122) 79.347 ms 64.952 ms 11.503 ms 8 ae14.cr1.ams10.nl.zip.zayo.com (64.125.21.77) 13.982 ms 14.622 ms 15.123 ms 9 v142.ae29.cr2.ord2.us.zip.zayo.com (64.125.30.170) 112.583 ms 112.614 ms 113.365 ms 10 ae11.cr1.ord2.us.zip.zayo.com (64.125.20.245) 118.816 ms 119.403 ms 120.093 ms 11 v11.ae29.mpr1.sea1.us.zip.zayo.com (64.125.31.50) 158.630 ms 159.681 ms 160.046 ms 12 216.200.88.129.z00003.above.net (216.200.88.129) 159.559 ms 159.593 ms 159.922 ms 13 ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 150.858 ms ge0-0-0-0-sea3.threshinc.net (209.189.201.213) 151.354 ms ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 151.977 ms 14 seattle-er1.hamwan.net (209.189.196.68) 152.033 ms 150.810 ms 151.959 ms 15 eth0.seattle-srv1.hamwan.net (44.24.241.98) 149.933 ms 150.508 ms 151.199 ms It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed). You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint. Rob

5 7

Re: [44net] 44Net Digest, Vol 4, Issue 115
by lleachii＠aol.com 05 Aug '15

05 Aug '15

Apologies, I meant to send the last email to my local ARES/RACES reflector regarding National Night Out. - Lynwood

1 0

Re: [44net] 44Net Digest, Vol 4, Issue 115
by lleachii＠aol.com 05 Aug '15

05 Aug '15

County Exec last spotted in Upper Marlboro, I didn't have reception. - Lynwood KB3VWG

1 0

Re: [44net] DMARC
by Brian Kantor 04 Aug '15

04 Aug '15

Well, if I did everything right, the people on yahoo, comcast, and sbcglobal who weren't getting messages from this mailing list because of those ISPs' DMARC filtering should now be getting messages once again. - Brian

3 4

DMARC
by Brian Kantor 04 Aug '15

04 Aug '15

It appears that comcast and yahoo have implemented DMARC mail filtering around the first of the month. This breaks mailing lists such as 44net. As a result, about a dozen people have had their mail from this list bouncing and they've been unsubscribed from the list as a result. This message won't reach them, but if you happen to hear from a former participant in this list who is wondering what happened, you might let them know that their ISP has broken mail filtering software in place that is blocking their participation. - Brian

2 4

test header munging
by Brian Kantor 04 Aug '15

04 Aug '15

testing header munging for DMARC

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 04 Aug '15

04 Aug '15

> Subject: > Re: [44net] New Linux Boot Scripts for Testing > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 08/03/2015 01:45 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Ok. It seems I got that wrong. > Actually there is no reply via tunnel. I can ping your system only via the > public internet. > > Marius Same for me, Marius! I did (just as for N1URO) detailed tracing of the network traffic and although there is outgoing encapsulated IPIP traffic to his advertised gateway, there is no reply whatsoever. It is still unclear to me if there is some problem with the operation of the network, or a systematic bug in the scripts that some people use. This time I thought I could download a script and have a look, maybe I see some problem, but I cannot access the site from any address I tried... :-( Rob

4 10

Re: [44net] New Linux Boot Scripts for Testing
by Steve L 03 Aug '15

03 Aug '15

What might want to be considered in future portal enhancements under the gateways details section is a checkbox for if that particular gateway uses 1)rip44d by OH7LZB 2) ampr-ripd by YO2LOJ 3) A munge script Really if nothing else for statistical purposes. I realize gateway ops could be listing this voluntarily in the gateway note section till then. It might also be a good idea to have another field to list the radio LAN connectivity speed. (So people know to go gently with broadcast pings and nmap) It might also be nice to list the BGP connected subnets somewhere on the portal. For those not aware, you can see that now by: http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44\."

2 1

Re: [44net] New Linux Boot Scripts for Testing
by Steve L 02 Aug '15

02 Aug '15

I am running Marius' ampr-ripd version, routes show "proto 44" root@kb9mwr# ip route show table 44 <clip> 44.182.69.0/24 via 5.15.186.251 dev tunl0 proto 44 onlink window 840 44.182.83.0/24 via 95.76.237.2 dev tunl0 proto 44 onlink window 840 44.185.1.0/24 via 109.107.73.62 dev tunl0 proto 44 onlink window 840 44.185.4.0/24 via 109.107.73.62 dev tunl0 proto 44 onlink window 840 etc.. kb9mwr@kb9mwr:~/test/ampr/ampr-ripd-1.13 $ grep "proto" ampr-ripd.c * Observation: All routes are created with protocol set to 44 req.rtm.rtm_protocol = RTPROT_AMPR; Marius can you explain the purpose of that for us? I am not completely sold that is the problem, but at the same time I don't pretend to understand the proto 44's purpose either. Thanks. Steve, KB9MWR ------ Quote ------ Can everyone verify their AMRPRNet tunl0 route tables do not include the following value: "proto 44" This appears to have somehow entered some stations routing tables, the value should be "table 44" for routers using a separate routing table, as defined in STARTAMPR; or by using '-t' switch with RIP44d. The ROUTING PROTOCOL value "proto 44" is invalid for routing on AMPRNet, and I understand it should be zero (0) or unspecified. - Lynwood KB3VWG

1 0

Re: [44net] New Linux Boot Scripts for Testing
by Rob Janssen 02 Aug '15

02 Aug '15

> Subject: > [44net] New Linux Boot Scripts for Testing > From: > <lleachii(a)aol.com> > Date: > 08/02/2015 08:23 PM > > To: > 44net(a)hamradio.ucsd.edu > > > The files and README are located here for those on AMPRNet: > > http://44.60.44.10/amprnet_docs/start_ampr_version From AMPRnet, I cannot reach this system at all. From another internet address, I get a 403 error. How do you route to 44.137.0.0/16? Route from here to you is via a tunnel: 44.60.44.0/24 via 96.255.40.79 dev tunl0 Tunnel endpoint cannot be pinged, 44.60.44.10 neither. Packets go out into the tunnel, nothing comes back. Same problem as with N1URO. Rob

1 0

AMPRNet Munge script package
by Assi Friedman 29 Jul '15

29 Jul '15

Folks: I am using a pretty old munge package. I looked on the wiki/portal but I could not find the scripts, just references to it. Is it hidden somewhere? Thank you, Assi

2 1

Tomorrow 2015-07-29
by Brian 29 Jul '15

29 Jul '15

Just a friendly reminder that M$ will be releasing Windows 10 online, and millions of desktops are expected to suck up bandwidth because of this. Packet loss may be a very normal thing tomorrow. -- A computer once beat me at chess, but it was no match against me in kick-boxing - Emo Phillips 73 de Brian Rogers - 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] RIPv2
by Rob Janssen 28 Jul '15

28 Jul '15

> Subject: > Re: [44net] RIPv2 > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 07/27/2015 05:44 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Mon, Jul 27, 2015 at 08:26:08AM -0700, Assi Friedman wrote: >> >Addressing residential internet service with DHCP is a problem with the >> >encap method. Does RIPv2 address this problem? >> >Thanks, >> >Assi > Short answer: Not really. > > If you're referring to the dynamic nature of some home connections where > the address may vary from hour to hour or day to day, there is no good > solution to the problem. It is interesting to see that the implementation of home connections varies so much over the world. Over here there is a legal obligation to always be able to produce the name and address of the subscriber that owned an IP address at a certain point in time, and it appears that most providers have taken the easy way of assigning a fixed IP to each subscriber. DSL connections all have a fixed IP. Cable connections usually have an IP that is fixed as long as you do not turn off the cable modem for a few days or so. There is no hourly or daily cycling of addresses anywhere. Truly dynamic IP is only in use here on mobile connections, and often they are behind NAT so not possible to use an ipip tunnel on them anyway. I have implemented OpenVPN and IPsec on our gateway so those users still can get connected to AMPRnet. I would think that when your address really changes hourly, and you want to be on an AMPRnet tunnel, it would be best to arrange something similar, a VPN to a system on a fixed address. It should be easy to arrange for such a thing, e.g. with a group that share a cheap VPS for it that can also be used for mail, a webpage etc. Rob

2 1

Re: [44net] N1URO and traceroute. Was: Iperf server for public use
by Rob Janssen 28 Jul '15

28 Jul '15

> Subject: > Re: [44net] N1URO and traceroute. Was: Iperf server for public use > From: > Brian <n1uro(a)n1uro.ampr.org> > Date: > 07/26/2015 10:13 PM > > To: > 44net(a)hamradio.ucsd.edu > > My firewall rules were already installed fine and without incident 4th > of July weekend when botnets were flooding my subnet, including the > internet searching to exploit LogJam (which killed eBay and Yahoo as > examples) I still cannot ping you, I see no replies from you arriving on our external interface. So presumably something is wrong, but it may not be the same firewall rules. Those were probably applied to input, while this is something at output or a problem with the routing / rules. I think it worked OK before. Rob

1 0

ipip.routes and rc.local
by Assi Friedman 27 Jul '15

27 Jul '15

More of a Linux question, but worth a shot since others have probably been to this rodeo before. I have come across an issue starting AMPRnet automatically at boot. The ipip.routes script seems to fail starting the tunl interface when ran by the system by the rc.local script. Interestingly, when ipip.routes is ran in the crontab (nightly update) there are no issues. So this is specifically related to the rc.local script. Anyone else run into this issue? Thanks, Assi kk7kx

4 3

Packet loss through UCSD?
by Assi Friedman 27 Jul '15

27 Jul '15

Folks: I just brought my ampr host back online after moving to a new facility. My initial configuration is to enable internet <-> amprnet connectivity. So I have all traffic in both incoming and outgoing directions routed IPIP'd via UCSD. The host is Linux Fedora based (will be transitioning to CentOS sometime...) and I used the guidelines set on the wiki. One unexpected thing is packet loss. I am seeing very slow performance using this approach and rather poor packet loss. Are there any issues or QoS policies implemented on the amprnet router at UCSD? Thank you, Assi kk7kx/4x1kx AMPRNet host: kk7kx.ampr.org (icmp & http only for now) Internet host: phantom.kiloxray.com (hosts kk7kx)

11 30

ampr WWC HUB_UK
by Paul Lewis 27 Jul '15

27 Jul '15

Hi Chris Is this server Convers HUB_UK back online?? 73 de Paul G4APL CatHam_UK GB7CIP

2 1

Re: [44net] Iperf server - kk7kx
by Assi Friedman 27 Jul '15

27 Jul '15

Are there benefits to using the API as compared to wgeting (yup, it's a word) the encap file? Assi -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Chris Sent: Monday, July 27, 2015 12:41 AM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Iperf server - kk7kx (Please trim inclusions from previous messages) _______________________________________________ > On 27 Jul 2015, at 03:30, Assi Friedman <assi(a)kiloxray.com> wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > Just downloaded and updated the encap file from portal.ampr.org. My > node is now updated with the recent file. Is there a way to automate > download of the encap file via ftp or wget? > Thanks, > Assi The preferred solution is to use the API, you can then run a cronjob at whatever frequency you prefer to check for changes and update your routes. Chris _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

2 1

Re: [44net] RIPv2
by Assi Friedman 27 Jul '15

27 Jul '15

Addressing residential internet service with DHCP is a problem with the encap method. Does RIPv2 address this problem? Thanks, Assi

3 2

Re: [44net] Iperf server - kk7kx
by Rob Janssen 27 Jul '15

27 Jul '15

> Subject: > Re: [44net] Iperf server - kk7kx > From: > Assi Friedman <assi(a)kiloxray.com> > Date: > 07/26/2015 12:23 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Based off the output of the munge script, those two addresses take > different paths: > /sbin/ip route add 44.137.41.96/28 via 89.18.172.156 dev tunl0 onlink > /sbin/ip route add 44.137.0.0/16 via 213.222.29.194 dev tunl0 onlink Ok... THAT explains something! This is *old* data. That 44.137.41.96/28 entry was removed on April 25th this year, and you still have it in your table. The 44.137.41.96/28 network should now be routed via the 44.137.0.0/16 entry, as I have moved this network from a tunnel route to a radio link to our Dutch HAMNET which connects to internet via a national gateway for 44.137.0.0/16. It looks like your method of managing routes only adds and modifies entries, but never deletes them. I'm interested in what method you are using, and if you maybe have copied it from someone else who also still uses this. It would explain some of the broken routing we are facing. Of course when some route no longer appears in the encap table, you should make sure you also delete it from your local routing table. Else you will have more and more incorrect routes as a result. Maybe it is better to switch to using ampr-ripd, which would not have this problem. Rob

4 6

Re: [44net] Iperf server for public use
by Steve L 26 Jul '15

26 Jul '15

Corey, I get ping replies from 44.88.0.9 To traceroute over a tunnel, you may have to change the TTL to 64 like so: This is from my gateway, 44.92.21.1 root@ampr-gw:~# ip tunnel change ttl 64 mode ipip tunl0 root@ampr-gw:~# traceroute 44.88.0.9 traceroute to 44.88.0.9 (44.88.0.9), 30 hops max, 60 byte packets 1 gw.ct.ampr.org (44.88.0.1) 62.346 ms 68.416 ms 68.897 ms 2 n1uro.ampr.org (44.88.0.9) 71.669 ms 72.287 ms 72.554 ms root@ampr-gw:~# ip route show table 44 | grep 44.88.0 44.88.0.0/27 via 76.28.121.159 dev tunl0 proto 44 onlink window 840 44.88.0.2 via 76.28.121.159 dev tunl0 proto 44 onlink window 840 44.88.0.192/29 via 76.28.121.159 dev tunl0 proto 44 onlink window 840 44.88.0.200 via 66.162.28.8 dev tunl0 proto 44 onlink window 840 44.88.0.201 via 66.162.28.8 dev tunl0 proto 44 onlink window 840 If I remember correctly N1URO uses the munge method, and exactly how he has that configured is best to leave to him explain. Steve, KB9MWR

5 5

Re: [44net] portal down?
by Brian Kantor 26 Jul '15

26 Jul '15

Chris tells me they had a minor fire in the datacenter where the portal lives and they have to install some new servers and restore from backups so the portal (and www and wiki) will be out of service for some days until after the paying customers are back on line. This seems entirely reasonable to me; we can get along without it for a little while. And again I want to say thanks to Chris for writing and hosting the portal and our other web sites. - Brian

8 9

Re: [44net] N1URO and traceroute. Was: Iperf server for public use
by Rob Janssen 26 Jul '15

26 Jul '15

> Subject: > Re: [44net] N1URO and traceroute. Was: Iperf server for public use > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 07/26/2015 05:06 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Sat, Jul 25, 2015 at 09:55:32PM -0500, Steve L wrote: >> >To traceroute over a tunnel, you may have to change the TTL to 64 like so: > Strange advice, considering how traceroute works, which is to send packets > with very low TTLs (starting with a TTL of 1 and working up to 30 in most > implementations). If it really makes a difference to set the tunnel TTL > to 64 in order to get traceroute to work, something very strange is going on. The problem is that the default setting of the ipip tunnel in Linux is to copy the TTL of the packet being encapsulated into the outer IP header. When you traceroute, the packet sent to the public IP of the tunnel endpoint will have the low TTL that traceroute is using, and so that packet will not make it to the destination over the internet until that TTL is sufficiently high, can be something like 10-15 these days. So you will see many lines of * * * before finally something comes back, and often you will have interrupted the traceroute by then. When the fixed TTL of 64 is set as shown with ip tunnel change ttl 64 ..., the encapulation will put a fixed TTL of 64 in the outer IP header, so it makes it through the other end of the IP tunnel in one traceroute hop, and you can traceroute without problem. Of course you cannot see the hops the encapsulated packet takes over the internet, but with a standard traceroute you cannot see those anyway. For normal traffic there is no difference, as long as sufficient TTL remains in the inner IP packet at the moment it is copied to the outer header for that packet to make it over the internet. So when the source sets a TTL of 64 or 255, it will be fine. Rob

1 0

Re: [44net] N1URO and traceroute. Was: Iperf server for public use
by Steve L 26 Jul '15

26 Jul '15

Brian, The TTL thing is really just a bad setup on our part. From what I understand when you create a ipip tunnel in Linux in inherits the TTL of 0 if you haven't set it when you bring up the interface. So without making adjustments to the TTL, you won't get responses from your amprnet-hops. As for why Corey can't ping Brian N1URO I assume it's because Brian uses a munge script and maybe doesn't have a private tunnel route to Corey. I know both n1uro.ampr.org and n3fe.ampr.org are both reachable one of two ways. By private tunnel and/or thru UCSD. So there is plenty of room for a routing headache. :-)

1 0

Re: [44net] Iperf server for public use
by Rob Janssen 26 Jul '15

26 Jul '15

> Subject: > Re: [44net] Iperf server for public use > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 07/24/2015 09:44 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I have a BGP feed and the IPIP mesh (loaded from API). > > These are the relevant routing entries for 44.137.40.2. > > # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > 0 ADb 0.0.0.0/0 46.29.abc.xyz 250 > 1 A S 44.137.0.0/16 ampr-213.222.de... 210 > 2 Db 44.137.0.0/16 46.29.abc.xyz 250 > 3 A S 44.137.40.2/32 ampr-89.18.def.ghi 210 > > Rule #0 and #2 are BGP routes, rule #1 and #3 are static rules added via script parsing API output. > > As you can see I prefer IPIP routes over BGP. > > Traceroute looks fine: > > marconi:~# traceroute -I 44.137.40.2 > traceroute to 44.137.40.2 (44.137.40.2), 30 hops max, 60 byte packets > 1 lx0bgp-18.ampr.org (44.161.204.1) 0.390 ms 0.493 ms 0.652 ms > 2 tunnels.lx0bgp.ampr.org (44.161.230.255) 7.681 ms 7.743 ms 7.878 ms > 3 sys2.pe1chl.ampr.org (44.137.40.2) 24.655 ms 24.666 ms 25.041 ms > > 73 de Marc, LX1DUC > Hi Marc, I can ping you OK from both systems. What you tried above is via tunnel, and e.g. to 44.137.0.1 can be via BGP or Tunnel. Both will work. But when I ping Brian N1URO from 44.137.0.1 I see the outgoing traffic via tunnel and I never see a reply coming back. No idea what is wrong. It cannot be a firewall at my end because I would see the reply when tracing (tshark operates before the filter). Interesting is that he can ping me. And I can communicate with many systems, both those that use tunnels and those that have direct BGP routing. No idea where the issue is. Rob

3 4

Re: [44net] Iperf server - kk7kx
by Rob Janssen 25 Jul '15

25 Jul '15

> Subject: > [44net] Iperf server - kk7kx > From: > "Assi Friedman" <assi(a)kiloxray.com> > Date: > 07/25/2015 05:56 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Folks: > I think the direct routes to the various AMPRNet nodes are up and running. > Iperf is running: > TCP: iperf -c kk7kx.ampr.org -p 7000 > UDP: iperf -c kk7kx.ampr.org -p 7000 -u > Ping and MTR should also respond. > I do however seem to have an issue with the web page. Does > http://kk7kx.ampr.org respond from the AMPRNet? > Thanks, > Assi > I think there still are issues. How do you route 44.137.0.0/16 ? I can now run the iperf from 44.137.0.1 but not from 44.137.41.97 Same for the webpage. Rob ------------------------------------------------------------ Client connecting to kk7kx.ampr.org, TCP port 7000 TCP window size: 256 KByte (default) ------------------------------------------------------------ [ 3] local 44.137.0.1 port 57548 connected with 44.8.0.160 port 7000 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 6.50 MBytes 5.36 Mbits/sec ------------------------------------------------------------ Client connecting to kk7kx.ampr.org, UDP port 7000 Sending 1470 byte datagrams UDP buffer size: 256 KByte (default) ------------------------------------------------------------ [ 3] local 44.137.0.1 port 54929 connected with 44.8.0.160 port 7000 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec [ 3] Sent 893 datagrams [ 3] Server Report: [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.242 ms 0/ 893 (0%)

2 1

Iperf server - kk7kx
by Assi Friedman 25 Jul '15

25 Jul '15

Folks: I think the direct routes to the various AMPRNet nodes are up and running. Iperf is running: TCP: iperf -c kk7kx.ampr.org -p 7000 UDP: iperf -c kk7kx.ampr.org -p 7000 -u Ping and MTR should also respond. I do however seem to have an issue with the web page. Does http://kk7kx.ampr.org respond from the AMPRNet? Thanks, Assi

3 2

Re: [44net] Iperf server for public use
by Rob Janssen 24 Jul '15

24 Jul '15

> Subject: > Re: [44net] Iperf server for public use > From: > Brian <n1uro(a)n1uro.ampr.org> > Date: > 07/24/2015 02:46 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob; > > On Thu, 2015-07-23 at 22:46 +0200, Rob Janssen wrote: > >> >This means it failed! >> >And not from UDP either. I have the same result. It does not work. >> >Others who can reach kk7kx? >> > >> >Assi, what kind of return routes do you have? Do you route everything back via UCSD >> >or do you have a proper tunnel mesh? > I concur: > n1uro@n1uro:~$ iperf -c kk7kx.ampr.org -p 7000 > connect failed: Connection timed out Hi Brian, With your system I have a different issue... when I ping n1uro.ampr.org from 44.137.40.2 which has an IPIP tunnel on 89.18.172.156 I can ping you without problem, but when I ping from other addresses like 44.137.0.1 or 44.137.41.97 I get no reply. Those addresses are supposed to be handled via the tunnel for 44.137.0.0/16 which has external address 213.222.29.194 and is also registered in the portal. They are also reachable on the internet directly (BGP announced) What can be the problem? Did you add some handling of BGP routed subnets that now fails because of the dual connectivity we have? Or is it the issue that I hunted some time ago (and never really tracked down) where there appears to be systematic packet loss in RIP announcements that makes certain subnets disappear completely or make them flapping? (I tried to suppress that by increasing EXPTIME to 7200 in ampr-ripd.c) Rob

2 2

Re: [44net] Iperf server for public use
by Rob Janssen 24 Jul '15

24 Jul '15

> Subject: > Re: [44net] Iperf server for public use > From: > Andy Brittain <g0hxt(a)greatbrittain.co.uk> > Date: > 07/23/2015 07:39 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi Assi > > Results for UDP: > > ------------------------------------------------------------ > Client connecting to kk7kx.ampr.org, UDP port 7000 > Sending 1470 byte datagrams > UDP buffer size: 160 KByte (default) > ------------------------------------------------------------ > [ 3] local 44.131.243.3 port 35310 connected with 44.8.0.160 port 7000 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 8.00 GBytes 6.86 Gbits/sec > [ 3] Sent 893 datagrams > [ 3] WARNING: did not receive ack of last datagram after 10 tries. This means it failed! > For some reason that I cant work out I get no response from the TCP test. And not from UDP either. I have the same result. It does not work. Others who can reach kk7kx? Assi, what kind of return routes do you have? Do you route everything back via UCSD or do you have a proper tunnel mesh? Rob

8 8

Email updates to AMPR/Portal Access
by Jerry Kutche (N9LYA) 24 Jul '15

24 Jul '15

Hi, Anyone else having issues logging into the portal. I get a message I have to activate my email, so it sends me an email then I click link add my user name and I get .. Opps.. We have a problem, contacting webmaster.. Also if I send an email to the ampr system I get no replies, unless I intentionally send a non-plain text message.. then it replies I can only send plain text. No replies to plain text. I suspect both systems have forgotten me.. 73 Jerry N9LYA Indiana IP Coordinator..

3 2

Re: [44net] Iperf server for public use
by Steve L 23 Jul '15

23 Jul '15

>> Subject: >> [44net] Iperf server for public use >> From: >> "Assi Friedman" <assi at kiloxray.com> >> Date: >> 07/23/2015 05:50 PM >> >> To: >> "'AMPRNet working group'" <44net at hamradio.ucsd.edu> >> >> >> Folks: >> I'll leave the iperf server running on kk7kx.ampr.org for the benefit of the >> community. I combined both to operate on port 7000. To connect, use the >> following basic syntax: >> TCP: iperf -c kk7kx.ampr.org -p 7000 >> UDP: iperf -u -c kk7kx.ampr.org -p 7000 >> If you do use it, please be considerate. >> Thank you, >> Assi kk7kx/4x1kx >Still no connectivity whatsoever with your system.... >No ping, no tcp, no udp. >This is from 44.137.0.0/16. How do you route there? > >Rob I noticed that I can reach Assi's host from the general internet, but not from directly within the private tunnels. Steve

3 2

Iperf server for public use
by Assi Friedman 23 Jul '15

23 Jul '15

Folks: I'll leave the iperf server running on kk7kx.ampr.org for the benefit of the community. I combined both to operate on port 7000. To connect, use the following basic syntax: TCP: iperf -c kk7kx.ampr.org -p 7000 UDP: iperf -u -c kk7kx.ampr.org -p 7000 If you do use it, please be considerate. Thank you, Assi kk7kx/4x1kx -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Will Gwin Sent: Wednesday, July 22, 2015 10:43 PM To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Packet loss through UCSD? (Please trim inclusions from previous messages) _______________________________________________ On 7/22/15 10:27 PM, David Ranch wrote: > Linux's ipfwadm and ipchains were stateless "packet filters" but iptables has been fully stateful for many many years. We are now at the cusp of nftables on Linux which makes things even more programmable though I don't know about the performance. My mistake. It's been years since I was actively comparing the different fire-walling methods in use by Linux. I went hardware for years and only within the last few years went to software, when I went OpenBSD due to native IPsec support as well as pf. >> Filtering at a router is a sure fire way to bring throughput to a crawl. Proper campus routers are designed with ASICs optimized for routing in hardware, and fire-walling is done in software. > > Modern ASIC based firewalls can handle 100,000s of stateless filters on a per interface basis. Note I said 'router', not 'firewall'. Routers are designed from the silicon up to forward packets, reduce broadcast domains and connect networks. Firewalls are designed from the silicon up to restrict the flow of packets. Yes firewalls will forward packets from one network to another, but their primary purpose is inspection and restriction. >> I have seen enterprise small office routers handle 450~500mbps of straight routing but max out around 40mbps when fire-walling because it's CPU bound. The results are similar when stepping up to large chassis routers. > > It depends on the class of devices you're buying. There are many inexpensive Enterprise grade firewalls (always stateful) that can run many 100s of Megabit and a few thousand dollars will get you into the 10G+ range. Again, please note that I said 'router', not 'firewall'. As to the type of router I was referring to in that specific example was a Cisco enterprise branch router. Campus and data center grade routers do minimal traffic filtering if any due to the CPU hit they incur, hence why large hardware firewalls exist. Proper tool for the job. > Yeah.. but we don't need that throughput or scale. The current configuration was choking, hence the discussion. Brian has worked with CAIDA and resolved the congestion for now. >Just statelessly filtering at the border edge with a modern router would solve much of these issues. Please note that router and firewall are not the same thing. They can do the same job, but not as effectively as the device purpose built for the job. Also Brian already stated: > The port 'em0' is connected to a 1G switch which is in turn connected at 10GbE to the building infrastructure switch/router. and > to do so requires administrative access to the campus border router that we don't have. Fire-walling is done at the AMPR edge, but traffic was overwhelming the current configuration. Moving filtering to the provider router is technologically improper and operationally restricted, hence my suggestion to split filtering and tunneling onto separate machines to increase capacity. The suggestion Tom made of running an IGP to selectively advertise only subnets which have valid destinations via the tunnels would also restrict the amount of traffic that will ultimately be blocked from reaching the firewall. This type of routing combined with a large null route is a common practice in large enterprise networks. Reducing the amount of traffic that is going to get blocked from reaching the AMPR edge will help system load but won't help with the timeouts due to slow [or down] tunnel peers. As this thread has demonstrated, there are a few different ways to increase capacity of the AMPR gateway. While it may not be necessary at this time, it's still useful information to have for whoever is going to be responding next time there is an issue. -- Will _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

4 3

Portal API
by G1FEF 23 Jul '15

23 Jul '15

Portal API now back online Chris

1 0

Re: [44net] Iperf server for public use
by Assi Friedman 23 Jul '15

23 Jul '15

David: Let me see what I can do about that. While iperf doesn't support user end messages, I posted the basic info on http://kk7kx.ampr.org. Assi kk7kx/4x1kx PS: a week ago someone from the mailing list pinged me asking for contacts in the IARC. Please send me a note again to assi(a)kiloxray.com so I can forward it to the people I know. I should probably figure out how to check the archives on the mailman but I have been pretty busy to poke the system. -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of David Ranch Sent: Thursday, July 23, 2015 11:26 AM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Iperf server for public use (Please trim inclusions from previous messages) _______________________________________________ Hello Assi, > I'll leave the iperf server running on kk7kx.ampr.org for the benefit > of the community. I combined both to operate on port 7000. Thanks for doing this and I think this is a great way to not only validate connectivity but also performance. One issue here is what performance should people expect. I looked but it seems that Iperf doesn't support any sort of banner to tell people something like "Internet connection is 10Mb/s VHDSL@ MTU of 1480 - you should expect X throughput with a last hop latency of 23ms". Since that isn't supported (yet), can you tell us a little about your network connection and maybe we can get this captured into the AMPR portal. Would be very helpful! --David

2 1

Re: [44net] Iperf server for public use
by Rob Janssen 23 Jul '15

23 Jul '15

> Subject: > [44net] Iperf server for public use > From: > "Assi Friedman" <assi(a)kiloxray.com> > Date: > 07/23/2015 05:50 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Folks: > I'll leave the iperf server running on kk7kx.ampr.org for the benefit of the > community. I combined both to operate on port 7000. To connect, use the > following basic syntax: > TCP: iperf -c kk7kx.ampr.org -p 7000 > UDP: iperf -u -c kk7kx.ampr.org -p 7000 > If you do use it, please be considerate. > Thank you, > Assi kk7kx/4x1kx Still no connectivity whatsoever with your system.... No ping, no tcp, no udp. This is from 44.137.0.0/16. How do you route there? Rob

1 0

Re: [44net] iperf
by Steve L 22 Jul '15

22 Jul '15

I noticed the same thing, unable to reach kk7kx.ampr.org I am running iperf on the same ports (till my next reboot) on 44.92.21.35, which should be reachable both ways for anyone who cares to mess around. Note: the gateway this host is behind is a residential cable modem 15/1 Mbps, nothing impressive. ________________________________ >> Subject: >> Re: [44net] Packet loss through UCSD? >> From: >> Assi Friedman <assi at kiloxray.com> >> Date: >> 07/21/2015 06:28 AM >> >> To: >> AMPRNet working group <44net at hamradio.ucsd.edu> >> >> >> Oops, left out the host name: kk7kx.ampr.org >> TCP -> port 7000 >> UDP -> port 7001 >> Thanks, >> Assi >> kk7kx/4x1kx > >It does not reply at all, not even to ping. >The tunnel endpoint can be pinged.

1 0

Re: [44net] Packet loss through UCSD?
by Rob Janssen 21 Jul '15

21 Jul '15

> Subject: > Re: [44net] Packet loss through UCSD? > From: > Assi Friedman <assi(a)kiloxray.com> > Date: > 07/21/2015 06:28 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Oops, left out the host name: kk7kx.ampr.org > TCP -> port 7000 > UDP -> port 7001 > Thanks, > Assi > kk7kx/4x1kx It does not reply at all, not even to ping. The tunnel endpoint can be pinged. Rob

1 0

Re: [44net] Packet loss through UCSD?
by Assi Friedman 21 Jul '15

21 Jul '15

What is the AMPRGW machine based on? Assi -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Monday, July 20, 2015 10:32 PM To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Packet loss through UCSD? (Please trim inclusions from previous messages) _______________________________________________ > > On 2015-07-20 17:41, Assi Friedman wrote: > >> and rather poor packet loss. Are there any issues or QoS policies > >> implemented on the amprnet router at UCSD? There's no QoS policy in effect, but 'amprgw' is getting hammered at the moment, with inbound packet drops peaking in the 25% range so performance is going to be horrible. It's hard to see precisely what's happening but it looks like multiple hosts (possibly a botnet) are sweeping through the 44/8 range looking for something. There's not much we can do about this in the short term. Long term includes a higher-performance machine with faster network interfaces. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

3 3

Re: [44net] Packet loss through UCSD?
by Assi Friedman 21 Jul '15

21 Jul '15

Sounds like an excellent research topic for a UCSD summer intern. (Please trim inclusions from previous messages) _______________________________________________ It's hard to see precisely what's happening but it looks like multiple hosts (possibly a botnet) are sweeping through the 44/8 range looking for something.

2 1

Some hosts from net, rest masq'd?
by Rob Janssen 20 Jul '15

20 Jul '15

> Subject: > [44net] Some hosts from net, rest masq'd? > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 07/19/2015 09:29 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > I had a guy ask me who I don't think is on this list yet, if its > possible so have some 44 ips behind his gateway reachable from the > public net, and all the remaining to use masquerading rather than the > default 44/8 UCSD route. I told him I am sure it can be done. > > I am sure there is more than one way to do this. Here is what I came > up with, I mark the traffic type by matching source address (I am > using some hosts on my lan to test). Set a rule for that, and then > finally set a route based on that rule. I am doing that on my system as well, but rather than using a separate rule that is matched by the mark, I use the mark to enable the masquerade in POSTROUTING. (using a -m mark --mark 1 match) But of course it can be done either way. Rob

1 0

Some hosts from net, rest masq'd?
by Steve L 19 Jul '15

19 Jul '15

I had a guy ask me who I don't think is on this list yet, if its possible so have some 44 ips behind his gateway reachable from the public net, and all the remaining to use masquerading rather than the default 44/8 UCSD route. I told him I am sure it can be done. I am sure there is more than one way to do this. Here is what I came up with, I mark the traffic type by matching source address (I am using some hosts on my lan to test). Set a rule for that, and then finally set a route based on that rule. Here is what I have: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-n3fe I am not sure I am doing it right as the iptables marking and ip rules are a little greek to me. I am looking for input, suggestions etc. There may even be a much easier way that I haven't thought of. It seems to work, but I have said that before and turns out I was logged into something other than what I thought for testing. Seems a bit sluggish from the net though, but maybe there is just congestion right now. Thanks Steve, KB9MWR

1 0

Issues setting up tunnel gateway
by Chris S. Munz-Michielin 15 Jul '15

15 Jul '15

Hi everyone, I'm just starting to setup an AMPRNET node and am running into some difficulty setting up a Linux gateway using the rip44d daemon and was hoping someone has some pointers. I've been following this guide: http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example and start running into trouble once I try and get the rp daemon running. I've managed to download and extract the latest tar file from: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.13.tgz and it seems to compile and install fine. The next step, according to the guide, is to run ./find_pass.sh but when I do that I get the error: Tunnel socket: Setting SO_BINDTODEVICE: No such device I took a look at the contents of the find_pass.sh file and it seems to contain the command ./ampr-ripd -d -i ampr0 so I decided to run ./ampr-ripd -d -i eth0 from the command line and I get the message: Waiting for RIPv2 broadcasts... but it never prints out the "secret" password. I am running Debian Jessie as my OS and have registered a gateway on the ampr portal. Just wondering if there's something obvious I'm missing here? Cheers, Chris VE7ALB in Victoria BC||||

4 4

Re: [44net] What's a goot 44.x test peer
by Steve L 15 Jul '15

15 Jul '15

Assi, You can test against: 44.92.21.35 reachable both ways 44.92.21.50 reachable only from 44net Steve, KB9MWR

1 0

What's a goot 44.x test peer
by Assi Friedman 15 Jul '15

15 Jul '15

Folks: I am trying to bring my 44 host back online but am having some issues (not receiving IPIP traffic from mirrorshades.) What's a good 44 peer I can test traffic from Internet->44.x to and 44.x -> 44.x. Not planning on flooding, mostly pinging. Thanks, Assi (kk7kx.ampr.org)

3 2

Re: [44net] 44Net Digest, Vol 4, Issue 99
by Rod Ekholm 14 Jul '15

14 Jul '15

I would be interested in testing this as an endpoint. Let me know what you need from me, on or off the list! Thanks!! Rod Ekholm - KC7AAD Spokane, WA On Tue, Jul 14, 2015 at 12:00 PM, <44net-request(a)hamradio.ucsd.edu> wrote: > Send 44Net mailing list submissions to > 44net(a)hamradio.ucsd.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://hamradio.ucsd.edu/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)hamradio.ucsd.edu > > You can reach the person managing the list at > 44net-owner(a)hamradio.ucsd.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. BPQ and 44 IP's (William Lewis) > 2. Re: BPQ and 44 IP's (Don Poaps) > 3. Re: BPQ and 44 IP's (John Wiseman) > 4. Re: BPQ and 44 IP's (Demetre - SV1UY) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Jul 2015 20:27:34 -0700 > From: William Lewis <kg6baj(a)n1oes.org> > To: 44Net(a)hamradio.ucsd.edu > Subject: [44net] BPQ and 44 IP's > Message-ID: <6.0.0.22.2.20150713202554.01c5e1c8(a)mail.n1oes.org> > Content-Type: text/plain; charset="us-ascii"; Format="flowed" > > I'm hearing that the latest BPQ software can do 44.x.x.x IP Addressing? > > Can anyone confirm this? > > If so, I have a friend in Nevada that wants to set up his BPQ station to > link with me using our 44.x.x.x numbers. > > Thanks, > > > > ---------- > > This message is for the designated recipient only and MAY CONTAIN > PRIVILEGED OR CONFIDENTIAL INFORMATION. > If you have received it in error, please notify the sender immediately and > delete the original. > Any other use of this E-mail is prohibited. > > Wm Lewis >

1 0

BPQ and 44 IP's
by William Lewis 14 Jul '15

14 Jul '15

I'm hearing that the latest BPQ software can do 44.x.x.x IP Addressing? Can anyone confirm this? If so, I have a friend in Nevada that wants to set up his BPQ station to link with me using our 44.x.x.x numbers. Thanks, ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited. Wm Lewis

4 3

shorewall help ?
by Maiko Langelaar 12 Jul '15

12 Jul '15

Greetings, I've been forced to change my main router to shorewall (I can go another route, but right now I'm just evaluating the situation), and as a result I have lost a few things that I have become a bit too used to over the past few years. Like having a DMZ host direct to my JNOS and being able to pass ip-ip direct to it. I have not figured out how to dmz to my jnos (2 ports on the shorewall, not 3) yet or how to pass ipip through ... Anyone on the list done this already ? I would appreciate some working examples, thank you. Maiko Langelaar / VE4KLM

2 1

Re: [44net] ampr.org mail
by William Lewis 11 Jul '15

11 Jul '15

21st Century and SMTP ?? Pretty wrong, so I think you don't know anything about H-Addressing. First off, SMTP (email) is just like someones home phone number. If you dial the wrong phone number, you either get the wrong house, or you get none at all. Same with email. If you don't have the 100% correct email address, the message doesn't get through at all, or winds up in the wrong persons in-box. With H-Addressing, YOU DON'T HAVE TO KNOW THE EXACT ADDRESS! That's one of the many beautiful things about packet messaging forwarding. Let me explain.... My packet address looks like this KG6BAJ(a)KG6BAJ.#NCA.CA.USA.NOAM. The ".#NCA.CA.USA.NOAM" is the Hierarchical part of the address. The ".#NCA"denotes SUBSECTION of the state (in this case Northern CAlifornia), then the state "CAlifornia (.CA)", then the Country (.USA), then the continent of North America (.NOAM). With HAddressing, Someone really doesn't need to know the precise address like you do with phone & email (The SMTP you refer too). Someone wants to send me packet mail, they really only need just a part of my address, which they could guess by running my callsign through something like QRZ. Someone could send me a packet mail addressed to "KG6BAJ@.#USA.NOAM" (notice the huge difference from KG6BAJ(a)KG6BAJ.#NCA.CA.USA.NOAM). Properly configured NOS/FBB/Misc full service BBS's then can at least determine that the message is intended for USA, in North America, and forward the message along. Since my BBS is in fact located within USA, in North America, then I'll get the message, and drop it in the correct mailbox. Try doing that with an SMTP (email) message. Just won't work. To those who don't fully understand the brilliants of Hierarchical I suppose it would seem antiquated. But nothing else gets that message through like packet radio and H-Addressing. And one another note, you state all NOS stations run SMTP. Also not true. It depends on if the sysop has built it in at time of compiling it features. And..... not all Full-Service BBS's run NOS. Bill Lewis, KG6BAJ At 05:51 PM 7/10/2015, you wrote: >Jerry, Are you talking about the BBS Hierarchical Addressing Protocol that >is common with people running NOS BBS'es? >ftp://ftp.tapr.org/bbssig/recommendations/hierarchical >In all honesty from what I remember it's a lot of manual configuration, >that really seems quaint to me since all the NOS programs also speak SMTP, >the standard today. > >It would seem the same could be accomplished using SMTP standards by >setting up some mail aliases. I'm going to recommend the TAPR NOS-BBS list >for (Hierarchical forwarding) things of the non 21st century:

4 4

Re: [44net] ampr.org mail
by Steve L 11 Jul '15

11 Jul '15

Jerry, Are you talking about the BBS Hierarchical Addressing Protocol that is common with people running NOS BBS'es? ftp://ftp.tapr.org/bbssig/recommendations/hierarchical In all honesty from what I remember it's a lot of manual configuration, that really seems quaint to me since all the NOS programs also speak SMTP, the standard today. It would seem the same could be accomplished using SMTP standards by setting up some mail aliases. I'm going to recommend the TAPR NOS-BBS list for (Hierarchical forwarding) things of the non 21st century: https://www.tapr.org/mailman/listinfo/nos-bbs ---- Quote ---- Is there anything written on the operation of amper.org mail forwarding? We routinely run h-address packet mail forwarding and I see some ampr.org mail bulletins coming in from all over the world. I’m interested in the addressing, routing, and just how does this mail forward. I run Ubuntu Linux JNOS latest version. Jerry, N0MR

1 0

ampr.org mail
by Lakenet 10 Jul '15

10 Jul '15

Is there anything written on the operation of amper.org mail forwarding? We routinely run h-address packet mail forwarding and I see some ampr.org mail bulletins coming in from all over the world. I’m interested in the addressing, routing, and just how does this mail forward. I run Ubuntu Linux JNOS latest version. Jerry, N0MR

1 0

Is the Portal down
by William Lewis 07 Jul '15

07 Jul '15

I can't seem to get a response from the portal? Anyone else having issues? Been this way for over 24 hours. Bill KG6BAJ

6 6

Re: [44net] Is the Portal down - loss of communications
by Assi Friedman 07 Jul '15

07 Jul '15

"Loss of communications can only mean one thing... INVASION." Sorry guys, someone had to say it ;-) Assi kk7kx -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Paul Lewis Sent: Tuesday, July 07, 2015 9:11 AM To: AMPRNet working group Subject: Re: [44net] Is the Portal down (Please trim inclusions from previous messages) _______________________________________________ Hi Brian Thanks for the confirmation that the services are down. 73 de Paul G4APL GB7CIP -- paul(a)skywaves.demon.co.uk _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Gateway filtering?
by Steve L 04 Jul '15

04 Jul '15

Thanks Rob, your message was helpful. It gives me some good ideas and a place to start. 73 Steve, KB9MWR

1 0

Gateway filtering?
by Rob Janssen 04 Jul '15

04 Jul '15

> Subject: > [44net] Gateway filtering? > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 07/03/2015 09:05 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > A few hosts behind my gateway want to accept general inbound internet > connections. > > As discussed earlier there is a lot of crap and the gateway I run is > off a residential internet connection. Combine that with some limited > bandwidth radio links. > > I have been thinking about applying some IP blacklists using the ipset tool. > > ex:https://github.com/trick77/ipset-blacklist > > I am not super savvy on the more advanced functions of tcpip in the > Linux networking stack. > > Since those in all the inbound packets from the internet are > encapsulated at UCSD, how can I apply blacklisting? Can I apply them > to the eth1 (wireless lan) output interface somehow? > > Examples are especially helpful. > > Thanks > > Steve, kb9mwr > I use this a lot in the Dutch gateway. First, I have an ipset that is loaded with the list of allocated addresses within 44.137.0.0/16. You don't need to do that when you are behind the UCSD gateway, but we have a BGP-advertised /16 so we get a lot of crap for addresses that are not allocated. Then, there is an ipset that is loaded with addresses of persistent abusers like shodan.io. Finally, I have an ipset with those addresses for which the user has indicated that they want to receive inbound connections from outside 44.0.0.0/8. This works in combination with an iptables -m state --state ESTABLISHED,RELATED entry that passes the traffic related to outgoing connections. As a lot of hams are not interested in providing connectivity to the large internet, this filter removes a lot of incoming traffic that would otherwise be blocked further down the path. (at their incoming firewall) The use of these ipset filters in the firewall is quite simple: # Drop traffic from abusers $ipt -A amprifwd -m set --match-set Hackers src -j DROP # Drop traffic for addresses not registered in DNS $ipt -A amprifwd -m set ! --match-set PAnet dst -j DROP # Allow related traffic $ipt -A amprifwd -m state --state ESTABLISHED,RELATED -j ACCEPT # Drop traffic to stations that don't want incoming from internet to HAMnet $ipt -A amprifwd ! -s 44.0.0.0/8 -m set ! --match-set HAMnet dst -j DROP # Drop invalid traffic (not related to existing connections) except TCP close-down traffic $ipt -A amprifwd -p tcp --tcp-flags ACK,FIN ACK,FIN -j ACCEPT $ipt -A amprifwd -p tcp --tcp-flags RST RST -j ACCEPT $ipt -A amprifwd -m state --state INVALID -j DROP # Accept remaining traffic $ipt -A amprifwd -j ACCEPT Of course you need to apply this filter to the FORWARD chain for traffic incoming on your tunnel interface and being forwarded to your radio interface. You can write such a filter (without the ESTABLISHED,RELATED part) for traffic forwarded outbound as well. E.g. to block traffic from nonregistered addresses. When loading the ipsets, it is important to note that you cannot delete a set that is in use in iptables. So I use this method (in a script that reloads the sets e.g. after an address update): ipset create HAMnet bitmap:ip range 44.137.0.0/16 2>/dev/null ipset create HAMnet_new bitmap:ip range 44.137.0.0/16 ipset flush HAMnet_new grep '^44\.137\.' hamnet | cut -f1 | while read ip do ipset add HAMnet_new $ip || echo "Failed to insert $ip in HAMnet_new" done ipset swap HAMnet_new HAMnet ipset destroy HAMnet_new 2>/dev/null This creates a new set, loads it with the data, then swaps it with the currently used set and destroys that one. This operation is allowed while the set is in use, and of course is preferred over just flushing the set and loading it, as during that brief time the filter could drop traffic. Rob

1 0

Gateway filtering?
by Steve L 03 Jul '15

03 Jul '15

A few hosts behind my gateway want to accept general inbound internet connections. As discussed earlier there is a lot of crap and the gateway I run is off a residential internet connection. Combine that with some limited bandwidth radio links. I have been thinking about applying some IP blacklists using the ipset tool. ex: https://github.com/trick77/ipset-blacklist I am not super savvy on the more advanced functions of tcpip in the Linux networking stack. Since those in all the inbound packets from the internet are encapsulated at UCSD, how can I apply blacklisting? Can I apply them to the eth1 (wireless lan) output interface somehow? Examples are especially helpful. Thanks Steve, kb9mwr

1 0

Not able to fill subnet IP
by Libor Berka 29 Jun '15

29 Jun '15

I am trying to register amprnet gate at IP 147.229.242.130 (ok0nmg.ddns.net) at portal.ampr.org but there is no offer to put a subnet (here 44.177.10.254/32). I ahve already registered 2 gateways before succesfully with their subnets but this a/m one its not possible to put a subnet. (The ampr-ripd system is running well on ok0nmg.ddns.net.) I need some help please. Best 73 Libor OK2PEN (PY2ZEN) sysop of gates ok2koj.ampr.org, ok2pen.ampr.org and ok0nmg.ampr.org

2 1

Test New Tool - APRS Code Recovery
by lleachii＠aol.com 24 Jun '15

24 Jun '15

All, I've added a new tool that I'd like you to test. This web application should provide the registration code required by APRS software suites. In order to use it, you must browse to: http://kb3vwg-010.ampr.org/tools/aprscode or http://44.60.44.10/tools/aprscode If you're on AMPRNet, you should be able to enter the callsign and look up the registration code. If you access it from outside of AMPRNet, you will be prompted for an access code (1234). Please let me know how it works 73, KB3VWG

39 87

Re: [44net] attacks on 44 net !
by Gustavo Ponza 24 Jun '15

24 Jun '15

> Hi Maiko and all, > > since from three or more years I'm visited from many > attackers which I mainly identified as government agencies > and/or research/industrial groups... just note the inbound and > the outbound traffic below. > A very big attack at 23.30 - 00.30 is shown > > gus i0ojj > > > ----------------- ***Image 'attacks.png' deleted*** The tonight visitor(s) was the following: org. 128054 IN NS b2.org.afilias-nst.org. org. 128054 IN NS b0.org.afilias-nst.org. org. 128054 IN NS c0.org.afilias-nst.info. org. 128054 IN NS d0.org.afilias-nst.org. org. 128054 IN NS a2.org.afilias-nst.info. org. 128054 IN NS a0.org.afilias-nst.info. a0.org.afilias-nst.info. 128054 IN A 199.19.56.1 a0.org.afilias-nst.info. 128054 IN {28} a2.org.afilias-nst.info. 128054 IN A 199.249.112.1 a2.org.afilias-nst.info. 128054 IN {28} b0.org.afilias-nst.org. 128054 IN A 199.19.54.1 b0.org.afilias-nst.org. 128054 IN {28} b2.org.afilias-nst.org. 128054 IN A 199.249.120.1 b2.org.afilias-nst.org. 128054 IN {28} c0.org.afilias-nst.info. 128054 IN A 199.19.53.1 c0.org.afilias-nst.info. 128054 IN {28} d0.org.afilias-nst.org. 128054 IN A 199.19.57.1 d0.org.afilias-nst.org. 128054 IN {28} ---------------- ... and in the past few days as below: ---------------- www.google.it. 0 IN A 74.125.206.94 . 93348 IN NS b.root-servers.net. . 93348 IN NS j.root-servers.net. . 93348 IN NS i.root-servers.net. . 93348 IN NS e.root-servers.net. . 93348 IN NS k.root-servers.net. . 93348 IN NS m.root-servers.net. . 93348 IN NS d.root-servers.net. . 93348 IN NS c.root-servers.net. . 93348 IN NS g.root-servers.net. . 93348 IN NS f.root-servers.net. . 93348 IN NS a.root-servers.net. . 93348 IN NS l.root-servers.net. . 93348 IN NS h.root-servers.net. dnsscan.shadowserver.org. 0 IN A 184.105.143.133 satellite.cs.washington.edu. 41243 IN A 198.48.92.101 satellite.cs.washington.edu. 41243 IN A 198.48.92.103 satellite.cs.washington.edu. 41243 IN A 198.48.92.102 satellite.cs.washington.edu. 41243 IN A 198.48.92.104 cs.washington.edu. 0 IN A 128.208.3.200 www.google.com. 0 IN A 64.233.184.103 www.google.com. 0 IN A 64.233.184.106 www.google.com. 0 IN A 64.233.184.105 www.google.com. 0 IN A 64.233.184.99 www.google.com. 0 IN A 64.233.184.104 www.google.com. 0 IN A 64.233.184.147 a.root-servers.net. 473340 IN A 198.41.0.4 b.root-servers.net. 473340 IN A 192.228.79.201 c.root-servers.net. 473340 IN A 192.33.4.12 defcon.org. 197093 IN SOA dns-1.datamerica.com. hostmaster.defcon.org. 2015051025 43200 600 86400 86400 defcon.org. 197093 IN TXT =v=spf1 defcon.org. 197093 IN MX 10 mail-1.datamerica.com. defcon.org. 197093 IN A 162.222.171.206 ----------------------

1 0

Power outage
by Jerry Kutche 22 Jun '15

22 Jun '15

Today's power outage seems to have left my net 44 link DOA... If so I wanted everyone to know I may be back.. No time to fix right now.. Just spent over a week getting everything working after a virus attack. And was not really done still had two systems down.. Now I have this.. I need a break, also.. May pick this back up in July... May not. Anyone linked to me I will be back eventually.. Maybe Maybe not. But now I have to figure out a few things. Why does my Pi lose all its free space within 30 minutes of boot up. Went from 73% to 100% cannot connect to it without rebooting over and over... So until I feel like being a slave to linux and the PI I am off line. 73 Jerry N9LYA

6 8

K3MMB
by Brian 21 Jun '15

21 Jun '15

Does anyone know the status of K3MMB? His system appears to be offline and has been for a couple weeks or so. -- A computer once beat me at chess, but it was no match against me in kick-boxing - Emo Phillips 73 de Brian Rogers - 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] portal purge
by Rob Janssen 21 Jun '15

21 Jun '15

> Subject: > Re: [44net] portal purge > From: > Don Fanning <don(a)00100100.net> > Date: > 06/20/2015 01:40 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > There is so much cruft in the DNS tables > that I imported the information into a database and ran the FCC > database against it. There were roughly 1800 entries out of 3700-ish > that matched expired/cancelled/revoked callsigns. And that's just for > the US alone - not including active licensees who just lost interest > in 44net. As BrianK would point out, there is no way that the DNS > table should be this big. I do regular checks of the registered addresses in the 44.137.0.0/16 subnet against the list of callsigns published by our local authority. I also delete registrations when "silent key" announcements appear in the club magazine. And a few weeks ago I deleted all dangling MX and CNAME records, most of them for US hams. (see discussion on the list) It appears to have been standard practice to create MX records for new registered addresses, and to not delete them when addresses are deleted. Do you have valid "callsign change" tables in the US? A problem for me is that there is no official information on that from our authority, apparently for privacy reasons. So sometimes I delete an address because the callsign is no longer valid, to find later that the operator has changed to a higher license class or vanity callsign. And not everyone changing their callsign notifies me. Rob

4 5

Re: [44net] Model gateway system
by Rob Janssen 20 Jun '15

20 Jun '15

> Subject: > Re: [44net] Model gateway system > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 06/19/2015 10:06 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > IPIP gateways should not use amprgw default route. > Ex: ip route add default dev tunl0 via 169.228.66.251 onlink .... That is incorrect. Such a route is OK as long as it is in an alternative routing table for AMPRnet traffic. It can be to amprgw or to a more local gateway. Such a route is required when you are on a source-address filtered internet connection and want to be reachable on your AMPRnet address from other internet systems. Rob

1 0

Model gateway system
by Michael E Fox (N6MEF) 20 Jun '15

20 Jun '15

So is the architectural debate over, or are people just tired of arguing? Frankly, there's been so much back and forth that I don't know what's expected any more. As I understand it, some nodes are on the IPIP mesh, some not. Some are reachable through amprgw, some not. What a mess. If the debate is over and there is consensus on a standard gateway architecture, then someone needs to publish it. I'm thinking the design should include a diagram of how to address the interfaces (which tunnels need AMPR addresses, which don't), where NATing occurs, what the ampr routing table should look like, what the ip rules should look like, etc. Otherwise, I guess it's up to each individual person to parse through the last 100 or so emails to figure out what they're going to do. Maybe I'll find time to do that . Someday. And folks wonder why there's not more participation . Michael N6MEF

3 2

portal purge
by Brian Kantor 20 Jun '15

20 Jun '15

At my request, we're cleaning out obsolete entries from the portal. A reminder is sent after 3 and 6 months with no login. A warning is sent after 9 months with no login. A notice is sent after 12 months with no login. After 15 months, the user, their network allocations, and any gateways belonging to them are deleted. At the current time, there are 3 gateways and 70 allocations to be so deleted. - Brian

8 20

Re: [44net] Model gateway system
by Steve L 19 Jun '15

19 Jun '15

IPIP gateways should not use amprgw default route. Ex: ip route add default dev tunl0 via 169.228.66.251 onlink .... IPIP gateways and the Wireless LAN's behind them will then be able to reach the BGP'd portions. I think that only leaves this scenario: BPG gateways and the wireless LAN's behind them will not be able to reach IPIP gateways and the LAN's behind them, as UCSD can't get a reply back to them. >From what I gathered Brian is seeking to hand off IPIP gateway destined traffic an intermediary ISP to fix this. Again from what I understand. The problem stems from a routing loop in the architecture at UCSD, when traffic leaves amprgw destine for a BGP'd chunk of the network. Others can correct me if I am wrong. Steve, KB9MWR ---- Quote ---- So is the architectural debate over, or are people just tired of arguing? Frankly, there's been so much back and forth that I don't know what's expected any more. As I understand it, some nodes are on the IPIP mesh, some not. Some are reachable through amprgw, some not. What a mess. If the debate is over and there is consensus on a standard gateway architecture, then someone needs to publish it. I'm thinking the design should include a diagram of how to address the interfaces (which tunnels need AMPR addresses, which don't), where NATing occurs, what the ampr routing table should look like, what the ip rules should look like, etc. Otherwise, I guess it's up to each individual person to parse through the last 100 or so emails to figure out what they're going to do. Maybe I'll find time to do that . Someday. And folks wonder why there's not more participation . Michael N6MEF

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 19 Jun '15

19 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > "Cory (NQ1E)" <cory(a)nq1e.hm> > Date: > 06/18/2015 11:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Bingo!!! There's the use-case I was missing in my head: > YourGWHost(Forcing44SourceIP) -> OtherIPIPLANs That is right! Note that this config was constructed for an all-in-one system that functions as the IPIP tunnel host, as a host for running services on AMPRnet (potentially reachable from all internet addresses), as a host to make outgoing connections to other amprnet systems, and as a general work machine for the owner (to browse, mail etc). The same browser session would automatically use the tunnels to reach other systems on AMPRnet, but it would use the direct path via the ISP for google and youtube. > The correct way to do that is obviously to tell the program you're using > that you want to bind to the specific 44 network interface. Forcing it to > happen for all traffic with a 44/8 destination is an easy workaround to > make that work, but as you can see it can have unintended consequences. Unfortunately this is not really practical. Sure you can set the source address on many common commandline utilities (like ping, telnet, traceroute, ftp) but not on many other networking programs like web browsers. Even an amateur radio oriented program like the Echolink client I use (QTEL) cannot set the source address. I made a request for enhancement for it, but that kind of thing had better be handled in a universal way. > > My recommended solution for those who want to be able to connect to as many > 44 nets as possible is: > Remove the 'to 44/8' rule and if you want to talk to a 44 host from a 44 > IP, use a host behind your gateway, not the gateway host itself. I have more or less done that already, as I now have a separate router between the host and the network, but even that does not solve this problem when that host again has to be on both networks. My main PC now has 2 addresses (each on a VLAN) to talk to the outside world, one is used (via NAT) to talk to internet, the other is 44.137.41.97 and is used when talking amprnet. But of course both can in fact communicate to any address, the decision which one to use is always a bit tricky. So my rule still is that "all traffic from my own subnet to anywhere, and all traffic from my hist to 44.0.0.0/8" is using the amprnet and goes out from 44.137.41.97 and without NAT, all other traffic is using the ISP internet and is NATted by the router. And again I have those "ip rules" in my system to achieve that: 0: from all lookup local 1: from all to 44.137.41.96/28 lookup main 44: from 44.137.41.96/28 lookup amprnet 44: from all to 44.0.0.0/8 lookup amprnet 32766: from all lookup main 32767: from all lookup default I am open to better solutions, as long as they are not "make sure that every program you use can bind an explicit local address". Of course now that I am behind a router the immediate problem of sending tunnel traffic to net-44 endpoints is no longer there, also because I am no longer directly on IPIP but only via our gateway, but still this source address selection issue remains. It may be that a suggestion I received from Jann can fully remedy the problem at least on a dedicated router/gateway. His approach is to make an unconditional rule that first sends the outgoing traffic through a table with only the IPIP tunnels. When that matches, the system will of course set the 44.x.x.x source address. Then, a rule follows that matches on "from 44.137.41.96/28" and refers to a table with only a default route pointing to the gateway (UCSD or another) that will forward the outside-44 traffic back to internet. Then finally everything else is looked up in the main routing table which has the default route going out via the ISP. I have not tested yet how well that works in practice. As mentioned, I no longer have the setup running that this config was originally created for. But it looks good. Rob

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Steve L 19 Jun '15

19 Jun '15

I am in the same boat as Bob. Home connection with limited inbound speed. So the DNS filtering is nice. It also lets my wireless LAN end users easily decide if they want inbound internet connectivity or not (when that portion of the portal gets done) without having to get a hold of me to set a firewall rule for them. I also like the idea of other VPN technologies being an option. One being stateful for those in uncool firewall situations . Sometime back I though maybe one day there would be multiple regional portals (connected with BGP and all running the open portal code/web interface) where end gateways could connect using a couple different vpn technologies. I understand the problem at hand with the fragmentation between the BGP vs IPIP segments. Or I think I do, from my end I know hamwan is BGP connected and have problems reaching it: I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if the 44 address you are trying to reach isn't in the RIP list, like hamwan is, it defaults to route it to UCSD. That doesn't work for me, as you will see below. But when I override that, and tell it to go out eth0 like all non 44net traffic it then works. Or is there something special I can do in my configs to fix this? root@44.92.21.1:~# ip route show table 44 | grep 44.24 44.24.0.0/20 via 66.114.139.158 dev tunl0 proto 44 onlink window 840 44.24.10.0/24 via 192.231.186.20 dev tunl0 proto 44 onlink window 840 44.24.192.0/24 via 38.104.126.22 dev tunl0 proto 44 onlink window 840 44.24.194.0/24 via 216.161.250.189 dev tunl0 proto 44 onlink window 840 44.24.196.0/24 via 24.113.42.14 dev tunl0 proto 44 onlink window 840 root@44.92.21.35:~# ping hamwan.org PING hamwan.org (44.24.241.98) 56(84) bytes of data. >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=2 Time to live exceeded >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=3 Time to live exceeded ^C --- hamwan.org ping statistics --- 6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5002ms root@44.92.21.35:~# ping hambook.de.ampr.org PING hambook.de.ampr.org (44.225.56.138) 56(84) bytes of data. 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=1 ttl=55 time=189 ms 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=2 ttl=55 time=175 ms ^C --- hambook.de.ampr.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 175.383/182.595/189.808/7.225 ms ---- Quote ---- I appreciate especially the filtering out of 44 addresses who are not in the dns by ucsd. I hate to loose that when it goes to another ISP. I remember well the days when that extra garbage was not filtered out and I will hate it when that is lost. My gateway is presently just at a home connection with a static ip. I object when that stuff is moved and no filtering will be in place whatsoever. With other words: UCSD is working fine. So why is it that those BGP subnets have no mandatory IPIP entries in the list also? They don't have to route back over IPIP, only need to receive IPIP. Easy solution, nothing drastic, KISS, and done in no time.. Bob VE3TOK

10 18

(no subject)
by Steve L 19 Jun '15

19 Jun '15

That occurred to me after I sent my last message. Part of my startup script included this default route: ip rule add to 44.0.0.0/8 table 44 priority 44 So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13 If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me. Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr ---- Quote ---- NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS. Marius, YO2LOJ

4 10

Re; (no subject)
by Steve L 19 Jun '15

19 Jun '15

Managed to fix this on my own. Had to add a masquerad rule When I removed: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 I had to add this to allow eth1 (my wireless LAN) to get anywhere: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Thanks again ---------- Forwarded message ---------- From: Steve L <kb9mwr(a)gmail.com> Date: Thu, Jun 18, 2015 at 7:36 PM Subject: Re; (no subject) To: "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> Marius, I was to hasty in saying removing this line fixed everything. I forgot to test from a remote host on my wireless LAN, I got a message from one of my LAN users that this broke things. Although I am at a loss as to why. It broke all remote connectivity. Works from the gateway itself, but all remote traceroutes stop when they reach my gateway, Steve ---- Quote ---- The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks. Marius

1 0

Re; (no subject)
by Steve L 19 Jun '15

19 Jun '15

Marius, I was to hasty in saying removing this line fixed everything. I forgot to test from a remote host on my wireless LAN, I got a message from one of my LAN users that this broke things. Although I am at a loss as to why. It broke all remote connectivity. Works from the gateway itself, but all remote traceroutes stop when they reach my gateway, Steve ---- Quote ---- The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks. Marius

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 18 Jun '15

18 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > "Cory (NQ1E)" <cory(a)nq1e.hm> > Date: > 06/17/2015 11:02 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, Jun 17, 2015 at 1:17 PM, Marius Petrescu<marius(a)yo2loj.ro> wrote: > >> > >> >NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T >> >WORK AND IS POINTLESS. >> > > Whoa... no need to yell:) Indeed... I was never talking about a 44/8 route, it is a 0.0.0.0/0 route. > > I'm finally taking a look at the wiki doc he referred to: > http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example > > It does mention creating a new routing table with the default route (0/0, > not 44/8) pointed at the UCSD gateway. This makes sense as you may want to > generate packets with a 44 source and a non-44 destination on the > internet. The gateway will forward those correctly. That is why it is there! it is required for IPIP gateways on a source address filtered connection. > it would also do it > for non-tunneled 44 nets if we didn't have the upstream routing issue at > UCSD that started this thread. > > The problem seems to be with the traffic that gets flagged to use the > alternate routing table: > > ## Configure Policy Based routing > # Packets to 44/8 network use routing table 44 > ip rule add to 44.0.0.0/8 table 44 priority 44 > > # Packets from our 44 subnet use table 44 (put your AMPRNet Subnet here) > ip rule add from 44.128.10.0/24 table 44 priority 45 > > The second ip rule makes sense to me. You want all packets sourced from > your 44 net to use the alternate routing table so they can egress through > UCSD and keep their source IP without NAT. However, the first ip rule (all > packets with 44 destinations) seems unneeded and troublesome. Packets that > aren't sourced from your own 44 net, but happen to have a 44 destinations > shouldn't be forced to use your tunnel. The reason that it is there: when you make an outgoing connect from a socket that is not bound to a specific address, the kernel will decide on the local address based on the route. When you do nothing, traffic to 44.0.0.0/8 will be routed to your normal default route to your ISP, and the source address will be your public IP. The traffic will be routed "outside" via UCSD or a BGP-announcing gateway. Of course you want to make such connections via a tunnel, so there is the first rule that will match the 44.0.0.0/8 destinations, select table 44, and find the tunnel routes there. Then, your 44.x.x.x source address will be selected. Rob

2 1

Re: [44net] portal purge
by clark edwards 18 Jun '15

18 Jun '15

Kml £ On Jun 18, 2015 1:25 PM, Brian Kantor <Brian(a)ucsd.edu> wrote: (Please trim inclusions from previous messages) _______________________________________________ On Thu, Jun 18, 2015 at 10:14:00AM -0700, Tom Hayward wrote: > Which ICANN requirement is this? I'm only familiar with WDRP, which is > a requirement for registrars to maintain ICANN accreditation. I don't > think AMPR is a registrar or ICANN accredited, so I must be totally > out of context. ARIN requires that I verify my contact info once a year; they say it's a requirement placed on them by ICANN. > Also, how do I connect to the AMPR WHOIS server to read this information? The whois server is under development and not yet deployed. I'm not up on the progress of that project. The intent was to have it run on the portal, where the registration database is operated so that it can have access to the necessary data. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] (no subject)
by Steve L 18 Jun '15

18 Jun '15

Marius, Thanks for the explanation, it helped clear up quite a few things I wasn't clear on. And yes after I removed the line: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 I can reach hamwan.org. hambook.de.ampr.org and am able to accept connections from general internet IP's. So this was the secret for me. Thanks Steve

1 0

Re: [44net] (no subject)
by Steve L 17 Jun '15

17 Jun '15

Yes root@ampr-gw:~# ip route show table 44 | grep 44.224 44.224.0.0/15 via 141.75.245.225 dev tunl0 proto 44 onlink window 840

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 17 Jun '15

17 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 06/17/2015 08:01 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote: >> >Good question! No, a change to the portal around the same time >> >prohibits adding 44.xx.xx.xx addresses as gateways. I believe there >> >was some noise on this list about it at the time. > That change was made because > 1) it was reported that 44.x gateway addresses didn't work > 2) it was reported that 44.x gateway addresses caused problems > 3) people were entering 44.x gateway addresses for their IPIP tunnels > instead of the proper commercial IP address of the endpoint. The reason (1 and 2) is that for a typical system that has both a public IP and an AMPRnet IP and is to function on the IPIP mesh, you need policy routing when you want the AMPRnet IP to be reachable from public IP addresses on internet. Normal internet traffic is to go out using the public IP, possibly using NAT, and AMPRnet traffic is to go out via the IPIP tunnels. When such a system is on a source-address filtered internet connection, the default route for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh system that has unfiltered internet access. Typically the system at UCSD. It is preferred that the varying gateway systems are configured only via RIP (usually in a separate route table), and that it is not required to make specific policy routing configuration for gateways. So the policy routing is static for 44.0.0.0/8. This conflicts with the 44.x gateway addresses, because the traffic got incorrectly routed by the routing policy (which is used both for the actual traffic and the encapsulated packets). When people see a way around that (I don't completely oversee if Jann's suggestion will achieve that), it would be no problem when tunnel endpoints exist within 44.x. Please see the example configuration for Linux systems in the wiki and suggest a way how that could be made working without manual "ip rule" entries dedicated to specific gateways. Or else, those "ip rule" entries maybe could be managed by ampr-ripd, that would be fine as well. Aside from that, of course it should still be validated that tunnel endpoints are not within the subnet being tunneled (3). That is simply an error condition. There were some networks that were claimed to be reachable via a tunnel at their first address (Sweden, for example) and there were some entries with tunnel endpoint == tunneled address. The portal should refuse that so that applicants are made aware of their error before such entries are broadcast via RIP and result in encapsulation loops. Rob

4 3

AMPRNet Interoperability with BGP
by Tim Osburn 16 Jun '15

16 Jun '15

So to solve the issue of Existing AMPRnet tunnel users not being able to reach BGP announced 44-net IP Space I've drawing the below drawing that shows how this can be done without having Brian Kantor ask UCSD to make any network/routing changes. This only requires at least 1 (or more) ISP (or companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server to make this work. There are currently two ISP I know of willing to do this if Brian is willing to do this on the AMPRnet Server shown in the drawing. This only requires setting up BGP with a route-map for changing the next hop IP's and running GRE tunnels on his server. The bonus is he can set this up with multiple ISP so that there is redundancy. Since the ISP is only sending BGP routes of the 44 IP Space of size /16-/24, this will not consume very much routing table space on his box (currently 53 prefixes). I also have to imagine the bandwidth going over this GRE tunnels not going to be a huge amount. So to summarize how this work. AMPRnet tunnel users can send traffic to a BGP announced 44 ip space which would travel over their IPIP tunnels (perhaps a low pref 44.0.0.0/8 route to UCSD in rip? or inject the BGP routes into RIP) back to UCSD and then over the GRE tunnel to a ISP and then ride the internet to get to that BGP announced block. Return traffic would just follow the existing internet routing table and come back via the UCSD network. AMPRNet Interoperability with BGP Drawing: https://www.osburn.com/amprnet-150614-1.0.0-bgptunnels.jpg Tim Osburn www.osburn.com W7RSZ

12 26

Re: [44net] JNOS 2.0j.7 autoexec.nos ?
by Jay Nugent 16 Jun '15

16 Jun '15

Greetings Peter (et al), > Sorry for being a bit off topic, could someone please help me with a > current JNOS 2.0j.7 autoexec.nos file, I only have old 1.11 configs on > floppies somewhere but will need to find a working floppy drive first, > Hi. > > Thanks ....... Peter ZL2BAU Here is the 'autoexec.nos' I run here on Hamgate.Washtenaw.AMPR.org. At the bottom, I have included the 'access.rc' TCP and IP access firewall rules. This 'autoexec.nos' is used on a DOS machine. It will require a few tweeks to have it run on a Linux box. Enjoy! --- Jay WB8TKL # autoexec.nos # # 040821 tkl - first cut # 040822 tkl - Adding ETH0 # 040825 tkl - Added AX1 # tkl - Configured to work with NOS110 version as well as 111 # 041206 tkl - Also works with JNOS2.0a (for DOS) # 051104 tkl - Including a better access.rc firewall # 060305 tkl - Configured as new YPSI Hamgate (access3.rc local.rte) # 080604 tkl - HG.LIV now CONV links to us (rather than us to him) # Also changed 'smtp timer 900' (was 300) # 'smtp maxclients 4' (was default of 10) # And changed 145.76 interface to 144.93 # 080911 tkl - Changed TCP SYNDATA to off (cheap routes won't pass SYNDATA) # Moved ann SMTP and BBS Mail settings into /nos/etc/mail.cfg # 090320 tkl - Removed conv link to Monroe (they link to us now) # 100309 tkl - Added link to MICONV # 100315 tkl - Using experimental nos2a-nr.exe # Modified autoexec.nos to support NetROM (MIYPSI WB8TKL-7) # 120418 tkl - Changed eth0 from 216.144.208.44 to 216.86.85.144 # = Chamged nameserver from 216.144.208.67 to 216.86.85.167 # # ######################################## ### Memory and System Configs ### ######################################## isat yes watchdog yes mem minalloc 32 mem ibufsize 2048 mem nibufs 7 mem debug on echo "***** Memory configured *****" pause 2 ######################################## ### Station Indentity ### ######################################## ax25 mycall wb8tkl-4 ax25 ttycall wb8tkl-5 ax25 bbscall wb8tkl-3 ax25 alias YPSI hostname HamGate.Washtenaw.AMPR.org ip address 44.102.1.1 ax25 bctext "WB8TKL-3 (YPSI) Washtenaw County AX25 & TCP/IP HamGate [www.MI-DRG.org]" # ######################################## ### Global AX.25 Parameters ### ######################################## ax25 version 2 ax25 maxframe 1 ax25 retries 10 ax25 pacl 200 ax25 window 1024 ax25 irtt 4000 ax25 timer linear ax25 t3 0 ax25 t4 1200 ax25 maxwait 9000 # ######################################## ### Global TCP/IP Parameters ### ######################################## tcp timertype linear tcp maxwait 9000 tcp retries 32 tcp window 864 tcp blimit 20 tcp irtt 4000 tcp mss 512 tcp syndata off # ip ttl 225 ip rt 4 # ######################################## ### Port Attaches ### ######################################## attach packet 60 eth0 11 1500 attach asy 0x3f8 4 ax25 144.93 576 256 9600 f1 ##attach asy 0x2f8 3 ax25 223.40 576 256 4800 f1 # attach netrom # echo "***** Attaches completed *****" pause 2 # ######################################## ### Configure the Interfaces ### ######################################## # # ETHERNET ifconfig eth0 ipaddress 216.86.85.144 ifconfig eth0 netmask 255.255.255.0 ifconfig eth0 broadcast 216.86.85.255 ifconfig eth0 descript "Ethernet to the Internet" # ifconfig eth0 tcp win 1024 ifconfig eth0 tcp irtt 50 ifconfig eth0 tcp maxw 150 ifconfig eth0 tcp mss 512 echo "***** Ethernet configured *****" pause 2 # # ENCAP ifconfig encap ipaddress 44.102.1.1 ifconfig encap netmask 255.255.255.255 ifconfig encap broadcast 255.255.255.255 ifconfig encap description "IPIP Encapsulation interface" echo "***** ENCAP configured *****" pause 2 # # COM1 [144.93] ifconfig 144.93 descript "144.93 MHz AX.25/IP Local Access port" ifconfig 144.93 netmask 0xffffff00 param 144.93 up #130 (129 = down) param 144.93 1 100 #1 Transmit delay param 144.93 2 128 #2 Persistance param 144.93 3 10 #3 Slot time param 144.93 4 10 #4 param 144.93 5 0 #5 0=half 1=full duplex param 144.93 8 1 #8 dtr param 144.93 9 1 #9 rts # # COM2 [223.40] ##ifconfig 223.40 descript "223.40 MHz 1200 baud District-2south Backbone Network" ##ifconfig 223.40 netmask 0xffffff00 ##param 223.40 up ##param 223.40 1 30 ##param 223.40 2 128 ##param 223.40 3 10 ##param 223.40 4 10 ##param 223.40 5 0 ##param 223.40 8 1 ##param 223.40 9 1 # # COM3 [phone] ##attach asy 0x3e8 5 slip phone 2048 576 19200 v ##param phone up # echo "***** IFconfig & Param completed *****" pause 2 # ################### ### NetROM ## ################### start netrom pause 2 # netrom alias MIYPSI netrom call wb8tkl-7 # mode netrom vc netrom minquality 10 # netrom interface 144.93 192 netrom bcnodes 144.93 netrom bcpoll 144.93 pause 2 # netrom acktime 3000 netrom choketime 180000 # netrom derate on netrom hidden off netrom promiscuous off # netrom retries 10 ##netrom tdisc 0 netrom ttl 10 netrom window 4 # netrom timertype linear netrom irtt 15000 netrom nodetimer 1800 netrom obsotimer 2100 netrom qlimit 2048 # ###netrom verbose on ##netrom kick # echo "***** NetROM configured *****" # ######################################## ### Services ### ######################################## start ax25 start telnet start smtp start ttylink start convers start ftp start forward start finger start pop3 start remote ##start http 80 ##start http 8080 echo "***** Services Started *****" pause 2 # ######################################## ### Digipeating, JHeard, Beacons ## ######################################## ax25 bcinterval 1900 ax25 hsize 30 # ax25 bcport 144.93 on ax25 digi 144.93 on ax25 hport 144.93 on # ##ax25 bcport 223.40 on ##ax25 digi 223.40 on ##ax25 hport 223.40 on # ip hsize 30 ip hport 144.93 on ##ip hport 223.40 on ##pause 2 # ########################### ### ARP Settings ### ########################### ##arp eaves eth0 on arp eaves 144.93 on ##arp eaves 223.40 on # arp poll eth0 on arp poll 144.93 on ##arp poll 223.40 on arp maxq 10 # ##arp publish 44.102.1.72 ax25 ka8pog-4 145.76 ##arp publish 44.102.1.42 ax25 ka8pog-4 145.76 # ######################################### ### Domain Name Service (DNS) ### ######################################### domain dns on domain suffix ampr.org. domain add 216.86.85.167 domain ret 2 domain maxw 60 domain translate off # domain verbose yes domain cache clean off domain cache wait 330 domain cache size 15 # cache for 5.7 days domain ttl 500000 # echo "***** Resolver configured *****" pause 2 ######################################## ### CONVerse Bridge ### ######################################## conv hostname WASHTENAW conv channel 81 conv mycall wb8tkl-6 conv interface 144.93 on # ##conv filter mode accept ##conv filter 44.102.24.1 ##conv filter 44.102.56.1 # ###conv link 44.102.24.1 3600 LIVINGSTON ###conv link 44.102.238.1 3600 ALCONA ###conv link 44.102.56.1 3600 MONROE conv link 44.102.135.1 3600 MICONV # conv maxwait 600 # ######################################## ### SMTP & BBS Mail ### ######################################## source /nos/etc/mail.cfg echo "***** /nos/etc/mail.cfg sourced *****" pause 2 # ######################################## ### Routing Tables ### ######################################## source /nos/encap.txt echo "***** /nos/encap.txt sourced *****" # source /nos/etc/local.rte echo "***** /nos/etc/local.rte sourced *****" # # Gateway through a neighboring station ##route add 44.102.1.220 145.76 44.102.48.88 ##route add 44.102.1.50 145.76 44.102.1.32 # # AX25 ROUTES ##ax25 route perm wa8efk 145.76 wpxd ##ax25 route perm n8kuf 145.76 wpxd # pause 2 ######################################## ### Firewall Rules ### ######################################## source /nos/access3.rc echo "***** /nos/access3.rc sourced *****" ##echo "#### no access.rc ###" pause 2 # ######################################## ### Passwords ### ######################################## mbox password "12345" remote -s PURPLE # ######################################## ### Miscellanious ### ######################################## source /nos/scripts/fkeys.scr echo "***** /nos/scripts/fkeys.scr sourced *****" ##pause 5 # trace 144.93 111 trace netrom 0211 strace on # history 15 watchdog on log on # # ---end--- # # Gateways-Access-FAQ # # /nos/access3.rc # # 20080604 tkl - Change interface to 144.93 # # # Start of ACCESS.RC file # *********************** # NB: The IP ACCESS and TCP ACCESS frame work is based on IP ACCESS and TCP # ACCESS control files shown below written by VE3RKS at VE3UOW and by # VE3PNX at VE3RPI. # # - This file should be sourced into your autoexec.nos file after all ports # have been attached and defined. # - This file also contains a handy summary of what TCP/UDP ports are # commonly used. # - This file contains information on the use of TCP ACCESS and IP ACCESS # - All lines begin with # symbols. This is to allow this file to be # sourced into your autoexec.nos after being edited for you specific setup. # Lines that do not begin with # symbols are valid NOS IP and TCP ACCESS # commands. # # Ports of interest for both UDP and TCP # ************************************** # 1 - 3599 - SERVER PORTS limit access based on local rules UDP and TCP # #*************************************************************************** # 7 - ECHO # 9 - DISCARD # 20 - FTP-DATA # 21 - FTP-CONTROL # 23 - TELNET # 25 - SMTP # 57 - SECONDARY TELNET # 67 - BOOTP # 79 - FINGER # 87 - TTYLINK [Operator chat] # 97 - AXIP/IPIP/IPTUNNEL # 109 - POP2 # 110 - POP3 # 119 - NNTP # 513 - RLOGIN/RWHO # 525 - TIME DAEMON # 1234 - REMOTE # 1235 - CALLSIGN DB # 3600 - CONVERS [Only AMPR.ORG domain should have access] # 3601 - LZW CONVERS [Only AMPR.ORG domain should have access] # #*************************************************************************** # 1050 - 32768 - REPLY PORTS should be accessable to all <= very important # #*************************************************************************** # # TCP ACCESS # ********** # TCP ACCESS is used to limit access to certain servers accessable by # TCP/TELNET to specific ports. For example you may want to allow # access to the SMTP server in your machine from all machines AMATEUR # and NON-AMATEUR. # # TCP access stops a connection to a server from being built at only # the machine at which it is installed. If you want to stop a gateway # from routing TCP/IP packets from specific addresses to specific # addresses you need to use the IP ACCESS code! # # TCP ACCESS WHAT FROM LOW HIGH # ### ###### ###### ############### ##### ##### # # Permit all AMPR.ORG and LOCAL domains to ports 1 - 3601 tcp access permit 44/8 1 3601 tcp access permit 127.0.0.1 1 3601 # # Do NOT allow inbound SMTP connectins from the Internet tcp access deny all 25 25 # # Permit all to ports 1 - 3599 tcp access permit all 1 3599 # # Permit all access to ports 3602 - 32768 tcp access permit all 3602 32768 # # Deny all access to CONVERS ports 3600 and 3601 tcp access deny all 3600 3601 # # # NOTES: The preceding TCP ACCESS code is read in order. TOP down! # Order is important. In reading from top down the first rule that # satisfies the origination address and port requirments is the one # used. So you should place excludes before includes for specific # originating addresses then followed by global [all] includes or # excludes. # # Example: # tcp access permit all 1 32768 # tcp access deny 167.23.43.1 3600 3601 <= should be first line # # This would not deny 167.23.43.1 access to convers server as the first # rule would satisfy the test to allow, but reversing the order would! # # # IP ACCESS # ********* # IP ACCESS is an important bit of code for a INTERNET/AMPRnet Gateway # as it can be used to selectively allow or disallow the routing of # TCP/IP packets based on source ip address, destination ip address, # packet type [udp/tcp/..], UDP or TCP port number and interface port. # # For most gateways you would like to only pass AMPR.ORG originated # ip address to other AMPR.ORG ip address (like UK and AUSTRALIAN LAW). # Exceptions might be where local law allows Amateurs to originate to # anywhere (including non-amateur destinations) as the replys are # technically under the control of the originator (like USA and CANADIAN # law). # # The idea behind IP ACCESS is to set up rules that will allow or deny # routing of packets. Unlike the TCP ACCESS command, IP ACCESS does not # restrict access to servers at the machine that is running this code. It # does however restrict the gatewaying of IP packets accross interface # ports. # # Valid PROTOCOLS are ICMP, UDP, TCP, and ANY (every thing else). Both # ICMP and ANY do not allow specific port restrictions as port numbers # are not really used for the other TCP/IP protocols. # # WHAT = <permit | deny | delete> # PROT = <tcp | icmp | udp | any> # PORT = ATTACHED INTERFACE/PORT # LOW = TCP or UDP low port number # HIGH = TCP or UDP high port number # # Below I use the following pseudo PORT names: # AX0 = ax25 rf port # AX1 = ax25 rf port # AX3 = AXIP psuedo ax25 port # BBS = SLIP port to an attached bbs # MODEM = SLIP port to a telphone modem # ETH0 = PACKET interface to ethernet card # ENCAP = ENCAP routing interface # # # IP ACCESS WHAT PROT SOURCE DESTINATION PORT low high # ## ###### ###### #### ############# ############### ##### ###### ###### ip access permit icmp 44/8 all 144.93 1 32768 ### ip access permit icmp 44/8 all 147.58 1 32768 # ip access permit icmp all all ax3 1 32768 # ip access permit icmp all all bbs 1 32768 ip access permit icmp all all eth0 1 32768 ip access permit icmp all all encap 1 32768 # ip access permit icmp all all modem 1 32768 # ip access permit udp 44/8 all 144.93 1 32768 ### ip access permit udp 44/8 all 147.58 1 32768 # # ip access permit udp all 44.bbb.ccc.ddd ax2 1 32768 # The above line allow a machine 44.bbb.ccc.ddd to receive UDP datagrams # from any source over a channel that would normally only allow 44/8 sources # # ip access permit udp all all ax3 1 32768 # ip access permit udp all all bbs 1 32768 ip access permit udp all all eth0 1 32768 ip access permit udp all all encap 1 32768 # ip access permit udp all all modem 1 32768 # # TCP will allow TCP client-server packets to be passed # ip access permit tcp 44/8 all 144.93 1 32768 ip access permit tcp all 44/8 144.93 1000 3599 ip access permit tcp all 44/8 144.93 3602 32768 ### ip access permit tcp 44/8 all 147.58 1 32768 # # ip access permit tcp all 44.bbb.ccc.ddd ax1 25 25 # The above line allow a machine 44.bbb.ccc.ddd to receive incoming SMTP # from any source over a channel that would normally only allow 44/8 sources # # ip access permit tcp all all ax3 1 32768 # ip access permit tcp all all bbs 1 32768 ip access permit tcp all all eth0 1 32768 ip access permit tcp all all encap 1 32768 # ip access permit tcp all all modem 1 32768 # # ANY will allow AXIP, IPIP etc! # # ip access permit any 44/8 44.bbb.ccc.ddd ax1 1 32768 # The above line allow a machine 44.bbb.ccc.ddd to receive incoming axip # from 44/8 sources over a channel that would normally not allow axip # # ip access permit any all all ax3 1 32768 # ip access permit any all all bbs 1 32768 ip access permit any all all eth0 1 32768 ip access permit any all all encap 1 32768 # ip access permit any all all modem 1 32768 # # IP ACCESS WHAT PROT SOURCE DESTINATION PORT low high # # Allow FINGER (port 79) from monitor.nuge.com to any ip access permit any 216.86.85.228 all 144.93 79 # # Block anything from AMPRGW/Mirrorshades (such as RIP2 updates) ip access deny any 169.228.66.251 all eth0 1 32768 # # The default rule is to deny all that are not allowed above. # # # ---end of file access.rc--- #

1 0

JNOS 2.0j.7 autoexec.nos ?
by Peter Mallett 16 Jun '15

16 Jun '15

Hi All, Sorry for being a bit off topic, could someone please help me with a current JNOS 2.0j.7 autoexec.nos file, I only have old 1.11 configs on floppies somewhere but will need to find a working floppy drive first, Hi. Thanks ....... Peter ZL2BAU

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net