> 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
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 * * *
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
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
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)
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
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
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>
