44net April 2013

44net@mailman.ampr.org

30 participants
17 discussions

portal registration issue
by Geoff Armstrong VA7CWD 17 Apr '13

17 Apr '13

Hello, I have tried on a number of occasions to register on the Portal. I have not received a confirmation email once. Anyone else having this issue? Thanks, Geoff VA7CWD / VE7KA

2 2

private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

I am running a gateway using rip, etc. I really only have wifi radio range to a couple other hosts. And that is working well. We have a couple other small wireless networks in town that I can't reach by radio. They could be connected to the internet but unfortunately would be behind firewalls that we cannot control. So till we get things realigned and such, I am looking for examples on how to create a private tunnel from my gateway to those locations. It doesn't really make sense to put another gateway in the portal, as I doubt the rip packets will pass though.

5 6

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

Yes the separate clusters each have separate NAT/firewalls protecting them. Again, I am not going to be able to convince the people donating that bandwidth to set our internal ip on their network as a DMZ host. I plan to write about it, if I ever figure out how to punch a two way tunnel from me (a place where I have control over such things) to these places. What I envision is from the rest of the amprnet, 44.92.21.0/24 comes here via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from here via some other capable tunnel to these remote sites till we convince folks we need to get something up on a decent tower. It doesn't need to be encrypted or authenticated, whatever is easiest and will do the job. --Quote-- I'm unclear on the topology of your network; I'm going to assume that the separate clusters each have a separate NAT/firewall protecting them. In that case, I believe you may get the IPIP traffic to pass through the NAT/firewall to the internal host by designating the internal host as a DMZ host. You would then register the NAT/firewall's public IP address as the gateway host. I'd wager it depends on the software in the NAT/firewall so some may do it and others may not. I heard that OpenWRT does handle IPIP encapsulation. I've not tried that myself so others who have done so should comment on whether this approach actually works. I'd much appreciate you writing up what you wind up doing and publish it on the wiki so others may share your experience. - Brian

6 6

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

First off I don't claim to know much about VPNs and encapsulation. Everyone I talk to tells me openvpn should do what I want. I take it that is a state full type of connection? Brian, the problem I see if if I setup another rip44 listener gateway, how do I direct the encapped traffic to our natted, internal IP? An entry in the portal will get it to their router (outside address), but having them place a forwarding rule to get it from there to out 192 internet address probably won't happen. ---- Quote------ On Wed, Apr 17, 2013 at 12:38:01AM -0500, kb9mwr at gmail.com <http://hamradio.ucsd.edu/mailman/listinfo/44net> wrote: >* It doesn't really make sense to put another gateway in the portal, as I*>* doubt the rip packets will pass though.* The AMPRNet internal RIP packets from 'amprgw' are sent encapsulated, so if you can do IP-IP tunnels at all, the RIP should get through too. One way to see whether a firewall will pass IP-IP tunnels is to add its address as a gateway and see if you get tunnel traffic on the other side. Since the internal RIP is sent every 5 minutes, it can be a simple test of your incoming connectivity. - Brian

3 2

RIP44d issue/bug
by Marc, LX1DUC 12 Apr '13

