Marc, I do not suggest removing the 169.228.66.251 route. It was discussed a few weeks ago that removing the route on my standard Ubuntu machine causes RIP44 to fail (no longer receive RIP44 announcements). No resolution was reached in that discussion. ONE of the following routes must be manually added before RIP44 is operational: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 If you do not wish to have your subnet accessible from the Public Internet., use the following instead: ip route add 44.0.0.1 dev tunl0 via 169.228.66.251 onlink table 44 window 840 Further, 44.0.0.1 via 169.228.66.251 IS indeed a valid allocation on AMPR, it happens to be the Main AMPRGW. - Lynwood KB3VWG On 03/27/2013 10:40 AM, marius(a)yo2loj.ro wrote: I simply add 169.228.66.251 to the hosts to be ignored (option -a 169.228.66.251 ) so that route doesn't make it into the machine...

Hi Lynwood, I can ping/connect various ampr hosts via tunnel and can be reached/pinged from them (e.g. ve3zda.ampr.org, stecat, brklyn and others - just checked). 44.60.44.10 is not among them. So encapsulation on this side works ok, including the removed 44.0.0.1 route (which I can by the way ping correctly via the regular internet since it is a regular public IP and it has to be since it is the gateway for the tunnelled 44 hosts). So I would check the setup on your side again, ensuring that incoming requests AND outgoing ampr replies go via tunnel as defined in the broadcasts (wireshark is your friend...). Marius -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Wednesday, March 27, 2013 17:24 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Newbie issue I am unable to ping 44.182.21.1. You can verify at: http://44.60.44.10/tools/ping/php-ping.php 44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840

Hi again Lynwood, As I recall, I stated in the beginning of the previous discussion, I use Debian 6 on my gateway. "stecat" and "brklyn" are netrom nodes from which I can ping my tunnel endpoint. stecat is ve2pkt's node (at 44.135.49.4) but not reachable via telnet, only by netrom (I probably don't know the port). brklyn is ve1jot.ampr.org (44.135.32.74) and works, including an axip link over the tunnel. Btw: - I can not ping 44.60.44.10 from neither of them, but all can ping my system. Also other hosts working: db0eeo.ampr.org/telnet 3600, iz3lsv.ampr.org /ping, gb7cp.ampr.org /ping+telnet So I would think tere is no problem on this side. 73 de Marius, YO2LOJ

Lynwood, I really don't get it where you want to go. Maybe I confused the IP's since I looked only on Marc's traces, but the comments are equally valid. Your system is reacheable from the internet, but not via direct tunnel connection. And this because youprobably send all respones to the gw instead of the individual tunneling partners, but this is a assumption. Fyi: I have a fullt fledged setup, with full IPv4 and IPv6 acces. I host a full featured cluster, a igate, a convers node, mail server, ham forum, some web sites and a SIP VoIp setup. Also my system accepts PPtP acces for fellow ham operators providing 44 addresses if they like. And yes, I do communication programming and networking for a living. Unlike yourself, I can connect almost every node that has ampr access (and I mean connect, not a mere ping). So please stop asking me to check my systems, since it is yours that doesn't connect, doesn't ping and doesn't accept incoming connections except from the public internet. And this is my last statement to this topic. Marius, YO2LOJ -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Wednesday, March 27, 2013 23:03 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Newbie issue (Please trim inclusions from previous messages) _______________________________________________

Neither did I. - Brian

On Wed, Mar 27, 2013 at 02:57:30PM -0700, Cory (NQ1E) wrote: Uh, that's cheating. :-) - Brian

