Cathryn,
I see your ping requests arriving at 169.228.34.84 no problem,
and they are being encapsulated at sent to 50.79.209.150, again,
no problem. Nothing is coming back from 50.79.209.150.
This suggests that something is filtering out protocol 4 (IPIP)
between 169.228.34.84 and 50.79.209.150.
A traceroute from 169.228.34.84 to 50.79.209.150 using ordinary
UDP works, completing after 18 hops. The last few hops in that
path look like this:
14 162.151.87.226 12.097 ms 12.315 ms 12.088 ms
15 162.151.79.134 12.735 ms 12.744 ms 12.773 ms
16 68.87.227.122 13.080 ms 12.983 ms 12.920 ms
17 * * *
18 50.79.209.150 37.676 ms 42.664 ms 33.084 ms
A traceroute from 169.228.34.84 to 50.79.209.150 using protocol 4
(IPIP) does not complete, and there are no responses beyond hop
15. The last few hops are:
12 68.86.84.150 11.117 ms 12.601 ms 12.734 ms
13 68.86.94.154 11.761 ms 11.743 ms 11.340 ms
14 162.151.87.226 12.469 ms 12.162 ms 12.392 ms
15 162.151.79.134 12.757 ms 12.800 ms 12.797 ms
16 * * *
17 * * *
18 * * *
This suggests that hop 16, 68.87.227.122, is not accepting/passing
protocol 4 packets. The hostname for that host is
lag-2-240-acr07.pinole.ca.sfba.comcast.net.
I hate to throw you to the wolves of comcast's customer service line,
but you may need to find out from them if they suddenly started filtering
out inbound IPIP packets at that router.
- Brian
On Sat, Jun 29, 2019 at 09:50:40AM -0700, Cathryn Mataga via 44Net wrote:
> Date: Sat, 29 Jun 2019 09:50:40 -0700
> From: Cathryn Mataga <cathryn(a)junglevision.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: Connecting to 44net
>
> I'm not connected to 44net anymore, when I ping, to me at least, my
> outgoing packets look correct, but I get no response ever.
>
> I'm trying to put together as much as I can. My gateway ips 44.4.28.50
> at 50.79.209.150, I have a static IP.
>
> I'm current on the portal, far as I can tell with no error messages.
>
>
> ping 44.0.0.1
> PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data.
> *no response ever
>
> I see the outgoing, but never the ping back.
>
> tcpdump -vv -i enp4s0 host 169.228.34.84
> tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 09:39:25.982188 IP (tos 0x0, ttl 64, id 54479, offset 0, flags [DF],
> proto IPIP (4), length 104)
> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> id 14161, offset 0, flags [DF], proto ICMP (1), length 84)
> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 105,
> length 64
> 09:39:27.006173 IP (tos 0x0, ttl 64, id 54594, offset 0, flags [DF],
> proto IPIP (4), length 104)
> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> id 15137, offset 0, flags [DF], proto ICMP (1), length 84)
> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 106,
> length 64
>
> I occasionally see one of these, which hints to me that ipip is making
> it to my gateway.
>
> 09:39:15.386222 IP (tos 0x20, ttl 48, id 32657, offset 0, flags [none],
> proto IPIP (4), length 60)
> amprgw.ucsd.edu > hamradio.junglevision.com: IP (tos 0x0, ttl 237,
> id 33644, offset 0, flags [none], proto TCP (6), length 40)
> no-reverse-dns-configured.com.46324 > ke6i.ampr.org.finger: Flags
> [S], cksum 0x039d (correct), seq 2046795537, win 1024, length 0
>
>
> ip tunnel list tunl0
> tunl0: any/ip remote any local any ttl 64
>
> ifconfig tunl0
>
> tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480
> inet 44.4.28.50 netmask 255.255.255.255
> tunnel txqueuelen 1000 (IPIP Tunnel)
> RX packets 2259 bytes 305270 (298.1 KiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 2874 bytes 233904 (228.4 KiB)
> TX errors 232 dropped 0 overruns 0 carrier 0 collisions 232
>
> ifconfig enp4s0
> enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 50.79.209.150 netmask 255.255.255.240 broadcast
> 50.79.209.159
> ether 8c:89:a5:64:04:4c txqueuelen 1000 (Ethernet)
> RX packets 140452 bytes 25244334 (24.0 MiB)
> RX errors 0 dropped 473 overruns 0 frame 0
> TX packets 53461 bytes 5807456 (5.5 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> ampr-ripd -d -t 44 -a 44.4.28.50/32 -s -L ke6i@cm87uu
> Using gateway 50.79.209.158 for direct 44net endpoints via interface enp4s0.
> Calling home
> Waiting for RIPv2 broadcasts...
> Simple password: ***********
>
>
> ip rule list
>
> 0: from all lookup local
> 44: from all to 44.0.0.0/8 lookup hamradio
> 45: from all iif tunl0 lookup hamradio
> 45: from 44.4.28.50 lookup hamradio
> 32766: from all lookup main
> 32767: from all lookup default
>
>
> ip route list table hamradio
> 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840
> 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840
> 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840
> ...
>
> I don't think it's a firewall issue, I've turned off firewall and it
> doesn't fix anything.
>
> My route table looks healthy, so I think ampr-ripd is worrking correctly?
>
> Tried to include as much information as I can, thanks for any help!
>
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
Hi everyone, new 44Net list member here. I'm trying to setup the OpenVPN connection to the OH7LZB VPN server. I'm primarily using this link (http://wiki.ampr.org/wiki/AMPRNet_VPN), but I am planning to update it once I get my connection working. Looking thru the archives, it seems a number of us have had challenges with the setup.
If someone has successfully configured it recently, maybe you can help me out with my setup? The encryption and auth seems to not negotiate, the connection never sets up. Per Hessu's response to my email (below), perhaps it has to do with the newer version / algorithms trying to get along with the server version.
Thanks in advance for any assist.
- Matt / KM4EXS
-------- Forwarded message -------
From: "Heikki Hannikainen" <hessu(a)hes.iki.fi (mailto:hessu@hes.iki.fi)>
To: matthew(a)alberti.us (mailto:matthew@alberti.us)
Sent: August 18, 2019 12:13 PM
Subject: Re: 44Net VPN Setup
Hi,
I generally prefer to have these discussions on a mailing list so that the answers are archived
publicly, and others can look for existing answers from the archive instead of asking the same
question again. I run aprs.fi so I get a lot of questions and emails.
The log, at this verbosity level, doesn't actually say what went wrong in the negotiation. I think
there was a thread on the 44list before where someone resolved this issue, something to do with new
versions of openvpn openssl refusing to use the older algorithms currently configured on the VPN
server.
https://mailman.ampr.org/mailman/private/44net (https://mailman.ampr.org/mailman/private/44net)
On Sat, 17 Aug 2019, matthew(a)alberti.us (mailto:matthew@alberti.us) wrote:
Hi Hessu,
I pulled your e-mail address off the 44net mailman list. Didn't want to spam
it, as I think I am missing something easy.
I'm trying to setup an OpenVPN connection to your server, so that I can get
an AMPRNet IP. I have followed the instructions at
http://wiki.ampr.org/wiki/AMPRNet_VPN (http://wiki.ampr.org/wiki/AMPRNet_VPN). It looks like I'm stuck after the CA
is verified, but before the data channel encryption/auth is negotiated.
Below are my logs. I was hoping you could take a look at the server side, my
public IP is 184.82.197.68. I think I'm probably using the wrong client
settings. I'm trying to set this up on a pfSense router.... so I have to
enter all the settings manually. I am trying to use BF-CBC and SHA1... but
also tried a few other combos. No luck.
Thanks in advance!
- Matt Alberti / KM4EXS
Aug 17 16:47:52
openvpn
18908
SIGUSR1[soft,tls-error] received, process restarting
Aug 17 16:47:52
openvpn
18908
Restart pause, 5 second(s)
Aug 17 16:47:57
openvpn
18908
WARNING: No server certificate verification method has been enabled. See
http://openvpn.net/howto.html#mitm (http://openvpn.net/howto.html#mitm) for more info.
Aug 17 16:47:57
openvpn
18908
NOTE: the current --script-security setting may allow this configuration to
call user-defined scripts
Aug 17 16:47:57
openvpn
18908
TCP/UDP: Preserving recently used remote address: [AF_INET]85.188.1.118:1773
Aug 17 16:47:57
openvpn
18908
Socket Buffers: R=[42080->42080] S=[57344->57344]
Aug 17 16:47:57
openvpn
18908
UDP link local (bound): [AF_INET][undef]:0
Aug 17 16:47:57
openvpn
18908
UDP link remote: [AF_INET]85.188.1.118:1773
Aug 17 16:47:57
openvpn
18908
TLS: Initial packet from [AF_INET]85.188.1.118:1773 (via
[AF_INET]184.82.197.68%), sid=368827b7 79c57373
Aug 17 16:47:59
openvpn
18908
VERIFY OK: depth=1, O=AMPRnet, CN=OH7LZB VPN service CA
Aug 17 16:47:59
openvpn
18908
VERIFY OK: depth=0, CN=ampr-gw.he.fi
Aug 17 16:48:57
openvpn
18908
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your
network connectivity)
Aug 17 16:48:57
openvpn
18908
TLS Error: TLS handshake failed
- Hessu
Greatings...!!!
I'm setting up an AMPR Gateway on an Ubuntu 16.04 box. This box is behind a Ubiquiti Unifi USG. I'm forwarding IP Protocol 4 to the internal IP of the box.
The layout of the box is two NIC cards...one that sits on my home network, the other card will handle my 44 net allocations with connection to the rest of the AMPR Net via the AMPR Net tunnel.
When I first bring the box up, and before I bring up the tunnel, I'm able to ping the 44 net hosts inside of my network. Using TCPDUMP I can follow the flow of packets pretty easily. The problem starts when I bring up the tunnel. As soon the tunnel comes up, when I try to ping one of my 44 hosts, I can see the packets are now going out on the tunnel interface and not on the NIC card on my 44 network. I've gone through this line by line on my scripts, and the problem starts when the actual default route to the AMPR Gateway is added. From that point on, all the packets are sent thru the tunnel. I've tried three different versions of scripts that I've found on the Internet and the result is the same.
Here's one script that I got off the AMPR Wiki:
#!/bin/sh
###
## Create AMPRNet Tunnel and routing
##
## Configure Tunnel (put your ISP you received from your ISP Here).
ip tunnel add ampr0 mode ipip local 192.168.12.158 ttl 255
## Bring it up
ip link set dev ampr0 up
## Enable Multicast in order to receive routes
ifconfig ampr0 multicast
## 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.26.2.32/27 table 44 priority 45
## Configure static routes
# Default route for table 44 is to send traffic to amprnet gateway at UCSD
ip route add default dev ampr0 via 169.228.34.84 onlink table 44
# Route packets for our net to local interface (put your AMPRNet Subnet here)
ip route add 44.26.2.32/27 dev ens192 table 44
## Start ampr-ripd to learn rest of mesh routes
# Be sure to substitute the password you found earlier for <SecretPassword>
# Put your static IP you received from your ISP here.
ampr-ripd -s -i ampr0 -a 192.168.12.158 -t 44
I've tried the obvious stuff...removing the route, re-adding the route....but I can't seem to figure this out. Any input, ideas, suggestions would be appreciated.
73's
Albert
WB7AWL
I thought some of you might be interested in this upcoming event. It
sounds relevant to our membership... Maybe a way to encourage other people
to get their licences? Too far from San Francisco for me to participate...
but I will be tracking the event from afar...
As to the ongoing maiing list discussion: I would like to propose we form
a subcommittee of interested members to review the organizational bylaws
and make recommendations to the Board of Directors for improvements.
I also think we need to communicate better and more efficently.. Perhaps
we can add some newer open source software tools to ensure smoother
communication?
Lori Guidos
KE6INO
OCTOBER 23, 2019
Mobile World Congress Americas
Los Angeles Convention Center :
https://www.spectrumcollaborationchallenge.com/
- The Challenge
-
The DARPA Spectrum Collaboration Challenge (SC2) aims to ensure that the
exponentially growing number of military and civilian wireless devices will
have full access to the increasingly crowded electromagnetic spectrum.
In this first-of-its-kind collaborative machine-learning competition,
competitors will reimagine new spectrum access strategies in which radio
networks autonomously collaborate to dynamically determine how the radio
frequency (RF) spectrum should be used moment to moment, avoiding
interference and jointly exploiting opportunities. SC2 teams will develop
these breakthrough capabilities by taking advantage of recent advances in
artificial intelligence (AI) and machine learning, and the expanding
capacities of software-defined radios.
The team whose radio design most reliably achieves successful communication
in the presence of other competing radios could win as much as $3,500,000.
I'm starting a new thread regarding this topic.
On 8/24/2019 2:10 AM, Lori Guidos wrote:
> I also think we need to communicate better and more efficently.. Perhaps
> we can add some newer open source software tools to ensure smoother
> communication?
I am reluctant to endorse adoption of new methods or tools: they tend to
become the problem they are supposed to prevent, drawing resources and
time away from more pressing issues.
This mailing list is stable, well-known, and easy to use. A new paradigm
would require that each subscriber climb what might be a steep
learning-curve, and once they do that, some will feel compelled to
demonstrate their command of the new methods and/or software by adding
to the amount of smoke surrounding our electronic campfire, without also
adding enough light to make the changes worthwhile.
Could communication be improved? Of course. Will having a new way to
communicate automagically cause that to happen? I don't feel that it will.
YMMV. HTH.
73,
W4EWH
Bill Horne
Hello,
I'm working on setting up a 44net gateway. I need to get some DNS names into the 44net DNS server. How is that being done nowadays...???
Thanks
Albert
WB7AWL
One approach that may generate some visibility of the issue - and possibly some action, or an investigation - would be to file a complaint with ARIN, the responsible entity fir all North American IP address allocations. See arin.net
Bill Semich, K1CSL
________________________________
From: 44Net <44net-bounces+bsemich=msn.com(a)mailman.ampr.org> on behalf of 44net-request(a)mailman.ampr.org <44net-request(a)mailman.ampr.org>
Sent: Friday, August 16, 2019 3:00:00 PM
To: 44net(a)mailman.ampr.org <44net(a)mailman.ampr.org>
Subject: 44Net Digest, Vol 8, Issue 133
Send 44Net mailing list submissions to
44net(a)mailman.ampr.org
To subscribe or unsubscribe via the World Wide Web, visit
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.a…
or, via email, send a message with subject or body 'help' to
44net-request(a)mailman.ampr.org
You can reach the person managing the list at
44net-owner(a)mailman.ampr.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 44Net digest..."
Hello,
I'm configuring a Raspberry with raspbian on 44.0.0.0 network.
I don’t understand some syntax options.
Man "route" options are "add" with "-net" or "-host" but
I don't find how to use the "addprivate" options.Example in Encap file : route addprivate 44.154.64/24 encap 62.169.206.224
But Man "route" says : route add [-net|-host]
"addprivate" seems not to be a option for "route add" command.
73
F1SXO
Frédéric ZULIAN
Hello,
I’m setting up my Raspberry 3 for HAMNET.
To configure my DNS server, I need the address of a root DNS server.
Is there one or more root DNS servers dedicated to HAMNET?
73
F1SXO
Frédéric ZULIAN