12 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good morning, I saw some odd routing during my tests. So I analyzed the routes added by RIP44d. I modified the code to log the command string to add routes, my suspicions where confirmed: rip44d v1.2 adds every route with a prefix length of /32: (examples) Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.161.0.0/32 via 141.75.245.225 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.129.0.0/32 via 118.22.1.194 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.147.0.0/32 via 121.99.232.227 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.183.0.0/32 via 130.208.168.63 dev tunl0 window 840 onlink table 44 Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add 44.94.0.0/32 via 141.224.128.8 dev tunl0 window 840 onlink table 44 All these routes should be /16 I'm trying to figure where the issue comes from, but I'm not a perl addict, so any help is welcome. I have already confirmed that the RIP message contains the correct netmask: IP Address: 44.161.0.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.161.0.0 (44.161.0.0) Netmask: 255.255.0.0 (255.255.0.0) Next Hop: 141.75.245.225 (141.75.245.225) Metric: 1 73 de Marc - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVNjWAAoJEHFIN1T8ZA8vteEP/2oD1ic40dvnuZSOOdvS+NNw BZEaIlI9gmIZ6P2FqJO4ZOs/kXLdKnxDa9hNgAV5+4bZAZyiGQIHFd1+rwIAaZKN quzJ1h7SzYKOJYDRiMIQO8nYdDzNMYKb4H5GhSpCiDWGHnt+OJA+uV8ZXHClj7QV y2AvJDKgrcRaf3Lr4kwghVnIHlmqibxPI2fFv8DuG8sBvIkxjtUJ21MOUq6nJD8z HaCpJRS8169Syl3jq/8DogEvKfjkehaNmczyxWfWcN1t93Lxh+pPGu88iDhh1pNS 3CpVw7nY1aV88fQUURMNRJqB5IEDLyL9z/A6oU8t4u095SS6wj3wbzs7HpY37Oc4 UsLbqLlH88wkc1AnW5PrrzNLNyjEX4/3y1zywhwJFaVWUGRTAVKC3fB8Q4hhg0/M r6q5LfjbFJzvZYppvsoqDMCAYHsAcg5lTP92+I1/86avntSW1Kj8bIJnrr/wGfZz zbURMk+9U2WJlX6mnmm/Z0a/Lo+l3/T74CzXDDmr8dvEaMB9r7AeTx3M7h6H/jBi yNrFZtwCg/ZMDcCR8jtAN8dqNOYht5uL/+N9dPZy50cyMhLjxVItl6BXrUYdXGqD 2p8zXKjwc8iPLuirvXs3cFK4dioDyJviMDTPSXss01zMBpLqj80UVltIV+xmMRf9 x6fcW9WXhFYoLN56hrti =0CVp -----END PGP SIGNATURE-----

3 2

Re: [44net] Gateways Unreachable after Dynamic IP Update
by Marc, LX1DUC 11 Apr '13

11 Apr '13

It seems that you have found the very same issue I have already documented: http://hamradio.ucsd.edu/mailman/private/44net/2013-March/000848.html https://github.com/hessu/rip44d/issues/7 Unfortunately I haven't heard back from the author or someone else and I'm not a perl developer, so I cannot fix it myself. Best regards, Marc Quoting lleachii(a)aol.com: 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.

2 3

Re: [44net] Gateways Unreachable after Dynamic IP Update
by lleachii＠aol.com 07 Apr '13

07 Apr '13

Dear Bob VE3TOK (and thanks to VE3ZDA and N2NOV), Your entry is on my route table, I'm using rip44d (not encap), so my updates are live. The IP of my gateway is correct in the Portal. I use the -a switch to remove my own route (and have updated it to the correct IP); and I still receive rip44d updates over AMPR (showing that I have not lost connectivity to the Main AMPRGW). From testing connectivity to your subnet, I have determined that my 44GW is operational; and that some gateways may not have yet updated their encap. Thanks for your help; I waited a few days to to be sure that was not the case; as I know all stations do not have dynamic routing updates, I'll wait longer next time. 73, Lynwood KB3VWG http://44.60.44.10/tools @kb3vwg-015:~$ ping 44.135.85.1 -c 10 PING 44.135.85.1 (44.135.85.1) 56(84) bytes of data. From 44.135.85.30: icmp_seq=7 Source Quench From 44.135.85.30: icmp_seq=8 Source Quench From 44.135.85.30: icmp_seq=9 Source Quench From 44.135.85.30: icmp_seq=10 Source Quench --- 44.135.85.1 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9003ms @kb3vwg-015:~$ traceroute 44.135.85.30 traceroute to 44.135.85.30 (44.135.85.30), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.724 ms 0.238 ms 0.218 ms 2 linux.ve3mch.ampr.org (44.135.85.151) 51.890 ms 55.835 ms 60.720 ms 3 port.ve3mch.ampr.org (44.135.85.30) 63.642 ms 62.613 ms 66.477 ms @kb3vwg-015:~$ ping 44.135.85.30 -c 5 PING 44.135.85.30 (44.135.85.30) 56(84) bytes of data. 64 bytes from 44.135.85.30: icmp_req=1 ttl=39 time=53.9 ms 64 bytes from 44.135.85.30: icmp_req=2 ttl=39 time=51.8 ms 64 bytes from 44.135.85.30: icmp_req=3 ttl=39 time=87.4 ms 64 bytes from 44.135.85.30: icmp_req=4 ttl=39 time=52.7 ms 64 bytes from 44.135.85.30: icmp_req=5 ttl=39 time=51.9 ms --- 44.135.85.30 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 51.899/59.607/87.406/13.919 ms

5 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2013