Brian, I think we found the problem...76.114.216.250 is my gateway IP, and it is being announced on RIP44; and is listed as such on https://protal.ampr.org (that has been my IP address for approximately 21 days). Am I to understand it's not being updated in encap? 44.60.0.0/16 - is Maryland 44.60.44.0/24 - KB3VWG AMPR -Lynwood

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well maybe it's better to get things working step by step. First step I want to get to work is ping from Internet. As I do receive routing updates via RIPv2, the communication between the central amprgw and my gateway must work. However, ping and traceroute from Internet does not. Ping and traceroute from Internet must go via Brian's central amprgw, so if RIPv2 works I don't see why ping and traceroute shouldn't. This is what the traceroute looks: traceroute to 44.161.229.126 (44.161.229.126), 64 hops max, 52 byte packets 1 * * * 2 e0.vtt176-1.lux.lu.as51405.net (46.29.176.120) 98.936 ms 25.167 ms 76.600 ms 3 83.243.15.25 (83.243.15.25) 21.690 ms 40.556 ms 60.720 ms 4 llnw.dus.ecix.net (194.146.118.93) 34.630 ms 89.112 ms 33.067 ms 5 tge1-5.fr4.frf.llnw.net (69.28.189.161) 69.808 ms 46.594 ms 55.931 ms 6 tge1-2.fr4.ams.llnw.net (69.28.171.54) 102.495 ms 115.217 ms 94.458 ms 7 tge16-1.fr4.lga.llnw.net (69.28.189.49) 280.854 ms 213.193 ms 299.031 ms 8 tge1-2.fr4.ord.llnw.net (69.28.172.198) 307.245 ms 204.316 ms 249.123 ms 9 tge1-3.fr4.sjc.llnw.net (69.28.172.77) 200.818 ms 202.944 ms 199.952 ms 10 * * * 11 dc-oak-core1--paix-px1-ge.cenic.net (137.164.47.19) 232.588 ms 207.561 ms 205.932 ms 12 dc-tri-core1--oak-core1-10ge-4.cenic.net (137.164.46.43) 204.926 ms 204.194 ms 213.565 ms 13 dc-riv-core1--tri-core1-4.cenic.net (137.164.46.248) 195.708 ms 208.480 ms 209.391 ms 14 dc-sdg-agg1--riv-core1-10ge-2.cenic.net (137.164.47.15) 214.901 ms 215.563 ms 216.029 ms 15 dc-ucsd-1--sdg-agg1.cenic.net (137.164.23.54) 201.269 ms 213.264 ms 202.829 ms 16 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 213.142 ms 200.361 ms 214.848 ms 17 ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 201.741 ms 204.033 ms 202.348 ms 18 amprgw.sysnet.ucsd.edu (169.228.66.251) 204.463 ms 201.769 ms 200.333 ms On the my 44net gateway no iptables rules have been defined: # iptables-save # Generated by iptables-save v1.4.8 on Thu Mar 28 22:59:30 2013 *filter :INPUT ACCEPT [31352:6172307] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [27531:4868700] COMMIT # Completed on Thu Mar 28 22:59:30 2013 I'm pinging 44.161.229.126 and 176.9.140.87 from my Laptop at home. On my 44net gateway only the packets to 176.9.140.87 show up in a trace: # tshark -i any not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on Pseudo-device that captures on all interfaces 0.000000 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 0.000023 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply 1.002346 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 1.002365 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply 2.002563 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 2.002593 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply 3.000364 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 3.000390 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply Brian can you see what happens with the ICMP ECHO REQUEST packets from 46.29.176.121 to 44.161.229.126? Regards, Marc On 27/03/2013 23:35, Marc STORCK wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How much time does it take for the DNS to update? Some additions were approved 10 hours ago, but they don't resolve yet... (If it's once per day, then there is no point to allow a TTL value of 1 hour...) 73 de Marc On 28/03/2013 23:30, Heikki Hannikainen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/03/2013 00:56, Brian Kantor wrote: Ohh, OK. That explains it. I'm not sure if my regional co-ordinator Arsène, LX1TB has ever used the DNS robot, so if you don't mind could you please add the following records: amprgw.lx0rl IN A 3600 44.161.229.126 aprs-igate.lx0rl-3 IN A 3600 44.161.202.10 73 de Marc

