Cathryn,
I see your ping requests arriving at 169.228.34.84 no problem,
and they are being encapsulated at sent to 50.79.209.150, again,
no problem. Nothing is coming back from 50.79.209.150.
This suggests that something is filtering out protocol 4 (IPIP)
between 169.228.34.84 and 50.79.209.150.
A traceroute from 169.228.34.84 to 50.79.209.150 using ordinary
UDP works, completing after 18 hops. The last few hops in that
path look like this:
14 162.151.87.226 12.097 ms 12.315 ms 12.088 ms
15 162.151.79.134 12.735 ms 12.744 ms 12.773 ms
16 68.87.227.122 13.080 ms 12.983 ms 12.920 ms
17 * * *
18 50.79.209.150 37.676 ms 42.664 ms 33.084 ms
A traceroute from 169.228.34.84 to 50.79.209.150 using protocol 4
(IPIP) does not complete, and there are no responses beyond hop
15. The last few hops are:
12 68.86.84.150 11.117 ms 12.601 ms 12.734 ms
13 68.86.94.154 11.761 ms 11.743 ms 11.340 ms
14 162.151.87.226 12.469 ms 12.162 ms 12.392 ms
15 162.151.79.134 12.757 ms 12.800 ms 12.797 ms
16 * * *
17 * * *
18 * * *
This suggests that hop 16, 68.87.227.122, is not accepting/passing
protocol 4 packets. The hostname for that host is
lag-2-240-acr07.pinole.ca.sfba.comcast.net.
I hate to throw you to the wolves of comcast's customer service line,
but you may need to find out from them if they suddenly started filtering
out inbound IPIP packets at that router.
- Brian
On Sat, Jun 29, 2019 at 09:50:40AM -0700, Cathryn Mataga via 44Net wrote:
> Date: Sat, 29 Jun 2019 09:50:40 -0700
> From: Cathryn Mataga <cathryn(a)junglevision.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: Connecting to 44net
>
> I'm not connected to 44net anymore, when I ping, to me at least, my
> outgoing packets look correct, but I get no response ever.
>
> I'm trying to put together as much as I can. My gateway ips 44.4.28.50
> at 50.79.209.150, I have a static IP.
>
> I'm current on the portal, far as I can tell with no error messages.
>
>
> ping 44.0.0.1
> PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data.
> *no response ever
>
> I see the outgoing, but never the ping back.
>
> tcpdump -vv -i enp4s0 host 169.228.34.84
> tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 09:39:25.982188 IP (tos 0x0, ttl 64, id 54479, offset 0, flags [DF],
> proto IPIP (4), length 104)
> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> id 14161, offset 0, flags [DF], proto ICMP (1), length 84)
> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 105,
> length 64
> 09:39:27.006173 IP (tos 0x0, ttl 64, id 54594, offset 0, flags [DF],
> proto IPIP (4), length 104)
> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> id 15137, offset 0, flags [DF], proto ICMP (1), length 84)
> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 106,
> length 64
>
> I occasionally see one of these, which hints to me that ipip is making
> it to my gateway.
>
> 09:39:15.386222 IP (tos 0x20, ttl 48, id 32657, offset 0, flags [none],
> proto IPIP (4), length 60)
> amprgw.ucsd.edu > hamradio.junglevision.com: IP (tos 0x0, ttl 237,
> id 33644, offset 0, flags [none], proto TCP (6), length 40)
> no-reverse-dns-configured.com.46324 > ke6i.ampr.org.finger: Flags
> [S], cksum 0x039d (correct), seq 2046795537, win 1024, length 0
>
>
> ip tunnel list tunl0
> tunl0: any/ip remote any local any ttl 64
>
> ifconfig tunl0
>
> tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480
> inet 44.4.28.50 netmask 255.255.255.255
> tunnel txqueuelen 1000 (IPIP Tunnel)
> RX packets 2259 bytes 305270 (298.1 KiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 2874 bytes 233904 (228.4 KiB)
> TX errors 232 dropped 0 overruns 0 carrier 0 collisions 232
>
> ifconfig enp4s0
> enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 50.79.209.150 netmask 255.255.255.240 broadcast
> 50.79.209.159
> ether 8c:89:a5:64:04:4c txqueuelen 1000 (Ethernet)
> RX packets 140452 bytes 25244334 (24.0 MiB)
> RX errors 0 dropped 473 overruns 0 frame 0
> TX packets 53461 bytes 5807456 (5.5 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> ampr-ripd -d -t 44 -a 44.4.28.50/32 -s -L ke6i@cm87uu
> Using gateway 50.79.209.158 for direct 44net endpoints via interface enp4s0.
> Calling home
> Waiting for RIPv2 broadcasts...
> Simple password: ***********
>
>
> ip rule list
>
> 0: from all lookup local
> 44: from all to 44.0.0.0/8 lookup hamradio
> 45: from all iif tunl0 lookup hamradio
> 45: from 44.4.28.50 lookup hamradio
> 32766: from all lookup main
> 32767: from all lookup default
>
>
> ip route list table hamradio
> 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840
> 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840
> 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840
> ...
>
> I don't think it's a firewall issue, I've turned off firewall and it
> doesn't fix anything.
>
> My route table looks healthy, so I think ampr-ripd is worrking correctly?
>
> Tried to include as much information as I can, thanks for any help!
>
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
If you are one of the 35 or so people who received a letter from
support(a)vultr.com informing you that there is a problem with your
subnet RPKI settings, feel free to ignore and discard it.
There is nothing wrong with your RPKI settings. In fact, most of
you don't have any RPKI settings at all. Maybe someday.
Vultr has a problem with their audit software which has been sending
out false alarms.
There appears to be no cause for concern.
- Brian
Brian N1URO - Have tried to reply to email you sent me about PacComm stuff a week ago but my reply has been returned undeliverable. If you are still interested, please contact me off-list with an alternative address?
Thanks,
Nick G4IRX
Cathryn;
I'm also on Comcast. To let you know in my 4 year battle with them, it
took me contacting Cisco direct to find out what the problem was. They
simply deploy broken CPE units to the end user by design.
What's probably happening is that they disable certain menu functions
which allows them to say they don't filter certain things, however the
natural behavior of the CPE will still filter. There's 2 solutions
available. You may read about them at:
https://uronode.n1uro.com/linux/amprcable.html
On Sat, 2019-06-29 at 10:51 -0700, Cathryn Mataga via 44Net wrote:
> email message attachment (Re: [44net] Connecting to 44net)
> > -------- Forwarded Message --------
> > From: Cathryn Mataga <cathryn(a)junglevision.com>
> > To: Brian Kantor <Brian(a)bkantor.net>, AMPRNet working group
> > <44net(a)mailman.ampr.org>
> > Subject: Re: [44net] Connecting to 44net
> > Date: Sat, 29 Jun 2019 10:51:06 -0700
> >
> > Thanks, this is useful, though is grim news. Last time I talked to
> > comcast, basically they had me reset power on my router, over and over,
> > for an issue that had nothing to do with my router, until they sent me
> > to another phone number that was disconnected.
> >
> > On 6/29/2019 10:38 AM, Brian Kantor wrote:
> > > Cathryn,
> > >
> > > I see your ping requests arriving at 169.228.34.84 no problem,
> > > and they are being encapsulated at sent to 50.79.209.150, again,
> > > no problem. Nothing is coming back from 50.79.209.150.
> > >
> > > This suggests that something is filtering out protocol 4 (IPIP)
> > > between 169.228.34.84 and 50.79.209.150.
> > >
> > > A traceroute from 169.228.34.84 to 50.79.209.150 using ordinary
> > > UDP works, completing after 18 hops. The last few hops in that
> > > path look like this:
> > >
> > > 14 162.151.87.226 12.097 ms 12.315 ms 12.088 ms
> > > 15 162.151.79.134 12.735 ms 12.744 ms 12.773 ms
> > > 16 68.87.227.122 13.080 ms 12.983 ms 12.920 ms
> > > 17 * * *
> > > 18 50.79.209.150 37.676 ms 42.664 ms 33.084 ms
> > >
> > > A traceroute from 169.228.34.84 to 50.79.209.150 using protocol 4
> > > (IPIP) does not complete, and there are no responses beyond hop
> > > 15. The last few hops are:
> > >
> > > 12 68.86.84.150 11.117 ms 12.601 ms 12.734 ms
> > > 13 68.86.94.154 11.761 ms 11.743 ms 11.340 ms
> > > 14 162.151.87.226 12.469 ms 12.162 ms 12.392 ms
> > > 15 162.151.79.134 12.757 ms 12.800 ms 12.797 ms
> > > 16 * * *
> > > 17 * * *
> > > 18 * * *
> > >
> > > This suggests that hop 16, 68.87.227.122, is not accepting/passing
> > > protocol 4 packets. The hostname for that host is
> > > lag-2-240-acr07.pinole.ca.sfba.comcast.net.
> > >
> > > I hate to throw you to the wolves of comcast's customer service line,
> > > but you may need to find out from them if they suddenly started filtering
> > > out inbound IPIP packets at that router.
> > > - Brian
> > >
> > >
> > > On Sat, Jun 29, 2019 at 09:50:40AM -0700, Cathryn Mataga via 44Net wrote:
> > >> Date: Sat, 29 Jun 2019 09:50:40 -0700
> > >> From: Cathryn Mataga <cathryn(a)junglevision.com>
> > >> To: AMPRNet working group <44net(a)mailman.ampr.org>
> > >> Subject: Connecting to 44net
> > >>
> > >> I'm not connected to 44net anymore, when I ping, to me at least, my
> > >> outgoing packets look correct, but I get no response ever.
> > >>
> > >> I'm trying to put together as much as I can. My gateway ips 44.4.28.50
> > >> at 50.79.209.150, I have a static IP.
> > >>
> > >> I'm current on the portal, far as I can tell with no error messages.
> > >>
> > >>
> > >> ping 44.0.0.1
> > >> PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data.
> > >> *no response ever
> > >>
> > >> I see the outgoing, but never the ping back.
> > >>
> > >> tcpdump -vv -i enp4s0 host 169.228.34.84
> > >> tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size
> > >> 262144 bytes
> > >> 09:39:25.982188 IP (tos 0x0, ttl 64, id 54479, offset 0, flags [DF],
> > >> proto IPIP (4), length 104)
> > >> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> > >> id 14161, offset 0, flags [DF], proto ICMP (1), length 84)
> > >> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 105,
> > >> length 64
> > >> 09:39:27.006173 IP (tos 0x0, ttl 64, id 54594, offset 0, flags [DF],
> > >> proto IPIP (4), length 104)
> > >> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64,
> > >> id 15137, offset 0, flags [DF], proto ICMP (1), length 84)
> > >> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 106,
> > >> length 64
> > >>
> > >> I occasionally see one of these, which hints to me that ipip is making
> > >> it to my gateway.
> > >>
> > >> 09:39:15.386222 IP (tos 0x20, ttl 48, id 32657, offset 0, flags [none],
> > >> proto IPIP (4), length 60)
> > >> amprgw.ucsd.edu > hamradio.junglevision.com: IP (tos 0x0, ttl 237,
> > >> id 33644, offset 0, flags [none], proto TCP (6), length 40)
> > >> no-reverse-dns-configured.com.46324 > ke6i.ampr.org.finger: Flags
> > >> [S], cksum 0x039d (correct), seq 2046795537, win 1024, length 0
> > >>
> > >>
> > >> ip tunnel list tunl0
> > >> tunl0: any/ip remote any local any ttl 64
> > >>
> > >> ifconfig tunl0
> > >>
> > >> tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480
> > >> inet 44.4.28.50 netmask 255.255.255.255
> > >> tunnel txqueuelen 1000 (IPIP Tunnel)
> > >> RX packets 2259 bytes 305270 (298.1 KiB)
> > >> RX errors 0 dropped 0 overruns 0 frame 0
> > >> TX packets 2874 bytes 233904 (228.4 KiB)
> > >> TX errors 232 dropped 0 overruns 0 carrier 0 collisions 232
> > >>
> > >> ifconfig enp4s0
> > >> enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> > >> inet 50.79.209.150 netmask 255.255.255.240 broadcast
> > >> 50.79.209.159
> > >> ether 8c:89:a5:64:04:4c txqueuelen 1000 (Ethernet)
> > >> RX packets 140452 bytes 25244334 (24.0 MiB)
> > >> RX errors 0 dropped 473 overruns 0 frame 0
> > >> TX packets 53461 bytes 5807456 (5.5 MiB)
> > >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> > >>
> > >> ampr-ripd -d -t 44 -a 44.4.28.50/32 -s -L ke6i@cm87uu
> > >> Using gateway 50.79.209.158 for direct 44net endpoints via interface enp4s0.
> > >> Calling home
> > >> Waiting for RIPv2 broadcasts...
> > >> Simple password: ***********
> > >>
> > >>
> > >> ip rule list
> > >>
> > >> 0: from all lookup local
> > >> 44: from all to 44.0.0.0/8 lookup hamradio
> > >> 45: from all iif tunl0 lookup hamradio
> > >> 45: from 44.4.28.50 lookup hamradio
> > >> 32766: from all lookup main
> > >> 32767: from all lookup default
> > >>
> > >>
> > >> ip route list table hamradio
> > >> 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840
> > >> 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840
> > >> 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840
> > >> ...
> > >>
> > >> I don't think it's a firewall issue, I've turned off firewall and it
> > >> doesn't fix anything.
> > >>
> > >> My route table looks healthy, so I think ampr-ripd is worrking correctly?
> > >>
> > >> Tried to include as much information as I can, thanks for any help!
> > >>
> > >>
> > >> _________________________________________
> > >> 44Net mailing list
> > >> 44Net(a)mailman.ampr.org
> > >> https://mailman.ampr.org/mailman/listinfo/44net
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
--
If a rabbit is raised indoors, would it be an ingrown hare?
-----
73 de Brian N1URO
IPv6 Certified
n1uro-dawt-ampr-dawt-org
uronode-dawt-n1uro-dawt-com
Hello,
This is sort of a follow up to my last email, which I ended up figuring
out. This link, http://he.fi/amprnet-vpn/amprnet-vpn-win.zip to download
the amprnet crt file is invalid. Any idea where I would obtain that file
from?
Thanks!
-Nate
I apologise in advance if this message is misplaced, but I've seen some
names/callsigns on the list that go back far enough to possibly have
what I'm looking for.
Some weeks back I performed some hardware decode comparisons for old
packet hardware - MFJ1270B and Tiny2 mk2 TNCs, serial port Baycom modem
(TCM3105 based), Baycom USCC>4 card with 1x9k6, 1xAMD7911 and 2xTCM3105
modems, a YAM modem, and some relatively new hardware, the TNCX and
Byonics TT4) - with Dire Wolf software decoding, with some surprising
results, except for the YAM.
Try as I might I couldn't get the YAM to rx data at 9k6, but I was able
to tx to the Baycom 9k6 modem which decoded packets. That was after I
added external, 5V powers supplies because the comport wasn't up to the
task (-5V/+2.8V)! The YAM won't tx or rx at 1k2.
I know the YAM is old - about 1998 - and there isn't much information
beyond what little I already had for the unit, which was capable of
two-way communication (over wire) with the Baycom many years ago, so I
know it "did" work. The Wayback Machine provided nothing useful.
My request is for any information pertaining to the YAM, and in
particular, any mcs configuration files for Linux. I have yam96v13,
yam17 and yam1k2b5. My fading memory seems to recall documentation
pertaining to faults and modifications, so that could also prove useful
.. if any still exists.
Thank you for your ears (or is that eyes?)
Ray vk2tv
Hello.
I have updated the firmware of my NPR (New Packet Radio) project with 2
expected features, mainly for America:
* New modulations (11, 12, 20, 21) for lower datarates, lower
bandwidth. Symbol rates: 56kS/s (complies with FCC) and 120kS/s. You now
have the choice between 9 modulation parameters, in order to adapt to
lots of situations and needs.
* Frequency range extended to 420-450MHz instead of previously 430-440MHz
I have updated all the documentation accordingly.
https://hackaday.io/project/164092-npr-new-packet-radio/
Several people here expected these features. I hope you will enjoy it!
73,
Guillaume F4HDK
> On 19 Jun 2019, at 17:33, チョーチュアン via 44Net <44net(a)mailman.ampr.org> wrote:
>
>
> From: チョーチュアン <quanzhou822(a)gmail.com>
> Subject: Re: [44net] IRR Entries for BGP Filtering
> Date: 19 June 2019 at 17:33:31 BST
> To: AMPRNet working group <44net(a)mailman.ampr.org>
>
>
> IIRC Vultr registers your prefix with the RADb as "Vultr Customer Route" or
> something alike. That will make your asn/prefix pair work with most
> providers. On the other hand, I met some providers completely ignores the
> RADb and/or LoA, and do their own due diligence, I believe there are good
> stories behind these practices.
Indeed, I have (not so fond) memories of trying to convince some carriers (usually tier 2 / wannabe tier 1’s) that they needed to update their filters so our customers could reach their networks. Those were the days! I guess not much has changed in 20 years.
Chris
Hello 44Net friends --
I'm operating a BGP-announced subnet of 44/8 for some paging and SDR
experiments, and with some new access to other facilities, I'm looking into
adding some geographic redundancy for my network, setting up an ASN, and
beginning some public peering.
However, what I am coming to discover is that Brian's LOA only gets me so
far... :)
Many networks in Europe are doing proper per-peer prefix filtering,
constructed from IRR data in various registries.
I would like to get my 44/8 prefix listed in one of these registries with
my ASN listed, so that I can get all this automatic filtering working.
Generally, most networks seem to be using the RIR-provided IRR registry for
this data, which for us in the US and with AMPR would be ARIN.
There are also some commercial IRR databases. https://www.radb.net/ seems
to be the most-widely mirrored, but it costs ~$500/year to use.
As this is just a hobby project for me, it's difficult to justify the costs
of a commercial registry.
Might it be possible for AMPRNet users to use ARDC's ARIN accounts to list
some "inetnum" IRR data for our prefixes?
Depending on the outcome, maybe this would be some useful information to
list on the FAQ in the Wiki.
Thanks,
jof
hi there...sound good but why aren't we using 2.4 or 5g for high
bandwidth backhauls? The hardware is cheap enough and works well.
73 Leon wa4zlw Blandon, PA
On 6/16/2019 10:40 AM, pete M via 44Net wrote:
> To:
> AMPRNet working group <44net(a)mailman.ampr.org>
>
>
> A big thank you for that effort. This will surely start a new boom in "packet radio" in north America. I for one will push to implement the fastest links to our audio links back bones that is all in uhf for our emergency net . That way we will work in Voip rather then analog voice opening the way to many more service at the same time .
>
> Télécharger Outlook pour Android<https://aka.ms/ghei36>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
