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.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
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
> 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
> 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
> 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
> 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
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.
> 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
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
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
> 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
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\."
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
> 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
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
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.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
> 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
> 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
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
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)
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
> 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
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
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
> 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
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. :-)
> 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
> 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%)
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
> 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
> 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
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..
>> 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
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
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
> 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
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.
> 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
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
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.
> 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
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
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||||
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)
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
>
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
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
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:
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
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
"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
> 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
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 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
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
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
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.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
> 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
> 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
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
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
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
> 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
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
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
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
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
> 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
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
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
> 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
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
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---
#
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
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Don Fanning <don(a)00100100.net>
> Date:
> 06/15/2015 12:35 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
>> >When you want to do something about a SPOF it is only required to do the
>> >RIP transmission
>> >from another system in parallel. E.g. from the system running the portal.
>> >
>> >
> RIP still doesn't solve routing loops that occur. RIP doesn't converge
> quickly (currently 44ripd takes 5+ minutes to send any new*static* change
> - if your firewall is configured to receive said packets from said
> source).
I fail to see why that is a problem. Few gateway stations appear a day, and having to wait
5 minutes before they are routed is really no big deal. Before, many gateway stations loaded
a routing table maybe once a day, or even less frequently.
Again, we are a radio hobbyist network, not some financial trade network.
> RIP has no concept of bandwidth limitations or multiple paths for
> the same route (ie: load balanced connections with different ISP).
Again, let's first set up something that is popular and has many users, and then we can always
consider doing things like that. For now we, and many others, find ourselves fortunate to have
found a SINGLE ISP that wants to sponsor us. When we setup radio connections to our neighboring
countries we may achieve some redundancy. And I prefer that way over settting up a tunneling
system over the internet. Or even over routing over the internet. Remember we are an amateur
radio network, not some multinational company trying to setup a rendundant data network with
zero failures.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Bryan Fields <Bryan(a)bryanfields.net>
> Date:
> 06/14/2015 09:48 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On 6/14/15 3:35 PM, Rob Janssen wrote:
>> >Your problem is that you want to try to talk us into believing that we have a problem with
>> >reliability, while for most of us it is clear that we first and foremost have a problem with
>> >existance. The amateur digital network is nearly dead, we are trying to revive it and make
>> >it thrive like it did in the early days, a network built and operated by hobbyists, and you
>> >are continuously trying to impress us with your knowledge about professional networks and
>> >your concerns about failure modes.
> Rob, take a chill pill.
>
> Take a look at the HamWAN, HAMNET, and what I'm doing here in the bay area.
> It's very much alive, and we're educating people about high-speed ham packet
> networks everyday. I had over 200 people at the TAPR forum at Dayton this
> year for my talk.
>
I am not talking about the work you do locally but about the way you approach "us" after you have found some
problem with your gateway implementation.
Not even mainly about the discussion that just has started, but about a similar discussion that was started
about the same topic some time ago. You continuously refer to Brian's system at UCSD as "broken", and
I don't like that attitude.
Especially not because it really is possible to fit in your system to co-exist in the network as it is now, as is
demonstrated by our gateway.
Rob
> Subject:
> Re: [44net] Two questions
> From:
> Bryan Fields <Bryan(a)bryanfields.net>
> Date:
> 06/14/2015 09:10 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
> No, the issue is the_broken_ routing at UCSD.
>
> ARDC does not announce the 44/8, UCSD does it for them and has a static route
> for 44/8 pointing at the gateway box. This is broken routing since the
> gateway is unaware of the more specific networks.
>
> What needs to be done is the UCSD gateway needs to be made aware of the
> subnets in the global table and only announce the subnets it knows about.
> There are routing protocols that would make this easy.
But that is already in place!! It is the IPIP tunnel mesh.
As long as you provide an IPIP tunnel for the subnet you advertise yourself on BGP, with
a tunnel endpoint on an internet address OUTSIDE 44.0.0.0/8, there is no problem at all!
We do have the same situation as UCSD at our gateway. Our ISP does the BGP advertising
of 44.137.0.0/16 and routes the traffic to the gateway. We have registered the same space
on the portal, and we have an external address for that (213.222.29.194). All the routing is fine,
also for people who send the traffic to UCSD. Because UCSD sees the more specific route 44.137.0.0/16
first and sends the traffic via IPIP to us, instead of sending it out to the default gw that would
bounce it back.
When you would set up the same configuration, you would be out of trouble.
When you don't want a single system to be responsible for the IPIP tunnel you can setup some
redundancy, as long as you don't "conveniently" take a subnet out of 44.0.0.0/8 for that, because
that does not work. It is known it does not work.
>
> <tangent>
> I'd argue the BGP networks would be better if 44/8 was split up in such a way
> set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users.
> This makes the routing much easier to configure on a IPIP encap gateway. The
> present geographic area way of doing it leads to routing table bloat.
> </tangent>
I don't agree with that. It will just make a new configuration necessary for something that now
works OK just by the mechanisms we already have.
Rob
Hi!
I have two questions:
1. Around 99% of all webcams on the HAMNET are *only* reachable if you
establish the connection using a *source-44* ip address. Do you think
this restriction is enough if you don't want to expose the webcam to the
internet but want to share with other AMPRNet users?
2. We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless
router to HAMNET access point> into their DSL/cable routers. Some
well-known internet services for radio amateurs are nowadays hosted on
the internet using network44 addresses. Who needs to be blamed if the
connection from the HAMNET user to the well-known internet service is
not as stable as expected by the user?
73,
Jann
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
On Sun, 14 Jun 2015, Brian Kantor wrote:
> Date: Sun, 14 Jun 2015 18:20:22 -0700
> From: Brian Kantor <Brian(a)ucsd.edu>
> Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] AMPRNet Interoperability with BGP
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote:
>> 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.
>
> I'm willing but not able. The server 'amprgw' is an old FreeBSD system
> that doesn't understand GRE. We have been discussing updating it to
> a more modern system (both hardware and software) but at this point
> it doesn't seem like that's going to happen. We've not been able to
> identify ANY router product that can do what the gateway needs to do
> in order to replace 'amprgw'.
>
> I have an alternative suggestion, which would be to find an ISP or two
> that are willing to take over the IPIP tunnel routing.
>
> They would BGP advertise /24 summary routes for the smaller tunnels, as well
> as appropriate routes for the wider tunneled subnets. That way there is
> no fixed route that blinds the tunnels to the BGP subnets. UCSD could
> still advertise the 44/8 overarching route (which I strongly believe is
> essential to preventing prefix hijacks), but since there would be more
> specific routes for the BGP and tunnel subnets, that wouldn't matter.
> It would only be necessary for the tunneled gateways to change their
> tunnel endpoint address -- there is no need for tunneled gateways to
> suddenly have to change software or overall configuration.
>
> Flaws?
> - Brian
>
If we did BGP over IPIP would that work? Are you able to run Quagga or
something that can do BGP/Routemaps on your FreeBSD box? What version of
FreeBSD is it?
Is the CAIDA telescope a external system? Perhaps a SHIM box with
quagga & GRE Tunnels between CAIDA & amprgw?
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Don Fanning <don(a)00100100.net>
> Date:
> 06/13/2015 10:05 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Alright, let's take this a different route.
>
> What would it take to make IPIP mesh more robust?
>
> If BGP capable nodes were to announce and route for IPIP endpoints within
> it's endpoint, that would remove the SPOF at UCSD.
No, it will just make the system more complicated. Especially when you introduce yet another
routing protocol, even worse, a manufacturer proprietary protocol.
When you want to do something about a SPOF it is only required to do the RIP transmission
from another system in parallel. E.g. from the system running the portal.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Bryan Fields <Bryan(a)bryanfields.net>
> Date:
> 06/13/2015 11:59 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On 6/13/15 4:05 PM, Don Fanning wrote:
>> >IPIP would also get the
>> >benefit of possibly routing EIGRP between IPIP mesh sites so that if one
>> >BGP route were to have catastrophic failure, another BGP announced route
>> >would already be announced and EIGRP would route to that end point.
> This is a joke, correct?
>
> You're proposing fixing broken routing using a non-standard protocol. IIRC
> EIGRP uses IP multicast for announcements (same as OSPF) so you'd need to run
> it over some sort of tunnel (gre) interface anyways.
>
> Just use BGP with a private AS up to the edge Internet connected BGP nodes if
> you're building tunnels.
>
> Tim Osburn and myself (and others) had proposed standards based way to move
> the IPIP tunnels to a redundant gateway design a few years back. It's not
> hard, but there is no movement from ARDC to actually move forward with it.
> I'd be happy with a study of proposed ideas, at least it's forward movement.
>
Your problem is that you want to try to talk us into believing that we have a problem with
reliability, while for most of us it is clear that we first and foremost have a problem with
existance. The amateur digital network is nearly dead, we are trying to revive it and make
it thrive like it did in the early days, a network built and operated by hobbyists, and you
are continuously trying to impress us with your knowledge about professional networks and
your concerns about failure modes.
Furthermore, you try to enforce your ideas by criticizing the efforts of volunteers and trying
to do a coup d'etat. It does not work that way. When you have a real improvement to
introduce you should demonstrate how to do it in a way compatible to what others are doing,
and understanding.
What I find a joke is that you are concerned about having a single point of failure, and then
roll out a solution that does not work *at all* under some static circumstances.
Better have a single point of failure in a network that works most of the time, than a network
that never works OK.
(some pure theorist may disagree with that and claim that something that never works is more
reliable that something that works 99.9% of the time, but I am not in that camp)
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Nigel Vander Houwen <nigel(a)k7nvh.com>
> Date:
> 06/13/2015 09:30 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Rob,
>
> Thank you for making my point. The reason you cant use a 44/8 address for a tunnel endpoint is because routing is broken.
>
> Nigel
>
I don't agree with you.
There is a problem with routing inside UCSD in that case, but there are other reasons why that should not be done.
When you run an IPIP gateway on a source-address-filtered system (and in my opinion, ALL user connections should be
soirce-address-filtered!! ISP's that don't to that just suck!) you need to route back traffic from net-44 to internet via
the gateway. The only viable way of setting up policy routing rules to do that falls apart when tunnel endpoints are
inside 44.0.0.0/8. So that should just be prohibited.
(As Marius also explained, it is even worse when tunnel endpoints exist within subnets that are also advertised as being gatewayed)
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Bryan Fields <Bryan(a)bryanfields.net>
> Date:
> 06/13/2015 09:40 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> I agree, however the configuration of a single gateway announcing 44/8 without
> the ability to reach more specific networks is_broken_ routing. Let me say
> this again:
>
> _The UCSD Gateway has BROKEN ROUTING affecting the REACHABILITY of IPIP users._
>
> If BGP users announce a subnet that 99.99999% of the internet can see, but
> IPIP users behind the UCSD gateway can't reach it, it's not BGP users that
> have broken routing, it's the silly UCSD gateway.
This is INCORRECT, it is actually your own system that is broken.
When you put up a system that announces a BGP route on Internet, you should also make
that system part of the IPIP mesh for the same subnet that you advertise on BGP.
Then, those that want to reach you on IPIP do not need to go via the UCSD gateway but
can directly reach you on IPIP. Remember IPIP is a mesh, there is no "central gateway"
other than that it has the largest subnet and attracts all traffic that is not otherwise routed.
Routing the IPIP traffic is your own responsibility, don't shift it to UCSD or Brian.
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Sam VK4AA" <vk4aa(a)vk4aa.com.au>
> Date:
> 06/13/2015 01:27 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Morning Gang
>
> Has anyone done authentication for paket stations connecting to our network
> by using radius?
>
>
> Sam
> VK4AA
I have tried, although not very persistently, but until now I have not succeeded.
I thought it would be easy (having some experience with radius in combination with VPN routers),
but until now I have not succeeded in getting a configuration with WiFi APs operating in EAP mode
and freeradius server on Linux to actually work. It should be possible, though.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Tom Hayward <esarfl(a)gmail.com>
> Date:
> 06/11/2015 08:45 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Forget about this; it's just syntax. Who cares if we have to have
> hundreds of P2P interfaces instead of a single P2MP? The script
> creates them, so the burden of both methods is equivalent.
>
Well, I think it is much better (at least, cleaner) to have a single IPIP interface (P2MP) and
have a route table (separate or merged with the main table) updated by a routing protocol.
What you have made will work, but requires frequent downloading of a file and patching of
the configuration to process changes. I did that before on Linux, but after having installed
ampr-ripd I would not want to go back to that method...
About routes: in Linux it is possible to have routes bound to an interface that has a broadcast
nature (e.g. ethernet) and with a gateway that is outside the subnet served by the system itself.
So you can partition a subnet and still have only a single gateway. This can be useful on ham
networks where everyone in a local area has a Point-to-Point link to a node, and everyone
routes to others via the node, but the node does not have an address in each subnet.
RouterOS cannot handle this, but Linux can. E.g.:
node has subnet 44.137.40.0/23 and has address 44.137.41.254
user has subnet 44.137.41.96/28 and has address 44.137.41.110 on eth0
then:
ip route add 44.0.0.0/8 dev eth0 gw 44.137.41.254 onlink
To do this in RouterOS (and in many other routers) you need to set the subnet mask
to /23 on the eth0, but that means it will try to contact the others directly, not routing via the node.
This will work when the local area is switching/bridging.
Otherwise you will need to have a node address in everyone's subnet.
The same situation occurs when setting up the P2MP IPIP tunnel interface: you assign it the
subnet of your local system, so all the routes are outside the interface's subnet and need
the "dev" and "onlink" parameters. RouterOS does not support them. But Linux does.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Marc, LX1DUC" <lx1duc(a)laru.lu>
> Date:
> 06/12/2015 05:06 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
>
> I do think that regardless of the OS it is much more important that anybody using 44net addresses shall support the IPIP mesh, regardless of any other routing procedures (e.g. direct BGP announcement, etc) in use. I have the "luxury" to be able to
> do direct BGP announcements, so I can reach BGP-only 44networks without NATing my 44net to my commercial IP address, others don't have this luxury but would eventually like to reach those 44etworks without the requirement for NAT.
Our country gateway is BOTH on BGP and on the IPIP mesh. It advertises the entire 44.137.0.0/16 network on both BGP and IPIP.
My systems at home are on net 44.137.41.96/28 and are linked to a local node for 44.137.40.0/23 via RADIO (unusual, I know...)
and that node is again linked to the gateway system via our HAMNET.
So my system is reachable both for BGP and for IPIP systems (and radio-connected systems) without me running IPIP myself.
Hence I don't need to do that at home.
When my radio link fails, I can setup an IPsec or OpenVPN VPN connection to our gateway, and routing in the network will
automatically adapt (the gateway and the nodes talk BGP on a private ASN# on the HAMNET side and the gateway will advertise
my 44.137.41.96/28 subnet when I setup an IPsec or OpenVPN link).
So there is no need to worry!
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> Jeroen Massar <jeroen(a)massar.ch>
> Date:
> 06/11/2015 09:03 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> >Forget about this; it's just syntax. Who cares if we have to have
> >hundreds of P2P interfaces instead of a single P2MP?
> ntpd cares about it and also the Linux and FreeBSD kernels.
>
> ISC ntpd listens on each interface automatically, hence after ~200
> interfaces it breaks as it runs out of file descriptors (each interface
> gets a separate socket as it uses it that way to be able to properly
> select the interface to reply to packets on that interface).
I know about that problem! Silly ntpd listens on a separate socket for every address,
instead of just listening on a wildcard socket. It caused havoc on our gateway because
it has over 200 addresses assigned to a dummy0 interface, used by an EchoLink proxy
farm running on the machine.
Fortunately in recent versions of ntpd it can be solved by config like this:
interface ignore all
interface listen lo
interface listen eth1
interface listen tun0
interface listen tunl0
i.e. you can direct ntpd what interfaces to watch and to ignore the rest.
I think it would be better when it listened on 0.0.0.0 instead (of course you CAN set
the source address of outgoing packets on a wildcard socket, at least in Linux you can),
but I saw there already has been a heated debate about that on the mailinglist so I chose
not to suggest that and use the abovementioned workaround.
Rob
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 06/06/2015 09:48 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hi Rob,
>
> I was quite active in the Mikrotik community and tried to push a little our
> ampr tunnel stuff.
> But the results are actually null. People are friendly but not interested.
Ok... at the moment I am reading the forum to see how change requests actually are
to be posted and how they are handled, as I have some other requests.
> The missing element is a way to create an IPIP interface without a specific
> peer IP, and add routes to specific peers on a given IPIP interface to get
> it in multipoint mode.
That is clear, yes. I already found that the do not support static routes being bound to
interfaces, let alone "onlink" routes. So even when you would want to load routes using
a script, it still cannot be done. They must have a reason for this (probably they want
to keep the routing entirely clean according to common practices), as the Linux kernel
can do a lot more than what they expose via the config interface.
>
> The easiest way to get ampr up fully is actually to set up a metarouter on a
> mipsbe routerboard (they have a xen virtualization on those), and run a
> OpenWRT in it, to do IPIP encap and run ampr-ripd. I have tried that, it
> works, but at the moment I use a PPC based routerboard which doesn't offer
> virtualization.
> But your RB2011 is a good candidate for this kind of setup, being mipsbe
> based. Others would be the RB45x, the RB75x, the RB95x and the OmniTik
> series.
As I wrote, I have no need for this because my RB2011 has a radio link to HAMNET and
as a backup I can setup an IPsec VPN to our gateway. So I don't need to be on the IPIP
mesh. And I still have a Linux system in colocation (a Raspberry Pi) that is on IPIP.
But for others, this approach can be interesting.
Some systems e.g. www.pe1chl.ampr.org and hampi.pe1chl.ampr.org are routed over
this radio link and the MikroTik (but there is no useful content on them).
>
> Regarding to linux: They run a proprietary distribution on a 3 kernel, but
> shell access is unfortunately not available, and there is no way to add 3-rd
> party extensions.
>
The device can be "rooted", though. You get a busybox shell. I have not done that yet,
it will probably make it difficult to get support in case I encounter some bug I want to be fixed.
Rob