On Thu, Mar 28, 2013 at 05:16:25PM -0700, Brian Kantor wrote: And it works: brian@catbox:~$ traceroute -n 44.161.229.126 traceroute to 44.161.229.126 (44.161.229.126), 30 hops max, 60 byte packets 1 192.168.1.1 0.540 ms 1.361 ms 1.614 ms 2 * * * 3 76.167.6.13 21.382 ms 25.091 ms 29.082 ms 4 72.129.2.168 46.194 ms 46.743 ms 46.860 ms 5 72.129.1.2 46.944 ms 47.653 ms 47.767 ms 6 66.109.6.64 40.189 ms 40.547 ms 39.578 ms 7 66.109.6.129 67.781 ms 17.755 ms 44.691 ms 8 206.223.143.14 26.054 ms 16.798 ms 18.666 ms 9 64.57.20.227 28.114 ms 33.131 ms 28.773 ms 10 137.164.46.117 36.108 ms 39.312 ms 42.604 ms 11 137.164.46.65 42.432 ms 43.121 ms 35.440 ms 12 137.164.47.111 46.850 ms 43.175 ms 33.868 ms 13 137.164.23.54 37.881 ms 41.139 ms 39.666 ms 14 132.239.254.163 43.493 ms 45.487 ms 45.936 ms 15 132.239.255.131 46.880 ms 49.937 ms 53.650 ms 16 169.228.66.251 57.827 ms 46.058 ms 49.569 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 44.161.229.126 212.925 ms 216.588 ms 220.600 ms

All, Has anyone manually set the MTU of their un-encapsulated interface(s) on their 44Net Gateway to a value other than 1500? -Lynwood KB3VWG

All, Paul's note made me consider a few things; and, I now know why WE cannot contact some Stations: - To test, I changed my tunl0 MTU to 512, I began having failures with my tunnel. I was no longer able to reach certain services within AMPR or on the Internet. I could only perform pings to devices that I had already been able to reach. - I've attempted to use netalyzr.icsi.berkeley.edu to examine the connection for over a year, it was finally determined between Berkeley and myself that there must be a router in the path dropping ICMP - Fragmentation Needed messages when the tunnel's MTU (1480 for me) is reached. I confirm that my router is sending them, as I've done MTU pings from my 44LAN while running Wireshark and can see my router sending the message. Marius, You wrote />/ I can ping ve3zda.ampr.org without problems. />/ As for 44.60.44.1, 44.60.44.10, 44.60.44.11 and 44.60.44.12, ping goes out />/ via encap interface but there's no response on the ipip tunnel. />/ />/ My system: 44.182.21.1/89.122.215.236/ the VE3ZDA.ampr.org entry (44.135.90.2, which I can ping) is: 44.135.90.2 via 70.52.124.227 dev tunl0 onlink window 840 To test, I added the following route to my routing table: ip route add 44.182.21.1 dev tunl0 via 89.122.215.236 onlink table 44 window 840 PING 44.182.21.1 (44.182.21.1) 56(84) bytes of data. 64 bytes from 44.182.21.1: icmp_req=1 ttl=63 time=158 ms 64 bytes from 44.182.21.1: icmp_req=2 ttl=63 time=157 ms 64 bytes from 44.182.21.1: icmp_req=3 ttl=63 time=156 ms 64 bytes from 44.182.21.1: icmp_req=4 ttl=63 time=156 ms The populated route reads: 44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840 44.182.21.0 is a valid IP address on the ICANN Internet and does not imply a subnet in any form. It should contain a /24 notation as in the AMPRPortal: 44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840 No AMPR networks on my routing table (populated by RIP44d) contain the proper CIDR notations. -Lynwood KB3VWG

Marius, With rip44d v1.3 I now see: 44.182.20.0/24 via 89.122.215.236 dev tunl0 onlink window 840 44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840 PING 44.182.21.1 (44.182.21.1) 56(84) bytes of data. 64 bytes from 44.182.21.1: icmp_req=1 ttl=63 time=161 ms 64 bytes from 44.182.21.1: icmp_req=2 ttl=63 time=174 ms 64 bytes from 44.182.21.1: icmp_req=3 ttl=63 time=156 ms 64 bytes from 44.182.21.1: icmp_req=4 ttl=63 time=156 ms Though, I'm still unable to traceroute you. -Lynwood

