44net

44net@mailman.ampr.org

3170 discussions

by Brian

I was asked by one of the current TAPR board members to throw my name into the hat for this year's elections which I have done. One thing I would like to try to do is help us get some exposure on TAPR with our projects amongst other things I'd like to help accomplish. TAPR has been at some of our EastNet meetings and they know what we're about and are supportive of our use of IP over RF. I also would like to think having someone from within amprnet on the TAPR board could be beneficial to both. They should have emailed you a ballot with your membership ID number and expiration date of your membership. You'll need that to cast your 3 member vote. With that said, please cast a vote for me so that I'll be able to help achieve some great things for us all. Thanks in advance. -- Do Lipton Tea employees take coffee breaks? ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

6 years, 3 months

Re: [44net] Right Way to Add IPIP Connections to BGP-Announced Network

by Rob Janssen

Jason, It is difficult to define "right way" because there always is someone with a setup that breaks when you do it in some way. Who is wrong and who is right is difficult to tell in such cases. We have a BGP-announced /16 for the Netherlands and we also announce the same /16 on the IPIP tunnel network. Subnets from this are routed internally (using BGP as well, but not related to the internet BGP, we use private AS numbers) and also some people have IPIP tunnels with subnets or addresses that are within the /16. We use ampr-ripd to get the IPIP routes. This works OK. People communicating to others that are on IPIP as well use the IPIP tunnel, when they want to talk to others they send it via IPIP to our gateway (i.e. our gateway is the default gw on the 44-net routing table, instead of amprgw as in the examples) and we decapsulate it and forward the internal IP packet to our internal systems or to internet. To have it working this way it is important that all routes are in the same routing table. You can use different metrics to avoid collisions between BGP routes and IPIP routes for the same subnet, but it is not a good idea to use different routing tables for BGP and IPIP routes and then use ip rules to lookup in those tables until a route is found. This is because a more specific route should always be preferred, independent from the routing protocol. So when a packet is to be routed, it is looked up in the table and either a route via the IPIP mesh or some other route is used to forward it. A destination on IPIP can be within the BGP routed subnet without problem, and vice-versa. It will work fine when the remotes on IPIP correctly route back to you via IPIP as well. But some stations use clever hacks to work around certain problems and the result can be that they are unreachable for people using this solution. Who is right and who is wrong is difficult to determine, as has been shown in earlier discussions on the list. Rob

6 years, 3 months

Right Way to Add IPIP Connections to BGP-Announced Network

by Jason McCormick

With is the correct AMPRNet way to connect a BGP-announced AMPR netblock to the IPs that live behind IPIP tunnels? Should I just use one of my IPs in the /24 for the IPIP tunnel on my side, connect to 44.0.0.1/169.228.66.251, and use ampr-ripd? Or do I need a second subnet as in a "pure" IPIP setup and route between those networks myself? I'm not finding any good docs on the topic, but if I'm missing something please point me in the right direction. My understanding is that AMPR networks behind IPIP-based gateways can't necessarily get out to the wider Internet but rely on IPIP tunnels to different networks they want to reach via the rip44 service. We're working on setting up a larger Allstar-based repeater network and once we get it finally going, I want networks elsewhere in AMPRNet to be able to connect if they desire. Thanks. Jason

6 years, 3 months

Re: [44net] Difference between RIPv2 and RIP44

by lleachii＠aol.com

Aaron, As Brian said, I have the following IPs online: 44.60.44.1 - ping, NTP44.60.44.3 - ping, DNS44.60.44.10 - ping, HTTP44.60.44.254 (only accessible on AMPRNet) - ping I allow ping from your Public IP endpoint address and your 44 subnet(s) in the Portal. If you're on AMPRNet, a folder containing the ITU Radio Regulations and compiled ampr-ripd versions will be visible on the web server at: http://44.60.44.10/amprnet_docs/ -------------------------- Miguel, Also, I've added Marius' information to the Wiki: http://wiki.ampr.org/wiki/RIP -------------------------- Marius, FYI, I am able to ping 44.0.0.1: root@OpenWrt:~# ip route get 44.0.0.1 from 44.60.44.144.0.0.1 from 44.60.44.1 via 169.228.34.84 dev tunl0 table 44 uid 0 cache expires 582sec mtu 1480 window 840 root@OpenWrt:~# ping 44.0.0.1 -I 44.60.44.1 -c 3PING 44.0.0.1 (44.0.0.1) from 44.60.44.1: 56 data bytes64 bytes from 44.0.0.1: seq=0 ttl=62 time=67.768 ms64 bytes from 44.0.0.1: seq=1 ttl=62 time=67.814 ms64 bytes from 44.0.0.1: seq=2 ttl=62 time=67.492 ms --- 44.0.0.1 ping statistics ---3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max = 67.492/67.691/67.814 ms 73, - Lynwood KB3VWG

6 years, 3 months

Difference between RIPv2 and RIP44

by Aaron Jackson

I am curious to understand the specific differences between "standard" RIPv2 and the "RIP44" used by AMPR. I read on the wiki that 44net uses a "modified RIP advertisements". I find that tcpdump can decode these packets, showing the destination nextwor and next hop address. Why is a standard ripd unable to process these? Not complaining - just curious :) Thanks, Aaron, M6PIU

6 years, 3 months

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> 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

6 years, 3 months

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> 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

6 years, 3 months

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

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

6 years, 3 months

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> >/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

6 years, 3 months

tcpdump of ping on ipip

by Brian

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

6 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net