44net

44net@mailman.ampr.org

4 participants
3198 discussions

Ping N1URO - PacComm email
by Nick G4IRX (44.131.x.x) 30 Jun '19

30 Jun '19

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

1 0

Re: [44net] Connecting to 44net
by Brian 30 Jun '19

30 Jun '19

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

1 0

44Net VPN?
by KJ7DMC 29 Jun '19

29 Jun '19

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

3 2

Old Files
by vk2tv 26 Jun '19

26 Jun '19

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

1 0

NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
by f4hdk 20 Jun '19

20 Jun '19

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

5 9

Re: [44net] IRR Entries for BGP Filtering
by G1FEF 19 Jun '19

19 Jun '19

> 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

1 0

IRR Entries for BGP Filtering
by Jonathan Lassoff 19 Jun '19

19 Jun '19

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

8 9

Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
by Leon Zetekoff 18 Jun '19

18 Jun '19

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

7 10

Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
by Mark Phillips 17 Jun '19

17 Jun '19

".... may use any technique whose technical characteristics have been documented publicly ...." This mode is documented publicly along with its source code. I'd say we are good. So now it's just the symbol rate and bandwidth issue to overcome. I like the idea of multiple carriers too. Bond them together on demand perhaps? Mark On Mon, Jun 17, 2019 at 4:54 PM Steve L via 44Net <44net(a)mailman.ampr.org> wrote: > > > > ---------- Forwarded message ---------- > From: Steve L <kb9mwr(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 17 Jun 2019 15:54:13 -0500 > Subject: Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud > and 120kBaud > The rules no longer really specify how you must ID, like pre-1980's. > Basically in this case you ID in the mode > itself, just like D-Star, YSF etc, does. > > If the digital code was unspecified (also allowed) you'd likely have > to default to a CW ID. > > §97.119 Station Identification > > (b) The call sign must be transmitted with an emission authorized for > the transmitting channel in one of the following ways: > > (3) By a RTTY emission using a specified digital code when all or part > of the communications are transmitted by a RTTY or data emission; > > §97.309 RTTY and data emission codes. > > (4) An amateur station transmitting a RTTY or data emission using a > digital code specified in this paragraph may use any technique whose > technical characteristics have been documented publicly, such as > CLOVER, G-TOR, or PacTOR, for the purpose of facilitating > communications. > > On Mon, Jun 17, 2019 at 11:40 AM David Ranch <amprgw(a)trinnet.net> wrote: > > > I'm not an expert on FCC Part 97 and I don't want to derail this > > conversation but I don't think some of these protocols are legally > > self-identifying. > > > > > > > ---------- Forwarded message ---------- > From: Steve L via 44Net <44net(a)mailman.ampr.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: Steve L <kb9mwr(a)gmail.com> > Bcc: > Date: Mon, 17 Jun 2019 15:54:13 -0500 > Subject: Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud > and 120kBaud > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

1 0

Hamnet over 70cm : NPR (New Packet Radio)
by f4hdk 08 Jun '19

08 Jun '19

Hello, I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio). All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source. Do not hesitate to ask me questions about it. I hope it will interest some people here. 73, Guillaume F4HDK

16 41

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net