44net

44net@mailman.ampr.org

2 participants
3205 discussions

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)
by Rob Janssen 04 Oct '18

04 Oct '18

> I updated ampr-ripd in line with recent changes. Running v2.3. I do > use multiple routing tables as recommended in the documentation. Using multiple routing tables is good when you have to work around source address filtering, so you want to send traffic from your 44 address to systems outside 44.0.0.0/8 via another default router, e.g. amprgw, than your usual internet traffic. However, I think ampr-ripd >= 2.0 should insert a route for 44.0.0.1 in your table for net44 like: 44.0.0.1 via 169.228.34.84 dev tunl0 proto ampr-ripd onlink Strange that you don't have that. But when you use multiple tables you should also have: default via 169.228.34.84 dev tunl0 onlink in the net44 table (unless you use another system to work around source address filtering) so it should not matter much that 44.0.0.1 is missing as this happens to use the same gateway. Rob

2 1

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)
by Rob Janssen 03 Oct '18

03 Oct '18

> I think I'm going to have to draw a diagram of the amprgw setup and > trace the journey a packet takes going to and from it before I > understand exactly what's going on. I'm no longer sure. It could also help a lot when you separate the ampr.org system and the amprgw system, e.g. by running ampr.org (or both) in a VM. Rob

1 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)
by Rob Janssen 03 Oct '18

03 Oct '18

Does the ampr gateway know about the networks routed via BGP? Maybe the mistake is that it consults the route tables in some order (first check if there is a BGP route, if so then route that way, then check if there is a tunnel route, if so route via tunnel). This will fail on my test system because it has a /32 route via IPIP but the address is within 44.137.0.0/16 routed using BGP. The routing tables should be all merged into one so that it recognizes this /32 as more specific than the /16 and it routes via the tunnel not via BGP. Part of our routing table: default via 213.222.29.193 dev eth0 44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1 44.0.0.1 via 169.228.34.84 dev tunl0 proto ampr-ripd metric 4 onlink 44.2.0.1 via 191.183.136.1 dev tunl0 proto ampr-ripd metric 4 onlink (213.222.29.193 is the router of our ISP) Rob

1 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)
by Rob Janssen 03 Oct '18

03 Oct '18

> >/Is there a route for 44.0.0.1 in your routing table?///> Not that I can see. I'm running ampr-ripd. Probably an older version (before 2.0)? These had a hard-coded ignore of routes to 44.0.0.1 so it does not appear in your routing table, and as a result you may send traffic to 44.0.0.1 via your default route, with your public IP as source address. Then, you get replies. (whether this actually works depends on your configuration w.r.t. "ip rule" and using multiple routing tables) Rob

2 1

tcpdump of ping on ipip
by Brian 03 Oct '18

03 Oct '18

It looks as if pings do come via the tunnel as well: n1uro@gw:~$ sudo tcpdump -i tunl0 -vvvvv|grep ICMP tcpdump: listening on tunl0, link-type RAW (Raw IP), capture size 262144 bytes 18:19:41.105553 IP (tos 0x0, ttl 64, id 63523, offset 0, flags [DF], proto ICMP (1), length 84) portland.n1uro.ampr.org > ampr.org: ICMP echo request, id 23674, seq 1, length 64 18:19:41.107566 IP (tos 0x0, ttl 63, id 63523, offset 0, flags [DF], proto ICMP (1), length 84) portland.n1uro.ampr.org > ampr.org: ICMP echo request, id 23674, seq 1, length 64 18:19:41.210652 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 1, length 64 18:19:41.212484 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 1, length 64 18:19:42.219244 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 2, length 64 18:19:42.221105 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 2, length 64 18:19:42.534924 IP (tos 0xc0, ttl 64, id 43001, offset 0, flags [none], proto ICMP (1), length 99) -- Men over 50 no longer fight at the drop of a hat. They've learned it's hard Enough to hit a toilet, much less an agile younger fellow who is kicking Their butt. ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org

1 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)
by Rob Janssen 03 Oct '18

03 Oct '18

> 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

2 1

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)
by Rob Janssen 03 Oct '18

03 Oct '18

> 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

3 2

Re: [44net] Difference between RIPv2 and RIP44
by Rob Janssen 02 Oct '18

02 Oct '18

> 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

1 0

AX.25 with digital signatures and binary compression
by Quan Zhou 25 Sep '18

25 Sep '18

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

2 1

Old newbe question.
by Jean Létourneau 24 Sep '18

24 Sep '18

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net