About traceroute... I think traceroute relies on a icmp message "expired in transit" returned by each host on the route with increasing TTL on each probe. I am not shure that encap tunnels are able to provide such behavior. By looking to the traces, the "expired" icmp message is sent to the public tunnel endpoint IP from the machine where the TTL expires, but it is not encapsulated so does not make it to back to the traceroute utility. This could be a linux-only behavior, never tried it on nos derivatives... Marius.

Don, Those problems were resolved yesterday. Rip44d has been updated to version 1.3, it now correctly adds routes to the kernel routing table (which are referenced by their network address and CIDR prefix). The 0's refer to the routing tables and CIDR type routing, which for a /24 (or 256 IP host network), the network [address] begins at 0, the first usable address is 1, and the broadcast is 255. Prior to the rip44d fix, the problem was rip44d-based routers would only have 44.182.21.0 (a single IP address, /32) in their table, instead of 44.182.21.0/24 (which references 44.182.21.1-44.182.21.254). Therefore, Marius and I couldn't ping each other because I did not have a route for the IPs 44.182.21.1-254. -Lynwood

Samantha, I'm curious if you were able to setup your node and what Operating System you're using. Also, I'm curious about your reference to IPv6; is it for purposes of exploration/curiosity, or is there a current Amateur demand in your area for IPv6 enabled nodes? 73, Lynwood KB3VWG

Dual stacked nodes are going to be in use for some time ipv4 isn't going to get shut off tomorrow. Jerry, KD4YAL

Hi Lynwood We have dual stacked servers (we are an isp here in Australia) so we see the best of both worlds Sam ----- Original Message ----- From: <lleachii(a)aol.com> To: <44net(a)hamradio.ucsd.edu> Sent: Wednesday, April 17, 2013 7:39 AM Subject: Re: [44net] APRS & IPv6 - JNOS (Docs) Offtopic

It is about seting up a tunnel via a router one has no access to to set up port forwarding or other pass-throughts (it is an ISPs router which does NAT). -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Friday, April 19, 2013 21:23 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] private tunnel? (Please trim inclusions from previous messages) _______________________________________________ I'm not quite certain I understand the problem you are attempting to solve

That is the idea, to have a tunneling partner outside. And axudp probably will work in one direction only, since nobody will forward incoming connections to the machine inside. IMHO something like OpenVPN seems still the best solution with the client inside and the server otside. -----Original Message----- Can you get someone on the outside to route your subnet or subnets to you via AXUDP ??? --- Jay WB8TKL _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

KB9MWR, Well, I have not personally firewalled the WAN interface in the manner described (since I use it as an optional second Gateway and I am in control of two firewalls before the GW), though it is possible. The easiest method would to be to drop all incoming packets by default, only allowing ICMP type 8 (Echo Request) and IPIP. As I'm aware, aside from Ping (Echo Request), only a spoofed ACK packet can reveal a firewalled online host. Since rip44 and proper routing configuration allows received IPIP packets to be returned only to valid subnets, only permitting Ping and IPIP should be rather secure. It will not prevent (for example) an IPIP packet spoofed by a non-AMPR user sent to your GW that possesses a valid 44 src IP and a dst IP that's valid on your subnet. The reply would return to the AMPR IP in the SRC address (unless they have a firewall). This is prevented since only AMPR users know both the GW IP addresses and their associated subnets. Just to note, this behaviour may be valid in a multihomed network. -Lynwood

KB9MWR, I have not always used the mega version (I just began using that device); also, the mega device is not connected to the Internet, the Standard is. So, I assure you, standard passes IPIP packets. To make the ampr dynamic, place your dynamic hostname in the portal instead of the IP.

I am using gateway mode as well.

