> I'm only on the mesh here Rob and I can ping 44.0.0.1.
Is there a route for 44.0.0.1 in your routing table? It may be that you are actually
sending your traffic to 44.0.0.1 "direct", not via a tunnel.
(this depends on the setup of your machine and the version of the rip daemon you are running)
Rob
> I believed the problem with pinging from tunneled hosts was
> still there, but if it works for you, I must have forgotten.
It is a bit unclear what is going on. From a host that is exclusively on the IPIP
mesh the ping does not return (I see only the outgoing IPIP packet). From a host that is
both on the IPIP mesh and BGP-routed on internet it does work.
It looks like it replies "directly" (via the BGP route) to the replies sent as IPIP.
Rob
> A standard ripd won't ever see the RIP44 packets because they're
> encapsulated in an IPIP tunnel packet. The standard ripd doesn't
> know how to de-encapsulate them first.
Of course when you have a single multi-point tunnel interface like in Linux (tunl0), you
could have ripd listening on that interface and it would see the correct packet format.
However, I think the default ripd does some sanity checks that make it fail on the special
assumptions made in RIP44.
Rob
Hi all,
I just saw this project on the Github, and it looks related and might
be very interesting to you. Check it out!
https://github.com/brannondorsey/chattervox
An AX.25 packet radio chat protocol with support for digital
signatures and binary compression. Like IRC over radio waves.
Chattervox implements a minimal packet radio protocol on top of AX.25
that can be used with a terminal node controller (TNC) like Direwolf
to transmit and receive digitally signed messages using audio
frequency shift keying modulation (AFSK). In the United States, it's
illegal to broadcast encrypted messages on amateur radio frequencies.
Chattervox respects this law, while using elliptic curve cryptography
and digital signatures to protect against message spoofing.
--
Regards,
Quan Zhou
Hello Group,
I'd like to start experimenting building my own gateway (For
learning purpose).
I am reading different way to do it. Now I am in limbo bettwing :
amprd 2.1 or Mikrotik RIPv2 AMPR Gateway
Can you tell me your experience if you are using any of those options.
Thank you
73 de Jean, VA2OM / VE2PKT
--
Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode)
: VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net)
: VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway)
RF:
147.435 Mhz (1200 Bps),
Internet:
Telnet://nodes-ve2pkt.dyndns.org <http://xrouter-ve2pkt.dyndns.org/> port
23 (Network Node)
Telnet://fbb-ve2pkt.dyndns.org port 6300 (FBB BBS)
Telnet://ve2pkt.dyndns.org port 9000 (DXCluster)
E-Mail:
packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam
ampr net: ve2pkt(a)ve2pkt.ampr.org
Inet: ve2pkt(a)gmail.com
> I'll read this carefully and figure it out...I was a BASIC and C++
> man...shouldn't be too hard.
There is always a lot to learn...
But in shell scripting, the following two do the same thing:
if command
then
and:
command
if [ $? -eq 0 ]
then
Similarly:
if ! command
then
is the same as:
command
if [ $? -ne 0 ]
then
It reads easier (once you know) and it avoids the situation where someone
inadvertently puts something between the command and the 'if' that resets the $?
e.g. some attempt at debugging like 'echo $?'.
Rob
> Also, don't put a space between these two lines:
> > ipset -N ipipfilter hash:ip 2>/dev/null
> > if [ $? -eq 0 ]
It would not be a problem to have a space between those, but of course there should
not be other things, and having a space there maybe invites that.
You would better write this as:
if ipset -N ipipfilter hash:ip 2>/dev/null
then
...
else
...
fi
so it is clear what is going on and that the result $? of the ipset is to be processed by the if.
Rob
> I believe a significant number of people who have AMPRNet addresses
> and are BGP-connected really don't care much about communicating
> with other IPIP mesh-connected hosts; their interest is the rest
> of the Internet.
Of course traffic mostly tends to be local and we see some IPIP mesh
traffic to stations in the area that are IPIP mesh connected, including
country networks like Germany.
Most traffic is between AMPRnet addresses connected on radio or VPN,
and between those and internet.
It is understandable, because many IPIP mesh stations are small islands
at the other side of the world and there is little chance that someone
here would want to send a lot of data to them.
On the other hand, connections internal to our network are used to
interconnect repeaters (both voice and ATV) and for things like echolink
and they transport a lot of data, mostly local.
> Since there's no way to capture flow data for these folks, we'll
> never know where their traffic is going. All we can do is guess
> from anecdotal data.
Maybe we can setup some ip flow export...
Rob
You can also use ipset in Linux and OpenWrt to filter from the RIP44 announcements. I only allow Protocol No. 4 from you all.
I have the script; it's a slight modification of the one found on the Firewall Wiki.
It can be set to run with the -x argument after each RIP44 announcement on ampr-ripd.
Let me know and I'll send a TXT file of it.
- Lynwood
KB3VWG
> Ah ah ah, it's very complex to common mortals as me :)
> Perhaps it is mature the time to adopt, after many
> years, the *SIMPLE* implementation created by Maiko
> VE4KLM for JNOS2, applying it to our systems:
> ------------
> 3) Configuration
> -------------
> When adding a 44 route, typically one uses something like this :
> route add 44.0/8 encap a.b.c.d
But does that automatically add the two levels of firewalling that we are
discussing here? If not, it does not seem very relevant. It is quite easy
to make a configuration that basically works (especially when using RIP which
makes route statements like the above unnecessary), but the point is that it
is not secure against abuse by malicious people. That is why additional
work is needed.
Rob
