Hey Everyone,
* Rosy (KJ7RYV) gave some opening remarks this morning at the
ARISS40th Anniversary Conference, which continues through tomorrow.
* ARDC's 2023 Annual Report is live: check out the associated blog
post for a copy of the report and see our highlights from last year:
https://www.ardc.net/2023-ardc-annual-report-now-available/
* Our first Community Meeting of the year is*TOMORROW*(Saturday,
February 24, 2024) at 10am PST / 6pm UTC. Hope to see you there!
Have a great weekend and 73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
I'm trying to configure a gateway with Debian and ampr-ripd never responds. I tried several tutorials and it never works.
My network structure is as follows;
eth0 (192.168.0.10) --> (192.168.0.1) [router(mkrotik)] (192.168.70.100) --> (192.168.70.1) [router (mikrotik)] --> ISP
(I know, it's a little strange but I need the 2 mikrotiks)
I have configured my external IP (it is in bridge mode) with a dyndns. For this test the firewall is completely open.
First I create the tunnel:
ip tunnel add ampr0 mode ip local 192.168.0.10 ttl 64
ip link set dev ampr0 up
ip addr add 44.153.x.x/32 dev ampr0
ifconfig ampr0 multicast
Then I add the path:
ip rule add to 44.0.0.0/8 table 44 priority 44
Finally I launch ampr-ripd:
ampr-ripd -a 44.153.0.0/16 -i ampr0 -t 44 -d
This process never receives a response.
Is there some configuration missing or am I misunderstanding the process? Maybe the mikrotiks are missing some configuration? (are the connections under NAT)?
Is there anyone who might be able to help me with a DNS entry? I'm trying to replicate something over the weekend that I've been experiencing at home.
I sent a note to hostmaster(a)ardc.net last week but I'm sure whoever answers that has been tied up. Entry I'm looking for is:
wvgw.kc8qba.ampr.org ADD A 44.63.19.14
Thanks in advance,
-Steve
kc8qba
Hey Everyone,
* John (K7VE), Phil (KA9Q), and myself are at HamCation this weekend:
come see us at booth 186 in the North Hall and catch John's forum
today (2/9) at 3:30pm in CS3.
* Our first Community Meeting of the year will be on Saturday,
February 24, 2024 at 10am PST / 6pm UTC. For more details, subscribe
to our newsletter: https://www.ardc.net/about/newsletter/
Have a great weekend and 73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hey Everyone,
Our first Community Meeting of the year will be on Saturday, February
24, 2024 at 10am PST / 6pm UTC. For more details, subscribe to our
newsletter: https://www.ardc.net/about/newsletter/
<https://www.ardc.net/about/newsletter/>Hope to see you there!
73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Somehow the output of the API call must have changed over time. It now
includes a count value before the encap array data, which will lead to an
error when processing it with jq.
Please update wiki the page with a different jq filter, c.f. how I fixed
the script on our system. I am ignoring the count value.
root@host:~# diff -U1 get-encap.sh-orig get-encap.sh
--- get-encap.sh-orig 2024-02-01 11:24:31.725642496 -0800
+++ get-encap.sh 2024-02-01 11:24:53.421227002 -0800
@@ -24,3 +24,3 @@
curl -s https://user:key@portal.ampr.org/api/v1/encap > json-data.out
-cat json-data.out | jq -r '.[] | "route addprivate
\(.network)/\(.maskLength) encap \(.gatewayIP)"' >> encap.txt
+cat json-data.out | jq -r '.encap[] | "route addprivate
\(.network)/\(.maskLength) encap \(.gatewayIP)"' >> encap.txt
root@host:~#
Thanks, andreas K6OTT
Hey Everyone,
* Please join us in welcoming Bob Witte, K0NR, to ARDC's Board of
Directors! To learn more about Bob, check out our recent blog post:
https://www.ardc.net/bob-witte-k0nr-joins-ardcs-board-of-directors/
* The blog post announcing ARDC's 2024 Advisory Committee Members is
also live: check it out to learn more about our new members and see
who's continuing with us this year:
https://www.ardc.net/ardc-welcomes-new-committee-members-for-2024/
Have a great week and 73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hey Everyone,
ARDC will be atOrlando HamCation happening from Feb. 9 - 11. If you're
at the event, stop by our table and say hello. Also, be sure to attend
our Forum (Friday, 2/9, 3:30pm ET), where John Hays (K7VE) will be
presenting/New Adventures using TCP/IP on 44Net (AMPRNet) and an ARDC
Update/.
Have a great weekend and 73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hello to those the list,
I have a VPN server running on a VPS (OpenVPN Access Server). I also have
the packet software XRouter (a.k.a. XRLin) running on the VPS. Normally it
can get the routes from the amprnet RIP broadcasts.
The VPN server uses a tunnel to send packets to my client. In the server to
client direction it takes packets from the internet addressed to the static
WAN address and changes the destination address to the client's VPN address
- pretty standard stuff. The dnat results in the traffic being routed to
the VPN tunnel. The OpenVPN Access Server writes rules to NFTables in order
to handle the forwarding, dnat, etc.
XRouter is set up with its own tunnel - somewhat similar to JNOS. I have
added rules in NFTables to forward all transport protocol 4/encap packets
to the XRouter tunnel. Included is a rule to dnat to Xrouter's address
which is on the Xrouter side of the P2P tunnel. This setup is working for
all encap packets EXCEPT the RIP packets.
Checking things with TCPdump, the RIP packets are being dnat'd to the VPN
tunnel address instead of the XRouter tunnel. I can't find any rules added
by the OpenVPN server that are matching any encap traffic, so I'm baffled
as to why they are not matched by my rules and also how they are matched by
the VPN rules. That said, the VPN Access server creates a very confusing
set of NTFable rules jumping all over the place though different chains, so
it's possible that they lost me. However I asked a question on their forum
a while back about support for protocol 4, and their answer was they don't
support it.
Is there anything about the RIP "IPIP" packets that is different from other
"IPIP" traffic so that they would be handled differently by NFTables?
Thanks,
Lee K5DAT
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