Morning All Seeing if anyone has got instructions on how to configure JNOS for APRS and IPv6 Thanks Samantha VK4FQ | VK4TTT

Hi Lynwood, -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Thursday, April 11, 2013 15:32 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Gateways Unreachable after Dynamic IP Update This is what I see in the encap file: route addprivate 44.182.20/24 encap 89.122.215.236 route addprivate 44.182.21/24 encap 89.122.215.236 Now these entries seem correct to me. Does it work with the new version from Hessu? Marius, YO2LOJ

On 13-04-09 04:54 PM, lleachii(a)aol.com wrote: Hi Lynwood, well, I'm running linux mint 14.1 on a laptop with jnos 2.0j2 (44.135.32.74) also running linux ax25 stack at the 44.135.32.201 address...this is to my wireless router which is connected to the cable modem...I found I had to add the path to the two 44-net addresses to my router with a route add statement in DD-WRT running in the router...otherwise stuff from regular ip addresses wouldn't find my 44-net.now I can access jnos and company from my local 192-net and has the added worry/benefit of being available from the entire inet....I'm running rip44d on the linux/jnos machine to handle the gateway entries...but I sure would LIKE to run rip44d on the actual wrt54g router...would be sooo much slicker, hi hi! I have the userland patches (google tuncreate.c) for jnos and linux using tun0, and also using tunl0 for getting the rip updates and handling the encap routes....just had a complete hard drive failure three or 4 days ago, so had to re-do everything from memory (arrgh!), but the benefit was a new laptop as the linux server with twice the ram, and a 2.8 ghz processor.... 44.135.32.74 is the jnos part (ve1jot-8)...telnet might be working to it...from it, you can go to ve1jot-7 (linux node) which has a few axudp routes and handles the radio ports (hf and vhf)...my config files are a mess, but if you like, PM me and I can attach a few for your confusion, lawl! HTH, John

I'm very much interested in others looking to implement services via RF and provide radio links in their local area; myection (Atlantic-MDC) is interested in building an infrastructure. And I've been working on back-end/backhaul resources that will provide rackspace for L7 services. While some Stations many not see the benefit, I do have interest in my area to break the 1200 Baud speed barrier (and proprietary equipment restrictions). -Lynwood KB3VWG

I now have rip44d version 1.2. Thanks for the help. I used the site: http://44.60.44.10/tools/ping/php-ping.php to ping 44.161.229.126 but on the gateway I see quite strange packet traces: # tshark -i eth0 not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 3.659640 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 4.670065 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 5.675693 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 6.683756 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) # tshark -i tunl0 not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on tunl0 0.000000 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 1.010436 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 2.019145 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 3.027052 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) Surfing from my office network to http://44.60.44.10/tools/ping/php-ping.php works fine. Surfing to http://44.161.229.126 gives a timeout on my browser and not a single tcp packet towards port 80 on my gateway. I am using the startampr script proposed earlier. The gateway is a fresh install done morning using Debian 6.0.7 64bit 73 de Marc

I can confirm the same. Bob VE3TOK On 13-03-27 04:28 PM, Marius Petrescu wrote:

It's strange that the packets are shown as fragmented packets. Also I have no idea who 76.114.216.250 is, it's the source IP for fragmented IP packets received on my gateway when pinging from your website... There is no firewall on that system # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Also I don't see any ICMP reply packets and your website reports: PING 44.161.229.126 (44.161.229.126) 56(84) bytes of data. --- 44.161.229.126 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3025ms This is my current kernel version in case this is relevant: # uname -a Linux debian 2.6.32-5-amd64 #1 SMP Mon Feb 25 00:26:11 UTC 2013 x86_64 GNU/Linux 73 de Marc, LX1DUC

Ooops, my mistake, it's in encap and active: 44.60.44.0/24 ipip-> 76.114.216.250[1,0]: 8090/4847421 Sorry. - Brian On Wed, Mar 27, 2013 at 02:53:23PM -0700, Brian Kantor wrote: