44net

44net@mailman.ampr.org

4 participants
3198 discussions

Re: [44net] A few more questions Re: BGP portal management after WB6CYT's passing
by Rob Janssen 21 Feb '20

21 Feb '20

> I know this process can be invasive but you would be surprised how many bogus requests I've received over the years. I have to assume this is because of the scarcity of IPv4 addresses I agree with that! I also get requests from people who just want to use it for internet hosting unrelated to amateur radio, and without mentioning a valid callsign at all. Of course Quan also does not mention his callsign in his mailinglist message. A lookup on QRZ.COM indicates he likely has a BG3 callsign, but for me it would be suspicious when I receive a communication like that because any radio amateur knows that it is customary to use a callsign rather than only first and last name when communicating between radio amateurs. Just last week I got (as the coordinator for Netherlands) a request from someone likely living in Denmark (a nearby country) with just a fake word in the callsign field. Maybe he got turned away by the Danish coordinator and tried with me, maybe he wasn't even aware of the subnetting by country, I don't know. But we really need to watch out for people trying to masquerade as a radio amateur and trying to obtain IP space for free. Of course it doesn't help that the portal does not convey that information. It is likely that googling for services offering IP space somehow refers those people directly to the portal or to a subpage of the wiki, they read some paragraphs about obtaining IP space and never see what is the target audience for this system. That is mentioned only in some toplevel pages, not in the actual procedures for obtaining addresses. Someone from outside our community may not know what "callsign" means and just enter a netname as they would use in whois. So there is room for improvement there. About the ID and personal info requirement, I certainly have not been asked for an ID photo and it would be a problem to have such things on file indeed. But having some personal contact info (like name, callsign, e-mail and street address) should be fine as it is required to contact the registrant in case of problems. Rob PE1CHL

2 1

Re: [44net] Need TraceRoute from UCSD router
by R P 29 Jan '20

29 Jan '20

Thank U i have finally found the problem it was a wrong IP in the tunnel chain it consisted of few routers in series Thank You all for all your help Now additional question : who deal with entering/Changing records in the ampr.org DNS ? I need to update few records in my Network Thanks Forward Ronen - 4Z4ZQ ________________________________ From: John Gilmore <gnu(a)toad.com> Sent: Tuesday, January 28, 2020 12:35 AM To: R P <ronenp(a)hotmail.com>; gnu(a)toad.com <gnu(a)toad.com> Subject: Re: [44net] Need TraceRoute from UCSD router R P via 44Net <44net(a)mailman.ampr.org> wrote: > Steve > May you be kind and make a traceroute from UCSD Router to the Commercial IP of this gateway to see the nodes it passes throug ? I'm not Steve, but here is a traceroute from the UCSD Router to some IP address that was mentioned in the message (you were not specific about what IP address you wanted a trace to, so I just had to guess. Be specific if you are asking people to do some service for you!) John traceroute to 31.44.137.3 (31.44.137.3), 64 hops max, 40 byte packets 1 169.228.34.82 (169.228.34.82) 0.607 ms 0.539 ms 0.606 ms 2 nodem-core-6807-vlan2995-gw.ucsd.edu (132.239.255.49) 0.215 ms 0.245 ms 0.209 ms 3 mx0--nodem-core-30ge.ucsd.edu (132.239.254.162) 0.261 ms 0.227 ms 0.216 ms 4 mx1--mx0-p2p.ucsd.edu (132.239.254.149) 0.566 ms 0.287 ms 0.265 ms 5 riv-agg4--ucsd-2.cenic.net (137.164.23.57) 3.240 ms 3.206 ms 3.152 ms 6 dc-lax-agg6--riv-agg8-100ge-2.cenic.net (137.164.22.46) 5.016 ms dc-lax-agg6--riv-agg8-100ge.cenic.net (137.164.11.2) 5.173 ms 5.120 ms 7 8-1-1-90.ear1.LosAngeles1.Level3.net (4.35.156.65) 4.925 ms 4.916 ms 4.920 ms 8 ae-1-3111.edge4.London1.Level3.net (4.69.141.230) 135.741 ms 135.784 ms 135.748 ms 9 195.122.180.186 (195.122.180.186) 209.543 ms 209.932 ms 209.580 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * *

3 3

Re: [44net] PKTerrors.
by lleachii＠aol.com 28 Jan '20

28 Jan '20

Bill, I attempted to look through my records for 138.88.77.89 on my interface and I see quite a bit of packets from you - so much so that it crashed my NetFlow console upon searching your IP with a setting of 10,000 flows. I am receiving encapsulated packets from you, and it seems you've pointed traffic towards me. Firewall: 203.87 K 11.09 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop Encapsulated: Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 2020-01-26 10:01:01.733 202.005 IPIP 138.88.77.89:0 -> 141.75.245.225:0 28 8758 1 2020-01-26 10:01:01.733 202.005 IPIP 141.75.245.225:0 -> 138.88.77.89:0 28 2371 1 2020-01-26 10:18:02.902 419.571 IPIP 138.88.77.89:0 -> 90.155.50.1:0 116 9976 1 2020-01-26 10:26:40.783 13495.994 IPIP 176.121.81.53:0 -> 138.88.77.89:0 107 8922 1 de-encapsulated: Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 2020-01-26 09:18:45.097 88198.195 TCP 138.88.77.89:41958 -> 3.219.211.244:8883 7209 879799 1 2020-01-26 09:18:45.097 88198.195 TCP 3.219.211.244:8883 -> 138.88.77.89:41958 5618 341324 1 2020-01-26 09:31:05.692 86085.778 TCP 138.88.77.89:38410 -> 69.147.82.61:443 8792 2.7 M 1 2020-01-26 09:31:05.692 86085.778 TCP 69.147.82.61:443 -> 138.88.77.89:38410 7968 1.6 M 1 - KB3VWG

5 4

Need TraceRoute from UCSD router
by R P 28 Jan '20

28 Jan '20

Hi there Im trying to debug why one of our hams dont have tunnel up an running (or actually why one day it stopped working for him ) I suspect there are a routing problem from UCSD side to his ISP I wrote Brian mail asking to login to the UCSD HAM router and make a trace route to this local ham so i can track the problem Who can help me now ? is there anyone that have the ability to login and make trace route maybe Chris ? or any other solution ? The MikroTik Router he have declare that no route to UCSD and the tunnel status is down but from the router side ping can be done to UCSD ham router Is there any chance to do a web interface on UCSD Router that will give the option to the users to make trace route from there to a certain destination using the 44 and the non 44 interface ? something like this https://ping.eu/traceroute/ Thans forware for any assistance Ronen - 4Z4ZQ

6 9

Re: [44net] PKTerrors.
by lleachii＠aol.com 27 Jan '20

27 Jan '20

Bill, The crash truncated the IPs in the search; showing my IP. Forcing a dynamic IP change on WAN helped me realize my error. But now, I get ICMP unreachable messages in reply to my pings. root@OpenWrt:~# tcpdump -vv -i eth0.2 host 90.155.50.1 -ntcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes16:46:24.510501 IP (tos 0x0, ttl 64, id 36329, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64173, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 0, length 6416:46:24.626840 IP (tos 0xc0, ttl 54, id 44297, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 36329, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64173, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 0, length 6416:46:25.510864 IP (tos 0x0, ttl 64, id 37129, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64530, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 1, length 6416:46:25.614088 IP (tos 0xc0, ttl 54, id 44337, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 37129, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64530, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 1, length 6416:46:26.511170 IP (tos 0x0, ttl 64, id 37676, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64733, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 2, length 6416:46:26.637354 IP (tos 0xc0, ttl 54, id 44392, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 37676, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64733, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 2, length 6416:46:27.511520 IP (tos 0x0, ttl 64, id 38445, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64775, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 3, length 6416:46:27.617907 IP (tos 0xc0, ttl 54, id 44428, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 38445, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64775, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 3, length 64^C8 packets captured8 packets received by filter0 packets dropped by kernel - KB3VWG

1 1

PKTerrors.
by W.B.Hill 27 Jan '20

27 Jan '20

Hi, Just been looking through https://gw.ampr.org/private/pkterrors.txt and I noticed there's entries for the external IP for the net I run. I'm running 44.131.170.0/30 with a RaspberryPi on 44.131.170.1 using IPIP with amprd, external IP address 90.155.50.1 The errors are like: 90.155.50.1 51.89.173.198 2 [19] dropped: non-44 inner source address What does this mean? And I can't seem to ping to 44.131.170.1 from the big bad internet, is this related? Thanks. Bill (M1BKF)

4 8

Re: [44net] PKTerrors.
by lleachii＠aol.com 27 Jan '20

27 Jan '20

All, I'm able to ping all three of Steve's IPs from 44.60.44.0/24. - LynwoodKB3VWG

1 0

Re: [44net] PKTerrors.
by lleachii＠aol.com 27 Jan '20

27 Jan '20

Bill, Can you reach me now as well? root@OpenWrt:~# ping 44.131.170.1 -I 44.60.44.1PING 44.131.170.1 (44.131.170.1) from 44.60.44.1: 56 data bytes^C--- 44.131.170.1 ping statistics ---4 packets transmitted, 0 packets received, 100% packet loss I still receive no IPIP packets on my WAN from 90.155.50.1. I also ran "tcpdump -vv -i eth0.2 -n proto 4" - I see no replies from any IP. 44.60.44.144.60.44.254 73, - Lynwood KB3VWG

1 0

Re: [44net] PKTerrors.
by lleachii＠aol.com 26 Jan '20

26 Jan '20

Bill, That error means that you are encapsulating an IP that does not equal a 44 IP (e.g. you're improperly sending multicast, broadcast or your Public IP onto the tunnel). Ensure that you only send 44-net SRC IPs inside the tunnel. Also, any 44 IP that you want to reach the Internet must have a DNS entry in the AMPR.ORG and 44 reverse zones. That seems to be properly setup already: 1.170.131.44.in-addr.arpa name = m1bkf.ampr.org. --- I ping and receive no reply - this is a TCPDUMP of my tunnel: 21:23:10.793135 IP (tos 0x0, ttl 64, id 46020, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 48759, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 7, length 64 21:23:11.793459 IP (tos 0x0, ttl 64, id 46092, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 48962, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 8, length 64 21:23:12.793801 IP (tos 0x0, ttl 64, id 46294, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 49447, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 9, length 64 21:23:13.794158 IP (tos 0x0, ttl 64, id 46674, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 49657, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 10, length 64 21:23:14.794465 IP (tos 0x0, ttl 64, id 47472, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 50140, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 11, length 64 73, - Lynwood KB3VWG

4 9

Link(s)
by gm4upx＠gb7jd.co.uk 25 Jan '20

25 Jan '20

Hello Matt, You may by now have found a solution to your problem; I had a similar problem when setting up a remote node last week via a mobile phone sim card ( cell net phone ! ). I found I could not connect from the remote node until I removed the default entry in iptables and used ip rules to get a two way connection. Regards, Ian.. A totally in-experienced user <smile>

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net