> 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
