- 44net - mailman.ardc.net

RPKI, BGP security, and possible paths forward

by k claffy

[written by two ARDC Board members kc claffy and John Gilmore] Along with all the other activities Phil mentioned in his mail, the ARDC board is talking about RPKI, catalyzed by the mailing list thread last month. Although John (W0GNU) sent some of his personal thoughts to the list, he emphasized that he was not communicating a Board position. As others noted in the thread, it is a complicated issue that admits no easy solution. There are unknown but presumably small amounts of BGP hijacking that occur in the wild. (Well, it doesn't matter how small the amount is if it's your prefix..) Current systems diagnose these mistakes after they occur; RPKI is an attempt to stop them before they occur. But it isn't clear to everyone that having that solution, in the political and litigious economies in which it is embeded, is better than having the problem it's trying to solve. Some incorrect assumptions have appeared on this thread, most importantly regarding the status of the AMPRnet address space, which is, without a doubt, legacy IP address space. This status has implications for trying to integrate into an RPKI system that is "rooted" in 5 roots run by RIRs that don't (always) trust each other. The idea of establishing a new independent RPKI Trust Anchor is -- as Job points out -- not something that has much precedent. A comparison to the web's PKI does not lend confidence in the trustworthiness of the ecosystem. Any organization that operated a new Trust Anchor would also be subject to tremendous liability. ARIN's response to that is tremendous indemnification (denying its RPKI users the right to successfully sue them), even in a hypothetical situation when ARIN were judged to be clearly at fault. This self-defensive behavior, plus some policy problems, are limiting RPKI uptake in the ARIN region. (For data geeks: https://rpki-monitor.antd.nist.gov/ ) Further complicating the issue, ARIN and the other RIRs decided to use routing certification as a wedge to require legacy users to sign contracts that both financially support the RIRs (maintaining high integrity databases is not cheap), and increase the RIRs' control over the legacy users' address space. At a deeper level, we recognize the architectural (not to mention sociopolitical) concerns John raised regarding inserting centralized cryptographic chokepoint(s) into the truly distributed BGP protocol. Questions we have heard in the debate, which we assume many amateur radio operators are sympathetic to, include: Who'll watch the watchers when they control the ability to block or allow users to be part of the routable Internet? And who will be able to effectively protest the RIRs' mistakes or overreaches when they can forcibly take anyone who disagrees with them off the Internet? We recognize the importance, magnitude, and sociotechnical depth of the problem. We admit that at this time we do not see a clear path forward that the whole AMPRnet community would stand behind. Since our mission is focused on network research, experimentation, and education, we would welcome one or more serious proposals in the area of BGP routing security. Approaches that do not require a hierarchical root of trust would be most consistent with the nature of our mission and the distributed nature of the Internet. Solutions that expose ARDC to the liability that ARIN has tried so diligently to avoid are much less likely to be adopted. We are also aware that routing security is a decades-old problem, and IETF working groups have argued over solutions for many years without resolution. We understand that RPKI as currently deployed is a compromise that has grown out of this history of tension and debate. Besides trying to solve the routing security problem for the world, we would also welcome ideas about merely solving it for 44net. If someone (or two) is inclined to (co)chair a working group on this topic, we could support workshops (virtual for now) to discuss AMPRnet-specific measures. https://www.ampr.org/giving/ kc and jg, on behalf of ARDC Board

4 years, 10 months

1
0
0 0

TA2T Coordinator for Turkey SK

by G1FEF

I have been informed of some more sad news: TA2T, the coordinator for Turkey is SK. Baris, TA7W has offered to step up as coordinator, unless anyone else is interested or has any objections? 73, Chris - G1FEF

4 years, 10 months

2
1
0 0

Re: [44net] Reverse DNS and access to DNS info

by Rob Janssen

>Email servers for instance need to be on addresses with a reverse DNS >pointing to the same name. To fight a spam, otherwise won't be accepted >by majority of other email servers. >How can we achieve something like this? > mail44.hamradio.si 44.150.0.10 > 44.150.0.10 mail44.hamradio.si That is true, but you do not need to run your mailserver under the hamradio.si domain even when you handle mail for that domain. It would work perfectly fine with a domainname like mail44.s57nk.ampr.org (both forward and reverse) and then in hamradio.si an MX record with that name. For this kind of thing we use "club callsigns" like pi9noz or pi4nos. Rob

4 years, 10 months

1
0
0 0

Reverse DNS and access to DNS info

by Rob Janssen

I notice that more and more 44net traffic originates from addresses that are not registered in DNS. To identify an amateur radio transmission, it is required in most countries that the callsign is included in transmissions. Up to now I have considered traffic from a net44 address to be identified by the reverse name that can be looked up in DNS, and that has the basic structure of "hostname.callsign.ampr.org" (with of course some variations, but always the callsign of the responsible station is part of the name). I think everyone should be encouraged (or even required) to register all used addresses in DNS. There may have been some hurdles to do that in the past (e.g. the never completed DNS part of the portal, the unavoidable restrictions of the ampraddr robot to accept only updates from coordinators). Everyone who has e.g. a number of hosts in the 44.190 or other not nationally registered parts of the network can send a list of their IP addresses and corresponding hostnames (with names like the above, i.e. a callsign embedded in them) to me, then I can submit them to the robot and they get registered in the ampr.org main DNS service. Otherwise please register your hosts through your local coordinator, even when you have been allocated an entire subnet. Furthermore, I see that more and more subnets have arranged to delegate DNS to their own servers. I think it would have been better to keep everything in a single list and then run a secondary zone within the own network (we do that here), instead of this split. Maybe a more convenient API for updating the main DNS should be (or would have had to be) added to avoid this? Or are there other reasons for operating this way? Given that we now have this situation, I think there should be a general policy of allowing AXFR and preferably also IXFR zone-transfers of these zones between net44 addresses. We should not have "dark and secret" zones that are inaccessible to others, I think, especially for the reverse (PTR) zones. Rob

4 years, 10 months

11
10
0 0

why and Wiki

by Dave Wade

Folks, Being marooned in that back water that is the UK I wonder what TCPIP packet activity there is in the UK and on what frequencies and how this would be supplemented by using 44net over the internet? I though I would read the Wiki but that seems to be un-availble.. Dave Wade G4UGM & EA7KAE

4 years, 10 months

2
2
0 0

Re: [44net] Reverse DNS and access to DNS info

by Rob Janssen

>I'm replying to the main thread, as Rob still insists with posting using his >broken MUA which breaks threading, making it impossible to follow his >ramblings. Thanks Rob. It is not convenient for me either! But I don't want to forward this list as separate mails as sometimes there are frantic discussions about topics that do not interest me at all (like RPKI) and I don't want my mail bell to ring all day (and load amsat.org with forwarding all those messages). So I am subscribed to the digest only, I sometimes watch the archives for quicker responses, and I cannot reply with the proper threading. I think I have mentioned it before: this list should be a newsgroup on an NNTP server. If only to honor Brian Kantor. Accessing it via a usenet news reader would be so much more convenient, you can just read it when you like and kill uninteresting threads. Or otherwise just use a forum. >Having reverse DNS with a callsign in it doesn't meet identification >requirements in the ITU or FCC rules, assuming the packet is traversing an RF >link on amateur frequencies. Under FCC rules (and I'm aware you may be under >a different legal authority), the control operator is the required ID, not the >originator of the packet. It is not only about regulatory ID requirements but also about identifying who is behind some traffic. Many places have "relaxed firewall rules" for traffic originating from within AMPRnet. This already requires revision due to the sale of the upper block (I think that lots of firewall rules still mention 44.0.0.0/8) but also with more and more blocks being routed directly and having no transparency about the actual use of that space, I would like to know if some address is really an amateur or if someone has lend it out to shodan.io or stretchoid.com. And if so, at least know who is responsible for that. When that is not feasible, we will have to become more and more closed and more like the general internet (default drop everything). Rob

4 years, 10 months

2
1
0 0

Re: [44net] Reverse DNS and access to DNS info

by Rob Janssen

>I am not sure what you mean by feared, but no, my allocations are not supporting the AMPRnet per se. If by AMPRnet you mean the legacy BBS style network of gateways and tunnels. I don't. With AMPRnet I mean what is described on the ARDC pages, not a set of applications and an old way to implement tunnels. So, the net44 address space and its use for amateur radio communications. Use for IRLP would be part of that. But in that case it should be possible to have reverse entries pointing to the callsigns involved. Rob

4 years, 10 months

1
0
0 0

Re: [44net] Reverse DNS and access to DNS info

by Rob Janssen

>The reason I did this was because I needed PTR records in something other than ampr.org. I already feared that it was to conceal non-AMPRnet usage... This makes it all the more important to have zone transfer capability so the data can be used to validate against local policies. Rob

4 years, 10 months

3
2
0 0

Re: [44net] Reverse DNS and access to DNS info

by Rob Janssen

>I manage my systems, and all the HamBSD systems, with Ansible. Some API >would need to be provided to allow me to check the current reverse DNS >record (in the database explicitly, not just by performing a DNS lookup >that may be influenced by caching etc.) and to update the record. I have that fully working using a collection of scripts, but indeed it would be convenient when there was an easier and more modern API for it. As it is now, you can download the zonefiles from an FTP server (or of course you can do lookups at the master server ampr.org at 44.0.0.1) and compile a list of updates (using diff between the downloaded- and the desired info) and then you can create an e-mail message to the ampraddr robot that will do the updates. For this to work you have to have your mail sender address whitelisted. (it used to be an open service until it was abused) Rob

4 years, 10 months

1
0
0 0

Re: [44net] Reverse DNS and access to DNS info

by Rob Janssen

>On 16/06/2020 18:23, Rob Janssen via 44Net wrote: >>/Furthermore, I see that more and more subnets have arranged to delegate />>/DNS to their own servers. / >I had no idea this was an option. Who do I speak to to do this? It'd be >great to have actually up-to-date reverse DNS for my subnet. Why can't you submit updates to the main DNS server? What would be required for you to do so? Rob

4 years, 10 months

4
3
0 0

VK AMPR Co-ordinator

by Gary B

Hi All, For info for those who knew Sam Scafe, VK4AA, who was the Australian AMPRnet Co-ordinator. SILENT KEY: - Samantha Scafe VK4AA Samantha went Silent Key on Saturday March 22nd at home in Cairns following complications from cellulitis interacting with a compromised respiratory system. Samantha had recently been in hospital a number of times but appeared to be improving before her health took a final dive. Samantha was one of the pioneers of Packet Radio networking in Queensland being one of the first to introduce the concept of data wormholes with the Aussie Wide Packet Radio Network. A move from the Gold Coast to Cairns found Samantha’s business become a ISP and Web Host/Design concern, including providing the backup site for the WIA News and QNEWS data files. Samantha and partner Colleen were also well known in autosports circles as CAMS Stewards, with many RadioAmateurs interacting with them at rallies and hillclimbs. Samantha also ran the Cairns APRS gateway for years and provided technical support for repeater builders around the country. The Australian Amateur Radio Service has suffered a great loss with Samantha’s passing and we pass on heartfelt condolences to partner Colleen and family. Vale Samantha Scafe VK4AA, Silent Key. >From Backscatter (Newsletter of the Townsville Amateur Radio Club) As a result, VK needs someone with AMPRnet and TCP/IP kwowledge and experience to volunteer to take on this role. If you think you are able to do this, or know someone who possibly could, please contact Chris, G1FEF asap. Currently VK does not have anyone to do the day to day co-ordination or issuance of 44. addresses. Regards, Gary VK4ZGB

4 years, 10 months

7
6
0 0

ampr.org tls cert expired

by Scott Nicholas

Look's like the Let's Encrypt cert on ampr.org isn't running on a crontab :) -Scott

4 years, 10 months

3
2
0 0

Re: [44net] NSP bugging me to use RPKI for my /24 grant

by Erik Seidel

Tom, It sounds like you're referring to delegated RPKI: https://www.arin.net/resources/manage/rpki/delegated/ I assume this could be done, but it would still have to be set up through ARIN first - just as in the case of hosted RPKI. Regards, Erik KE5SAI On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote: > > Tom, > > It sounds like you're referring to delegated RPKI: > > https://www.arin.net/resources/manage/rpki/delegated/ > > I assume this could be done, but it would still have to be set up > through ARIN first - just as in the case of hosted RPKI. > > Regards, > > Erik > KE5SAI > > On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net > <44net(a)mailman.ampr.org> wrote: > > > > Cynthia, > > > > I only listed them as an example, my point was a having our own CA > > signed by a signing org that is trusted by RIRs. If that be ARIN then > > so be it. More importantly though, as you know, we have a legacy > > allocation. In my opinion we are equal to an RIR but with the ability > > to make global allocations from the 44.0/9 and 44.128/10 space. > > > > --ton/n2xu 44.98.63.0/29. > > > > > > On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote: > > > Tom, > > > > > > As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web > > > PKI, not RPKI, they have nothing to do with this. > > > And not to mention the huge requirements something like that would have, > > > and enormous fees. > > > > > > Not entirely sure what you mean by "act as an IR"? > > > > > >> They would have to accept it much like ARIN and RIPE trust each other > > > In the context of RPKI, ARIN and RIPE NCC do not trust each other, they > > > have their own Root CAs (TALs), which are independent of each other. > > > An RPKI validator has to use both of them. > > > > > > - Cynthia > > > > > > > > > On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <44net(a)mailman.ampr.org> > > > wrote: > > > > > >> CA's like Thawte or Comodo won't work for this, they're for web PKI not > > >> resource PKI. > > >> The 44.0.0.0/9 cert would have to be signed by one of the RIR's trust > > >> anchors (probably ARIN since they have 44.0.0.0/8 assigned to them) > > >> > > >> Thanks, > > >> Q > > >> > > >> > > >> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net < > > >> 44net(a)mailman.ampr.org> > > >> wrote: > > >> > > >>> I've been monitoring this discussion. Since our space was allocated by > > >>> Jon Postel, initially around 1981 (ish), why can't we create our own > > >>> trust model (CA signed by a CA signing agency like Thawte or Comodo as > > >>> examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves > > >>> and publish that trust model to the RIRs? They would have to accept it > > >>> much like ARIN and RIPE trust each other. Then RPKI would work for > > >>> AMPRNet and AMPRNet would control it's own destiny. > > >>> > > >>> --tom/n2xu 44.98.62.0/29 > > >>> > > >>> > > >>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote: > > >>>> I can sympathize with the sentiment that RPKI and widespread RPKI > > >>>> adoption in its current form will really lock out and disenfranchise > > >>>> smaller network operators. > > >>>> > > >>>> Now, *more than ever*, we need to enable an Internet that any > > >>>> organization (a natural person, a registered entity, a hackerspace, > > >>>> etc.) can connect to, uniquely address itself, and begin exchanging > > >>>> traffic. > > >>>> > > >>>> In order to enable such an open system to function, we also need ways > > >>>> of ensuring that unicast addresses are unique and that there is some > > >>>> public, verifiable way of claiming ownership of IP space. Without > > >>>> this, the entire network is open to disruption and abuse by almost any > > >>>> operator. It's amazing we have gotten so far on the good will of most > > >>>> operators. > > >>>> > > >>>> The RIR model of lawyers, paperwork, and public databases works for a > > >>>> lot of people and organizations. IRR was the first step, but it was > > >>>> complex and a bit clunky to use. I see RPKI for Origin Validation as > > >>>> just the first/next step of extending this model of trust and > > >>>> numbering resource ownership into the routing protocol space more > > >>>> directly. > > >>>> From a technical standpoint, this logical extension of systems makes a > > >>>> lot of sense and I don't have a problem with it. > > >>>> > > >>>> For commercial network operators, a RIR registration is just the cost > > >>>> of doing business. > > >>>> But for many small nonprofits, regional amataur radio/network > > >>>> operators, or individuals, a few thousand dollars/euros a year is a > > >>>> lot of money that makes Internet independence out of reach. > > >>>> They end up having to resort to the hegemony of their local incumbent > > >>>> monopoly and chain themselves to the whims of their upstreams and > > >>>> regulators. > > >>>> > > >>>> I suspect many legacy resource holders find themselves in a similar > > >>>> limbo-state of not wanting to participate in the RIR model and pay > > >>>> money for essentially nothing. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Echoing some similar earlier sentiments to want to create a CA for > > >>>> legacy address holders: How feasible would it be to create something > > >>>> RIR-like, but noncommercial? > > >>>> A place for legacy address holders to coordinate and register > > >>>> resources seems like a natural fit. If we're going to operate a > > >>>> database of ROAs, we're going to need some database of address space > > >>>> ownership. > > >>>> For 44net use cases, this seems really straightforward, since we have > > >>>> the Portal to draw from. But for other organizations, it gets a bit > > >>>> more complicated to do properly. Given some random email > > >>>> address/account in some hypothetical legacy RIR, how can we really > > >>>> validate that they're authorized to take actions on behalf of some > > >>>> organization? > > >>>> To take some random examples from the IANA IPv4 list: DISA, USPS, > > >>>> AT&T, Apple, etc. Doing this right is going to take some process, > > >>>> record keeping, and well.... work. > > >>>> With this context, I can see how a lot of RIRs go commercial. However, > > >>>> with a bit of automation, good documentation and records, and some > > >>>> dedicated volunteers, this seems like a really doable/achievable thing > > >>>> in the netops community. > > >>>> > > >>>> I would be curious to know if anyone else shares these views/dreams > > >>>> and would like to chat about it. > > >>>> > > >>>> Stay safe and sane out there. > > >>>> > > >>>> Cheers, > > >>>> jof > > >>>> > > >>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net > > >>>> <44net(a)mailman.ampr.org> wrote: > > >>>>> Thomas, > > >>>>> > > >>>>> You say > > >>>>> > > >>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net > > >> wrote: > > >>>>>> DO NOT participate in RPKI! > > >>>>> And ... > > >>>>> > > >>>>>> We should be protecting our Internet!! Just saying... > > >>>>> What are you really saying? These statements seem at odds with each > > >>> other. > > >>>>> How do you protect your internet? Maybe I can learn some tricks from > > >>> you? > > >>>>> Kind regards, > > >>>>> > > >>>>> Job > > >>>>> _________________________________________ > > >>>>> 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 > > >>> > > >>> _________________________________________ > > >>> 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 > > >> > > > _________________________________________ > > > 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

4 years, 10 months

7
8
0 0

Modem

by Ken Adams

Hi Guys Looking for a UK compatible modem/router/DSL to use with TalkTalk. I can then switch off ALL firewall nat and filtering and pass ALL traffic through to my pfSense router/firewall and allow the usual 4 and 93 and ICMP. Waiting with hope in the heart 73 de Ken (G7OAH)

4 years, 10 months

4
4
0 0

NSP bugging me to use RPKI for my /24 grant

by Jeremy Cooper

Hello all, In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!) Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below: > Hi Jermy, > > We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI. > > > > If you haven't set up RPKI for your IP allocations, here are the steps in a nutshell: > > create SSL key > upload to ARIN > Create ROA (image below) > Thanks, > > Rudy > > HOW-TO on ARIN: > https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair <https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fm…> > I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign. Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request? 73, -Jeremy Cooper

4 years, 10 months

19
34
0 0

pfSense

by Ken Adams

Has anyone got ampr 44net ipencap working.? I have a node running Linux/uronode/ax25/netrom/fbb and ampr-ripd. This then feeds into the pfsense box. AX25/Netrom/fbb are all working fine. I think I have IPENCAP on the firewall directed to the Node 198Lan address. All help very happily received. Rgds Ken (G7OAH)

4 years, 10 months

3
2
0 0

Re: [44net] 44Net Digest, Vol 9, Issue 54

by Rob Janssen

> That vulnerability sounds quite like what alot of us have been saying for years....hummm...73,- Lynwood KB3VWG True! I have mentioned many times that it is best to filter incoming protocol-4 based on a list of valid gateway addresses, and also to filter traffic from those tunnels with filters allowing only AMPRnet addresses (except from amprgw when you use that to receive traffic from internet). We can only hope that this "discovery" and CERT registration will not lead to broad "protocol 4 blocks" by ISPs and transit providers, as has happened with NTP traffic when that was the topic. Maybe another motivation to move from the IPIP mesh to something more modern? Rob

4 years, 11 months

1
0
0 0

Internet access

by Edward Young

Charles, thank you for confirming muy membership in the group. I am very interested in using a ham radio to connect to the internet. What equipment do I need and what do I need to do?

4 years, 11 months

3
3
0 0

Mailing list

by Edward Young

I seem to be on the mailing list but I cannot post anything. Can you send me a link to confirm my membership? Edward Young

4 years, 11 months

2
2
0 0

Re: [44net] 44Net Digest, Vol 9, Issue 54

by lleachii

That vulnerability sounds quite like what alot of us have been saying for years....hummm...73,- Lynwood KB3VWG null

4 years, 11 months

2
1
0 0

CERT Vulnerability Note VU#636397: IP-in-IP protocol routes arbitrary traffic by default

by Chris KE2A

Reference: https://kb.cert.org/vuls/id/636397 OVERVIEW IP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device. Description IP-in-IP encapsulation is a tunneling protocol specified in RFC 2003 that allows for IP packets to be encapsulated inside another IP packets. This is very similar to IP GRE VPNs and IPSEC VPNs in tunnel mode, except in the case of IP-in-IP, the traffic is unencrypted at all times. As specified, the protocol unwraps the inner IP packet and forwards this packet through IP routing tables, potentially providing unexpected access to network paths available to the vulnerable device. An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses. This unexpected Data Processing Error (CWE-19) by a vulnerable device can be abused to perform reflective DDoS and in certain scenarios used to bypass network access control lists. Because the forwarded network packet may not be inspected or verified by vulnerable devices, there are possibly other unexpected behaviors that can be abused by an attacker on the target device or the target device's network environment. IMPACT An unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls. -- 73, Chris KE2A

4 years, 11 months

1
0
0 0

National AMPR Coordinator - info

by Marco Di Martino (IW2OHX)

Hi all, I have to do a formal communication to ARDC regarding the AMPR organization here in my Country. To whom should I address this ? Thanks Regards, Marco iw2ohx

4 years, 11 months

1
0
0 0

Mikrotik help needed

by Ian Redden

Hi All; When trying to connect, the IPIP tunnel on my Mikrotik box is flapping. I am using Mikrotik OS 6.46.6. It connects, shows as registered/running, but after a random period of time, the link goes down. Eventually it reconnects and the entire process starts over again. While connected however, I am able to see the RIP routes. Configuration: /interface ipip add allow-fast-path=no local-address=24.xx1.xx4.44 name=ucsd-gw remote-address=169.228.34.84 Any ideas? Speed Test: https://cogeco-on.speedtestcustom.com/result/baacd8c0-a027-11ea-8085-870a92… Ian / VA3IAN

4 years, 11 months

3
4
0 0

Portal is down

by G1FEF

Heads up, the portal appears to have crashed. Looking into it now… Regards Chris - G1FEF — AMPRNet Administrator

4 years, 11 months

2
1
0 0

WWconvers Hub_NA

by Charles J. Hargrove

Looking to add another dimension to your BBS? Consider offering a chatroom to your users. There are several groups that meet worldwide on various channels, some channels are used locally for events/nets/emcomm and there are some that act as tech support for ham radio software programs. Here in NYC we use 14736 every Monday night as an alternate way to check-in to our weekly emcomm net (especially when encountering jammers). There is even a growing movement to use state or country-based channel numbers that reflect their 44net assignments like 4468 in NY, 4440 in UT, etc. Various packet bbs packages have chat capability built-in. I know of at least one station looking to incorporate it into FBB, but I have no information on that system. Connection to Hub_NA is easy. Use 44.68.41.2 (gw.n2nov.ampr.org). We currently have stations across the USA and Canada connected to Hub_NA. Come join us, ask questions and share your tips/tricks/ideas! -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32 "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

4 years, 11 months

1
1
0 0

Some config error in ampraddr

by Rob Janssen

Since today I get error reply mails from amprgw-adm-owner(a)caida.org on the mail I send to ampraddr(a)gw.ampr.org for DNS updates, which indicate that my mail is somehow forwarded to a mailing list at caida where I am not a member, and thus not allowed to mail: You have tried to post to a list you are not subscribed to. Only members are allowed to post to this list. It appears that the update itself is correctly processed, I get the confirmation mail, but also an error message. Anyone knows what is going on there? Rob

4 years, 11 months

2
1
0 0

Routing from and to the internet

by Elias Basse

I have just completed setup on a ubiquiti router and am wanting to configure a host for some digital radio services behind the router but wish to use the 44 addresses out to the public internet to allow hotspots and repeaters to connect. Is anyone familiar with setting this up? From the server I am able to reach the internet but it is going out through an address from the isp rather than the 44 address. I used the ampr-ripd script from the wiki and can ping other 44 addresses. Hopefully this is possible, I have had my office allow use of some server and network hardware for ham radio. Best Regards Elias Kd5jfe Sent from my iPhone

4 years, 12 months

3
4
0 0

Re: [44net] www.ampr.org

by Rob Janssen

>This may cause address conflicts once the addresses are used by the >purchasing entity. >It is probably best to implement a plan to move the addresses to a new >block. There is no need to move those addresses, they are not in the block that has been sold. Since a month or two we are routing 44.192.0.0/10 to internet (amazon) but this still causes issues as over 4000 systems in the 44.224.0.0/15 block have not yet been renumbered. (I get occasional complaints about systems no longer being reachable) Rob

5 years

1
0
0 0

Re: [44net] www.ampr.org

by Rob Janssen

> To make it work you need to route it via your public GW and NAT, so it > does not leave the router with your 44.x.x.x IP. > I think this is a little bit wrong, not to be able to access the portal > from a random HamNET IP. Well, it *does* work from a net-44 IP but it requires sufficiently well setup of the routing... When you have routing setup from the old days (like "route all 44.0.0.0/8 to the radio network") it will not work. It works OK here from my net-44 IP but still I could envision this would cause problems. E.g. just at the day the portal was down for the move, one amateur here wanted to move his system from the IPIP net to our local BGP routed network and he was unable to delete his gw. So he first setup the GRE tunnel and BGP routing but it did not work due to restrictions at our GW (having both IPIP and BGP does not work) and of course then he could still not reach the portal after it was back up. But he managed to do that from an external IP. Maybe the portal should not be in one of those 44.190 networks that are not supposed to be on IPIP, but it should be in another net-44 subnet that is both BGP routed on internet and IPIP routed on the mesh. Then it would work OK. Rob

5 years

5
4
0 0

Re: [44net] www.ampr.org

by Rob Janssen

> I could move it to a different block (not within 44.190/16) and set it up so that it’s part of the tunnel/mesh as well if folks think that will be better? That should solve the problem for Greg and Brian. For me it does not matter. When you do have an external address (which you should have for IPIP, please don't put a tunnel endpoint on a net-44 address!) you could also consider to put the external address in the DNS entry as well. Or maybe an IPv6 address for each of the systems. Rob

5 years

1
0
0 0

Re: [44net] www.ampr.org

by Rob Janssen

> Hi Rob, > Your browser is caching, clear your browser’s cache and try again. if you go to http it should redirect you to https > Regards, > Chris Now it does. This morning it did not redirect... Thanks! Rob

5 years

1
0
0 0

www.ampr.org

by Rob Janssen

When I visit http://www.ampr.org/ I get a page with only the text "www http" on it. When I visit the https site I get the usual site. Rob

5 years

8
8
0 0

portal down

by Ruben ON3RVH

Hi all, Anyone reported the portal down yet? Can't even read the server hosting it (81.174.235.134) 73 Ruben ON3RVH

5 years

8
10
0 0

Configuring a gateway with Ubiquiti Edgerouter 10x

by Keith Kasin

Greetings, I am trying to set up my Edgerouter 10x as a gateway. When I get to the step ubnt@ubnt:~$ set interfaces ethernet eth0 address <put your AMPRNet network assignment> I enter my allocation 44.18.50.0/28 and get an error. I can set 44.18.50.1/28 or just 44.18.50.1 however this does not yield a route when I enter the “show ip route” command. Should I be using my broadcast address, 44.18.50.15 in this position? I am sorry if I sound dense here so any guidance is appreciated as I work my way through this set up. Thank you, Keith AI6BX

5 years

2
1
0 0

Returning YV.

by Gabriel Medinas

Greetings to all, just to inform you that returning to teamwork at AmprNet, Venezuela is connected again, renewing some things in my local structure with the JNOS Linux program through yv5kxe.ampr.org (44.152.0.60). We are especially grateful to Chris - G1FEF who personally granted the possibility of this YV return on this network after 20 years. We are in settings, I am mainly working to adjust my old JNOS to the new dynamic of AmprNet especially to the RIP44d update that does not work in JNOS doing it manually, I am working on a project to use other compatible hardware to achieve other gateways for use APRS and the DXCluster yv5kxe. 73 de Gabriel YV5KXE yv5kxe.ampr.org

5 years, 1 month

4
3
0 0

Ubiquiti AMPR-ripd

by Elias Basse

Is anyone familiar with ripd on the ubiquiti series of routers? I have a test device edgerouter pro that I am attempting to get working however I am unable to route through the ipip tunnel that has been built per both wiki articles. Any pointers would be appreciated. Many thanks, Elias Sent from my iPhone

5 years, 1 month

1
0
0 0

BGP annuncement of same address Block from 2 sites ?

by R P

Hi there Is it possible to announce same Address Block from two different sites ? with preferred way for one site ? The idea is to have redundancy in case that one site connectivity fail the traffic will pass to the other site automatically Both site will be connected by radio as well so Network connectivity will not stop I know that BGP support it is it also the way in the AMPRNET BGP announcement ? Has anyone done it ? or doing it in the AMPRNET community ? Thanks Forward Ronen - 4Z4ZQ

5 years, 1 month

3
2
0 0

BGP Announcment Procedure

by R P

Hi there Who deal today with BGP announcement procedure ? We want to start announce part of our 44 net BGP i started the procedure with Brian who take care of it now ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org

5 years, 1 month

2
1
0 0

Re: [44net] Large increase in inbound suspicious traffic from public internet to systems on 44 net?

by Rob Janssen

> On Thu, 2020-03-12 at 11:30 -0500, Shawn M Garringer via 44Net wrote: > > I am wondering if anyone else is seeing the following: starting on 5 > > March 2020 and continuing through the present I have detected a large > > spike in inbound traffic to several of my AMPR 44 IP addresses (on > > 44.50.1.0/24). The spike has been large enough that my logging ELK > > stack is struggling to keep up. > A good number of folks have seen a spike in scans by botnets spoofing > IPs but not just on 44-net. Commercial ISPs have seen similar spikes of > traffic and have taken proactive measures to try and halt these brute > force attacks. I see no visible increase in the traffic graphs for our internet gateway, but of course I do confirm that there is a continuous stream of port scanning going on, partly from individuals and partly from jerks like censys.io, shodan.io, stretchoid.com, binaryedge.ninja etc etc who are continuously scanning the internet for vulnerabilities and keep searchable databases where their users can instantly locate who is running e.g. a MikroTik router when there is a new known vulnerability (of course only when it its firewall is not properly configured). All this together is responsible for 1-2 Mbit/s of traffic on our /16. So yet, it is quite noticable. Of course we do not log all that, but we do have some auto-block features that trigger when people scan for wellknown ports (like mentioned above) within unassigned address space. Rob

5 years, 1 month

2
1
0 0

Large increase in inbound suspicious traffic from public internet to systems on 44 net?

by ampr＠shawngarringer.org

Hello group, I am wondering if anyone else is seeing the following: starting on 5 March 2020 and continuing through the present I have detected a large spike in inbound traffic to several of my AMPR 44 IP addresses (on 44.50.1.0/24). The spike has been large enough that my logging ELK stack is struggling to keep up. This traffic is coming from the public internet. Most of these are looking at standard ports 443, 80, 25, and 22. These are being directed to IP addresses in my subnet that are not in use, and therefore are being dropped (but logged) at the firewall. Nothing is running on these IPs so there is no way the traffic is in response to anything I can find coming from my network. I realize devices periodically scan the "entire internet" but this is more than that... in one day I saw 100,000 TCP SYN from a single public IP address. That is a significant spike and I am not certain why they sent so much traffic from a single IP to a single IP. Wondering if anyone else is seeing the same? 73 DE KC0AKY

5 years, 1 month

7
9
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

> So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. > Can you elaborate on the traffic that isn't, please? > Is this traffic from another operator...or a non-operator? > Can you also elaborate if this traffic forwards in any cases? As I explained before, what I sometimes DO see is IPIP traffic from gateway A.B.C.D with an internal packet with source A.B.C.D and destination 44.137.X.Y (inside our network). That traffic should have been sent with source address 44.P.Q.R in the internal packet, where 44.P.Q.R is the net44 address of that specific gateway at A.B.C.D. As I got repeated logs in the firewall of these occurrences (one was from a Polish gateway, I remember) I added a firewall rule to allow such traffic. The reply will of course be routed directly over internet, not via the tunnel, so it is questionable if the connection would get established. Probably not, when the user has the typical stateful firewall on his internet connection. Yesterday I have removed the extra rule and I am watching the firewall log, but I have not yet observed another instance of this error after about 12 hours. So maybe some people have woken up and fixed their config already. Rob

5 years, 1 month

1
0
0 0

Re: [44net] Security - Nested IPIP

by lleachii＠aol.com

Rob, You stated: So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. Can you elaborate on the traffic that isn't, please? Is this traffic from another operator...or a non-operator? Can you also elaborate if this traffic forwards in any cases? That's what we're tying to stop. Please note, I haven't identified this is related to any IPENCAP issue specifically (except that it appears we may have some operators that forward traffic not destined for them). While I understand your concern, I'm not sure it's related to IPENCAP 100%. 73, - Lynwood KB3VWG

5 years, 1 month

2
3
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

> I'm now wondering how such a config is [incorrectly] made (i.e. the inside Header has the incorrect SRC)....likely because of no route policy...another discussion... Easy: when you take a default Linux system and add something like IPIP mesh with routes in the same table, and then you run services on the same system, an outgoing connect to a system within net44 will just consult the routing table, find an outgoing route and make a connection. You then have to rely on the "source address selection" done by the system, which may select your public IP as the source address. This may also be configured in the service itself (when the socket is not bound to 0.0.0.0 but to some specified address). The outgoing connect will now be routed through the IPIP tunnel, but it will have the public address as the source. To prevent this, the service would have to be bound to the net44 address, or it would have to be set as a default source address in the tunnel routes in the table. When you run a separate system as the IPIP router and an AMPRnet services host, you do not run into this problem because the services host has the proper external address within net44 and the router will not change it. But with both combined in a single host, you can still get it working correctly when you pay some attention. Which of course has to be done when you want a single system that can both be a general-purpose internet browsing system (directly via your ISP connection) and can be an AMPRnet services host at the same time (also for services available from public internet addresses). The routing has to be carefully set up when doing this, and setting a preferred source address is only part of that. In our network the problem you mention w.r.t. AMPRGW does not occur because internet traffic is routed directly to our gateway, not via an IPIP tunnel. The IPIP tunnel via AMPRGW only gets public internet traffic when our BGP announcement is down for some reason, that is why I kept it operational but it normally has zero traffic. So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. When I "just drop" the bad traffic it appears in a log and it appears the originators of the traffic do not notice it, so it goes on and on. As I mentioned, I sent mail to gateway owners about it, but it rarely fixes the situation. Rob

5 years, 1 month

1
0
0 0

Re: [44net] Portal/Wiki text

by Rob Janssen

> One minor thing to bring up though, since I went and re-read the text. It says > "ISPs don't configure their routers with publicly routable IP space for end users, why would you?" > This is by and large false. Some do indeed use 1918 space for customer facing interfaces, but most do not, as this practice this can break PMTUD due to dropping PTB messages sent by 1918 numbered interfaces and is not generally not recommended. It looks like this came from the HamWan people who apparently use a lot of RFC1918 addressing, I think at first even their whole network was on RFC1918 space and they introduced net44 capability only later. However, in our network here we exclusively use net44 addresses, also for links and routers. Of course we do have appropriate firewalls in place. The first line of defense is that at the internet router, all incoming traffic is blocked by default unless the destination is from an address list of only systems that provide services that are to be visible from internet. And in the last router before the actual system there is an additional firewall that opens only certain ports for everyone, and restricts management ports to another address list that has only addresses of known operators, or at most the country subnet. This makes the result similar to using RFC1918 addressing (which provides protection because it can only be routed locally), but without the disadvantages that you mention. Anyway, I am not that much concerned about that part of the text, it will depend on local policies and we do not use that method of subnet allocation anyway. My main concern at this time is that "outsiders" (not licensed radio amateurs) apparently find our network in their search for IPv4 address space, and make requests that we have to reject. This rejection often leads to discussion (partly because there is no terminate-this-request option in the portal, a coordinator can only accept it or send it back to the requester for more detail). Therefore I think it would be best when those outsiders immediately see that this system is not for them. Rob

5 years, 1 month

2
1
0 0

Re: [44net] Security - Nested IPIP

by lleachii＠aol.com

Rob, I now understand what you meant by this. I'm not seeing [lots of] improper Header 1 traffic with a known gateway IP as a SRC IP (and if I do, I want to block as it's asymmetric, as I tax AMPRGW on the reply trip). I receive the packet from AMPRGW (i.e. they're using the Public Internet instead of AMPRNet to reach the NTP server). * AMPR <> AMPR (OK, This allowed - as I list this service to my subnet in the Wiki) * Registered_Public <> Registered_Public (OK; but closed for MOST services) * Registered_Public <> AMPR (OK, not announced, taxes AMPRGW - may close soon; closed for some services) * Tunnel (Header 0) <> Public IP (Header 1) (NO - I consider this a crafted packet or improperly configured gateway, creates asymmetry; and taxes AMPRGW on the reply) - but cannot be mitigate except by blocking registered gateways on the de-encapsulated side of tunl0 I would advise you block that traffic with an improper Header 1 from registered gateways of you flag it via Header 0. But this discussion now causes me to recall discussions we've had before on: 1.) the security of seeing the Registered Public IP on both sides of the tunnel 2.) policy-based routing and the need to separate routing tables comes to mind....this comes from operators' failure to set that up. I'm now wondering how such a config is [incorrectly] made (i.e. the inside Header has the incorrect SRC)....likely because of no route policy...another discussion... Just note that bad IPENCAP is not the majority of bad traffic we're seeing on some nodes...in fact, bad IPENCAP is the least of this traffic (at least now). - KB3VWG Unfortunately this breaks legitimate traffic because some gateways are incorrectly configured (as I mentioned before) and send tunneled traffic with their own external address as source address, instead of the AMPRnet address assigned to the gateway. So such traffic is accepted as well here (i.e. traffic with a source address of one of the gateways)

5 years, 1 month

1
0
0 0

DNS procedures/process

by Elias Basse

Are there any updated dns procedures with regards to coordinators? I have a new coordination and haven’t done it in a while and can no longer find the email with the procedure for adding dns. At one point I thought this was in the portal. Best Regards Elias Kd5jfe Louisiana AMPR coordinator Sent from my iPhone

5 years, 1 month

2
1
0 0

Re: [44net] Portal/Wiki text

by Rob Janssen

> The relevant page has been updated with your suggested dialogue Thanks! It is at least an attempt, let's hope it works. Other coordinators beware: there is a hosting company owner from the Netherlands that is apparently shopping for a subnet. After I rejected him, he tried in Germany. Rob

5 years, 1 month

4
3
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

> Please keep in mind though, the malicious traffic I observed did not originally come from AMPRGW. I originally observed the nested IPENCAP traffic from a Polish Public IP that's still currently registered as an AMPRNet gateway. As you know in later Linux kernels it became more difficult to see the outer header of the IPIP packet in a firewall rule handling the tunneled traffic. To circumvent that, a couple of years ago I added a rule to the firewall that sets a packet mark on traffic received from AMPRGW (matching the source IP in the outer header). This packet mark can then be checked in the firewall for the tunneled traffic. Source addresses outside AMPRnet are only accepted when the packet mark is set. Unfortunately this breaks legitimate traffic because some gateways are incorrectly configured (as I mentioned before) and send tunneled traffic with their own external address as source address, instead of the AMPRnet address assigned to the gateway. So such traffic is accepted as well here (i.e. traffic with a source address of one of the gateways) We really should abandon the IPIP tunnel mesh and move on to something a bit more secure (and easier to use on modern equipment)... Rob

5 years, 1 month

1
0
0 0

Re: [44net] Portal/Wiki text

by lleachii＠aol.com

Rob, The relevant page has been updated with your suggested dialogue: http://wiki.ampr.org/wiki/Requesting_a_block 73, - Lynwood KB3VWG

5 years, 1 month

1
0
0 0

Re: [44net] Security - Nested IPIP

by lleachii＠aol.com

David, 1. OpenWrt is Linux; and my previous gateway ran Ubuntu Linux (no *nos) - I cannot speak to other Routing Planes running IPENCAP tunnels. Also note machines running tnos have the machine's kernel and userland software to possibly interact with a packet. I only surmise without firewalls, some of the basic routing concepts apply to other Network Operating Systems too. 2. We're running AMPR gateways, so routing would be ON - I'm lost at the remark about IPv4 Forwarding = OFF. It seems as if you're suggesting to "disable routing on the router". I can only speak for Linux-based devices that are also performing functions as an actual router. Servers (i.e. with net.ipv4.ip_forward=0 and net.ipv6.ip_forward=0) merely receiving all of your IPENCAP packets should not apply here. Even when I originally ran a Linux server as my APMRNet device - downstream of my border router, I still had a /24 (253 other usable IPs) - so I've always had the need to route some IPs. You asked: Are these users trying to break into our AMPR hosts due to gaps in our firewalls or are they exploiting incomplete firewalls to use them as relay hosts to SOURCE attacks out on the Internet? Answer: Both are logically possible with an unfirewalled router or device and/or policy route isolation of the interfaces (in the case of a router). I described a scenario where a malicious actor can use the asymmetry of the routing to get a login screen (e.g. of your router or server) only accessible locally. It also seems as if DDoS is a consequence, or the modus operandi, of some traffic (e.g. TCP reflections cause 100% open connections at the router or a machine). 2b. These would be firewall rules to mitigate. 3. I have provided: tcpdump outputs and netflow records, the tcpdump command to observe the nested IPENCAP and a netflow log of a packet which (had it not been firewalled) could have double routed across my device - let me know what additional filters are needed. Also, the device running the dump must be your registered gateway (to which these actors are directing the traffic in this discussion), not a random device on the Internet. https://linux.die.net/man/8/tcpdump Nested IPENCAP: tcpdump -vvv -n -i tunl0 proto 4 I haven't thought of a tcpdump to observe all Header 1 routing - as the vice versa SRC/DST could be valid in some instances - this command only shows traffic entering or exiting tunl0 without your IP...it will also hit FALSELY on the RIP44 packets, hence the last part: tcpdump -vvv -n -i tunl0 src net not 44.60.44.0/24 and dst net not 44.60.44.0/24 and not host 224.0.0.9 4. I have posted the Second header scenario and it's remains available at the Wiki page. There should be no 3rd header scenario - that's the malicious activity the Second Header firewall rule blocks. http://wiki.ampr.org/wiki/Firewalls (and see previous emails on this topic) - FYI, there's nothing 44net-specific to the rules I suggested - # THIS PREVENTS NESTED IPENCAP (BCP 38) iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP HTTP Rule (OpenWrt syntax - iptables-based): config rule option target 'ACCEPT' option proto 'tcp' option name 'AMPR_WWW' option family 'ipv4' option dest_ip '44.60.44.10' option dest_port '80' option src '*' option dest 'amprnet' option extra '-m limit --limit 25/minute --limit-burst 100 -j ACCEPT' Block first TCP packet not SYN (again, OpenWrt syntax - iptables-based): config rule option proto 'tcp' option name 'Block_In_Not_SYN' option src '*' option target 'DROP' option extra '! --syn -m conntrack --ctstate NEW' (Also the normal SYN Flood and INVALID rules). 5. Yes you can have DNS records and not receive traffic from AMPRGW - just block it and/or remove its route. Following the Wiki (for an Linux or OpenWrt setup), the only allowed traffic from anywhere by default are routes from AMPRGW, so long as the machine's default iptables rule is drop or reject. So it's alarming to hear inquiries like this. This will not stop the actual IPENCAPed packets from the Internet via AMPGW for the IPs in the DNS zone. Please keep in mind though, the malicious traffic I observed did not originally come from AMPRGW. I originally observed the nested IPENCAP traffic from a Polish Public IP that's still currently registered as an AMPRNet gateway. 73, - Lynwood KB3VWG

5 years, 1 month

1
0
0 0

Re: [44net] Security - Nested IPIP

by lleachii＠aol.com

All, I wanted to make 2 notes regarding: dynamic IP addresses and AMPR TCP-based services. * An operator mentioned that it may perhaps be malicious dynamic IPs (no longer used by the operators in question) that are sending this traffic...I also think the [malicious] experience "via RIP[44]" had not occurred was noted... Since my gateway is in fact dynamic and still seeing issues...wouldn't it be prudent for those operators that are monitoring AND FIREWALLING their gateways to identify the rogue gateways for removal and dropping? Because, if they're rogue operators...**we now understand how our routes are being leaked**...as they are successfully relocating my new Public IPs (even though I'm dropping routing traffic and IPs out of tunl0 that != my allocation). * All operators running TCP services should ensure they are not reflecting SYN-ACK packets and/or experiencing half-open connections on the router and server as a result. Firewalling new TCP connections CONNECTION_STATE not SYN (unless you expect such traffic) and burst rules help. In OpenWrt, such activity can be easily seen on the Overview Page upon login at "Active Connections" graphic. ** I suggest as an extreme measure for those who have not blocked IPENCAP on tunl0 only to operators in the past - to do so; and/or renumber their router interface(s) possessing AMPR IPs (the IP does not need a DNS record if it doesn't need access from AMPRGW/Public Internet). This mitigates the malicious actors' ability to perform nested routing on your device. ** It is now apparent that 2nd and 3rd headers need to be properly firewalled on all gateways running IPENCAP. Be vigilant. ** Please make sure no internal LAN devices were compromised (thru asymmetric traffic that may have allowed a malicious person access to LAN machines). ** Nested IPIP can be firewalled (i.e. Header 2 - the third header); but there is no known solution to receiving a packet with a malicious Header 1 (i.e the second header - which could be expected to reach any device on Earth with a Public IP). Properly firewalling and monitoring traffic that you allow into your 44network (with 44net IPs) is important. ** If anyone running a Linux-based router can WireShark/tcpdump and observe MAC addresses directly on their tunl0, please let me know. This is believed a hash of the 4 SRC/DST IPs of Headers 0 and 1 - which could be used to authenticate traffic from gateways that != AMPRGW. 19:39 UTC 23MAR2020: 269 11.96 KB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop 844 76.12 KB zone_amprwan_dest_DROP all * * !44.60.44.0/24 0.0.0.0/0 - Drop-AMPR_OUT_InvalidSRC This is ~30 seconds of traffic of drops from my router to forwarding of invalid Header 1 receipts. The first rule is all traffic from you in which KB3VWG != DST IP; and hence you asked me to route it for you. (I only allow this by coordination). It should be 0. I should note the second rule includes drops from my AMPRLAN that != bogons - but should otherwise be 0 too (e.g. unfirewalled, the packets could forward to BGP 44 IPs that exist on an operator's routing table as "properly NATed traffic" from an allowed gateway). 73, - Lynwood KB3VWG

5 years, 1 month

2
1
0 0

Portal/Wiki text

by Rob Janssen

Can someone please add some explanatory text to the relevant portal and wiki pages that inform the visitor that AMPRNet is a closed network that is only accessible to licensed radio amateurs. I got another of those requests that come from people that are just after some free IP space and submit an allocation request through the portal using some "handle" like used on whois as their "callsign". They probably find us using some search and then land on portal.ampr.org, make an account and file an allocation request. When walking that route, there is no information at all about the target audience, all information is just geared towards "how to request IP space", which they do. In the latest case, when I rejected the request saying it is only for licensed amateurs the request was re-submitted with a callsign which is not assigned to the person making the request. He probable searched again to find what licensed radio amateurs are and found some callsign that he then added to the request. (not knowing that we can do reverse lookups on those) They should at least at some point encounter some text that explains them that this network is not for their hosting purposes. Rob

5 years, 1 month

1
0
0 0

Security - Nested IPIP

by lleachii＠aol.com

All, The following are RAW firewall hits indicating nested IPIP in IPIP packets. I run a firewall that only allows IPIP from all of you (and rules that only allows the AMPRGW routes and my destination IPs); but since this is a RAW rule - it implies nothing of any operator. I have not reviewed my Netflow records; but please be vigilant of this traffic. I warned of this issue in the "ancient" 44 mailing archives. Table: RawChain PREROUTING (Policy: ACCEPT, 94829408 Packets, 59.38 GB Traffic)Pkts. Traffic Target Prot. In Out Source Destination Options Comment32 2.37 KB DROP 4 tunl0 * 0.0.0.0/0 0.0.0.0/0 - - 73 ::and elbow bump::, - Lynwood KB3VWG

5 years, 1 month

4
18
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

> * Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may disable your access thru AMPGW in the future, as it's announced as "AMPR-only") Unfortunately it is quite common for gateway stations to send tunneled traffic towards 44net addresses (via IPIP) with a public IP as the source. I normally block all such traffic, except when the public IP is the gateway public address (as I got tired of trying to reach sysops where this error was present). People *should really use* proper source address selection and policy routing and NOT send tunnel traffic with other than 44net traffic (both source and destination) inside it to any gateway station except by prior agreement. (e.g. AMPRGW can send traffic from a 44net address to public destination addresses, and so can some gateways) To make life easier, DO NOT TRY to setup a gateway on the same system where your applications are also running, unless you have good knowledge of networking configuration and know about such concepts as policy routing (ip route rule, multiple route tables) and setting a preferred source address in a route. When you use a separate router and application machine, such errors are much less likely to occur, and configuring the firewall is also much easier. Get a separate Pi or MikroTik or whatever to run your gateway, and then have a PC or another system to run your BBS or conference or whatever you want to run on AMPRnet! Rob

5 years, 1 month

1
0
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

> Those with a dynamic address CAN participate as their public gateway > can now be a FQDN for their dynamic service. I have some within the > New York State subnet (44.68/16). The issue is that IPIP tunnels have to be validate with their external address for at least SOME security, and this means that when the address changes there is nothing else we can do than drop their packets until the change comes through the portal and RIP system. With a system that has those dynamic addresses connect only to one or two VPN routers in a secure manner (e.g. L2TP/IPsec) we would not have that problem. Also, those address changes would not be important to other systems on the network. Out of the 561 registered gateways, we only ever receive traffic only from 73 of them. (the others could be either inactive or not be sending traffic to the Netherlands) Their address changes would not be important to us. Rob

5 years, 1 month

1
0
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

> The spoofing is happening on GRE too...GRE was first. But with the GRE/IPsec and L2TP/IPsec tunnels spoofing is impossible. Rob

5 years, 1 month

1
0
0 0

Re: [44net] Security - Nested IPIP

by Rob Janssen

For a long time now, I have been allowing IPIP only from registered gateways and disallowed nested IPIP. Indeed I have seen in the past that IPIP packets were sent with the intention of being forwarded through "allow trusted subnets" rules and then maybe back out to internet hosts that were targeted for DDoS or similar. When looking in the logs of those rules, I usually see dropped packets from hosts that are apparently on dynamic addresses and have changed address, but this change has not yet reached me through the ampr-rip announcements. However, there are indeed also instances of apparently unrelated intrusion attempts. It remains my position that we should change from this IPIP mesh to a more modern VPN system where stations with dynamic addresses can participate through a local VPN server that participates in a network that uses standard protocols to form a dedicated AMPRnet tunnel network with automatic routing, that can be used by standard equipment and can be made more resilient against unwanted use (e.g. by using GRE/IPsec and L2TP/IPsec tunnels instead of the traditional IPIP). However, I no longer want to beat a dead horse. We had the discussion a while ago but unfortunately it was then redirected onto a separate mailing list. Rob

5 years, 1 month

2
1
0 0

Venezuela AmprNet

by Gabriel Medinas

Greetings to all the other colleagues and friends, I am Gabriel Medinas YV5KXE from Caracas, Venezuela. For years (20 years) I have been coordinator of the AmprNet network for Venezuela with assignment 44.152.0.0 / 16 trying to assign and maintain the network of radio amateurs on network 44. For some unknown reason, I do not have access to this coordination and I use this route to try to communicate with people who can help me restart the Amprnet network through my gateway in Caracas yv5kxe.org. and with the knowledge of the pass way of Brian Kantor, the communication has been more complicated for me. I have register in AmprNet Portal and have register my Gateway yv5kxe.org Jnos linux 2.0j, telnet port 2332, Convers, DXcluster, Netrom link USA (laxnet), Caracas City. I appreciate any help in solving this problem in the sense of being able to restore the service over the local networks of Packet Radio, CONV, and NetRom. Thank you. Gabriel YV5KXE 4M5G gmedinas.com

5 years, 1 month

1
0
0 0

Hub_NA Changes

by Charles J. Hargrove

With the shutdown of the WA7V system after a long and dedicated stretch, Hub_NA of the WWconvers needed a new home. With the help of WA7V and testing with KD6OAT, Hub_NA is still functioning but with a new IP address of 44.68.41.2 (gw.n2nov.ampr.org) on port 3600. The software also has the capability to make use of IRC clients that we might get included in a future version of JNOS. All bbs sysops in North America are welcome to connect their chat clients and servers to Hub_NA and join the rest of the WWconvers network. There is plenty of room for specialized convers channels. For the 44Net allocations in NY State (44.68/16) I suggest a common channel of #4468 to chat among ourselves. -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32 "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

5 years, 1 month

6
10
0 0

MTU standardization for tunnels?

by Rob Janssen

In our local network we have several different kinds of tunnels, with different header overhead. As the usual MTU on an internet connection is 1500 (the ethernet MTU), the typical MTU for an IPIP tunnel is 1480, for GRE it is 1476, for GRE6 it is 1454, etc. However, not everyone has a 1500 byte internet MTU. Some people have PPPoE connections to internet with MTU of typically 1492, sometimes 1480. So the effective MTU of the mentioned (and other) tunnel types becomes 8 or 20 bytes less. Some people get a fixed address subnet from their ISP and it is provided as some tunnel with an MTU of 1456 (quite common here). This results in a wide variety of MTU values in our network. Frequently issues arise for new connections where the chosen MTU for some tunnel turns out to be too large, and full-size packets are dropped. And in an environment where those tunneled packets encounter a point where the outer packet is too large for the interface MTU, the usual mechanism of returning "ICMP destination unreachable, fragmentation required" does not work very well, because the ICMP is returned to the router that encapsulated the packet, not the original source of the traffic. And I have never seen an encapsulating router that translated the ICMP to a new ICMP packet referring to the inner addresses and sent it back to the original source. Also, there are sometimes issues when routes are changed by BGP. Of course many routers have TCP MSS clamping configured where the TCP MSS is reduced whenever the TCP SYN passes through a place with lower MTU, but this happens only on the initial connection setup. When the MTU later reduces due to a route change, this still results in failure of the connection. I wonder if other gateway operators have done something to alleviate this problem. Solutions that can be considered: - ignore DF. much of the current TCP traffic has DF (don't fragment) set, but this often causes communications to unnecessarily break. Without DF, packets would be fragmented as originally designed in the IP protocol. sending everything with DF and interpreting the ICMP responses is the mechanism behind "Path MTU discovery", which was designed to avoid fragmentation and the overhead it causes in routers. however, in the AMPRnet we seldomly encounter so much traffic that CPU loading of the routers is an issue. - standardize on a "default MTU" whenever we cannot offer a 1500 byte MTU. this does not solve all problems, but at least it solves some of them. Note that most routers fragment packets in a particularly inefficient way. When a packet a few bytes too large for the next hop has to be forwarded (and DF is not set), they will not split the packet in two approximately equal halves, but rather they send a first fragment as large as the outgoing MTU can accept, then a small fragment with the remainder of the original packet. This can result in multiple fragmentations along the way: first it has to be fragmented to fit into a 1480 byte MTU of an IPIP tunnel, then further on it has to be fragmented again to fit a GRE or L2TP/IPsec tunnel with smaller MTU. Whereas no further fragmentation would be required when it had been split in equal halves the first time. So, I wonder what others do (if anything) to avoid the problems caused by oversized packets and maybe to avoid fragmentation. For some time, I have experimented with "ignore DF" and of course it keeps traffic flowing, but it is unclear if it causes problems for some users. Next I would consider to use a standard MTU value on all tunnels, so there are mostly two MTU values left in the network: 1500 and that smaller, to be determined, value. Of course the MTU should not be so low that it causes terrible overhead. In the past we had a 256 byte MTU on AX.25 packet radio (or even 216 when it was over NET/ROM), but that causes a 15% header overhead and made us very unpopular amongst plain AX.25 users. Fortunately the WiFi links we use today allow 1500 byte packets :-) The minimal required MTU for IPv6 is 1280. The maximal MTU we can accomodate with the worst case tunnel headers is about 1400. So the preferable default MTU would be somewhere between 1280 and 1400. Are people even using 256-byte MTU links today? Would it be worth it to select an MTU value that can be more efficiently fragmented into 256-byte packets? Or is there another small MTU size that would be a candidate for such considerations? So again, I wonder what others have done w.r.t. this matter. Are admins of gateways that offer many kinds of different tunnels using a standard MTU in their systems, or just the max MTU that each tunnel technology allows? Do you copy DF from the inner to the outer packet in a tunnel? Do you ignore DF? What would be your position on establishing a standard MTU for tunnels, and what size would you propose? Rob PE1CHL

5 years, 2 months

2
1
0 0

Auto Reply

by William Bressette

Auto Reply to Test EMail Titled [44net] Consider some tests

5 years, 2 months

1
0
0 0

Consider some tests

by lleachii＠aol.com

All, I have a question to ponder again. In preparation for emergencies, I wanted to consider some of the following. - Passing traffic thru another GW, we can use the test/example subnet - If AMPRGW at USCD is unreachable, could we have other capable devices that elect between themselves and announce the routes from Chris' server? - Can we test the redundancy of Chris' route server from whom they elect and receive - I'm not sure if anyone is doing AX.25 to IP or vice versa; but I would like to try - I'm curious if anyone has compiled kissattach and all utilities compiled; etc. in OpenWrt to connect a TNC and radio - I want to do an end-to-end test (I recall someone offered me a makefile for some libraries) - I want to migrate my base APRS radio to the router. I recall I have libax25 compiled... 73, - Lynwood KB3VWG

5 years, 2 months

1
0
0 0

Re: [44net] Seeking BGP Guru

by lleachii＠aol.com

All, I think there's big confusion here between what's called in the industry "Settlement Free Peering" and "paid transit services." Comcast offers "Ethernet Dedicated Internet" service in my area (Washington, DC). They offer: Static IPs, DHCP and a BGP session. In this service, Comcast will not allow the user to BGP to a third party with the intention to use Comcast for carrying the 3rd party's traffic. This is simply called "paid transit service". When we refer to getting a BGP session with another AS for AMPRNet, look for "BGP transit service" plans. Peering would be considered traffic between Comcast and another large ISP (i.e. the peering agreement would be relevant if e.g. USCD - AS7377, wanted to peer with Comcast). That's called [settlement free] peering (in a Tier 1 ISP's terminiolgy). About the product: https://business.comcast.com/enterprise/products-services/data-networking/e… For a list of cities with the product: https://business.comcast.com/enterprise/products-services/data-networking/m… 73, - Lynwood KB3VWG

5 years, 2 months

3
2
0 0

Re: [44net] Message for Chris, G1FEF about 44.135.92.8/29

by Bob Tenty

I replied to you from my gmail address Bob On 2020-02-24 17:27, G1FEF via 44Net wrote: Bob, nothing received from you. I have sent you an email, please reply to if or let me know here if you don't receive it. Regards, Chris

5 years, 2 months

1
0
0 0

Re: [44net] Message for Chris, G1FEF about 44.135.92.8/29

by Bob Tenty

Chris, I wrote you an email from my address as listed in the portal. Hopefully you received it this time. Bob On 2020-02-24 07:24, G1FEF via 44Net wrote: Hi Bob, On 24 Feb 2020, at 12:14, Bob Tenty via 44Net <44net(a)mailman.ampr.org> wrote: Chris, Sorry to write you in this way but I tried to reach you since the end of October of last year with emails without any reply. Also an email from the portal itself received no reply Please email me here: chris(a)g1fef.co.uk that should reach me. Thanks, Chris

5 years, 2 months

2
1
0 0

Message for Chris, G1FEF about 44.135.92.8/29

by Bob Tenty

Chris, Sorry to write you in this way but I tried to reach you since the end of October of last year with emails without any reply. Also an email from the portal itself received no reply I need the follow change. I route and have an entry for the subnet 44.135.92.0/24 Ron, VE3CGR wants to route the 44.135.92.8/29 part himself. He is registered in the portal. Can you add 44.135.92.8/29 to this entry? Please leave the rest of my 44.135.92.0/24 subnet intact. Many thanks, Bob (Boudewijn) VE3TOK -- There is nothing permanent except change Heraclitus

5 years, 2 months

2
1
0 0

Seeking BGP Guru

by William Lewis

Good evening. I am looking for someone who would be an expert in BGP and using Comcast for the transport. Please contact me off list. I have some questions I'm looking to get answered. Thank you, William Lewis / KG6BAJ wlewis(a)myhostingsource.com * ------------------------------------------------------------------------ * This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited. Wm Lewis

5 years, 2 months

7
6
0 0

ARDC response re BGP portal management

by John Gilmore

Quan Zhou via 44Net <44net(a)mailman.ampr.org> wrote: > Hi all, > Sorry to bother you with a rant, but I'm feeling an urge to ask that what's happening on the AMPR/ARDC. Thank you for your rant. > ## Background > A few weeks ago I have received a harsh email from Chris G1FEF accusing me for announcing a prefix was assigned to me. In that case, the claimed reason is that the prefix wasn't listed on the AMPR portal. > I tried to clear things up by sending him the LOA from WB6CYT, which he claims that is NOT legitimate, also denied possibility there could a bug in the portal caused this. I have also complied with his demands on even more information including all conversations between me and Brian regarding that the assignment. Eventually he continued to ask for even more personal information without justification, threatening that not complying may cause "close of account". > ## Questions > 1. Has all previous assignment by WB6CYT been overruled? Or am I singled out? Previous assignments by Brian (WB6CYT) have not generally been overruled. Brian took very seriously his duty to both make space available to real amateur radio operations and to deny space to opportunists trying to poach the space for commercial, personal, spam/malware or other purposes. Many people requested assignments, and most of them received assignments. Those assignments are and were recorded in the ARDC portal, which was initially programmed by Chris (G1FEF), and operated and evolved by both Brian and Chris. The data in it was supplied by Brian, by net44 users who register to receive allocations, and by the volunteer regional coordinators who make allocations. Any collection of detailed allocations too complicated to fit in one person's memory or on the back of an envelope needs a definitive register that provides the collective memory of all the past decisions. The portal was and remains that definitive register. If your allocation is not in that register, then we'd need to figure out why it isn't. The ARDC Board has access to some of Brian's stored email, as well as backup dumps of the Portal databases, so we can do some searching among those if needed. So far, your rant did not mention the particular IP address allocations involved, so we have had little information to start from. Most allocations are made via country-based and region-based volunteer coordinators, who all have portal accounts with permission to make sub-allocations in their region; Brian did not have to adjudicate most of these. Apparently your allocation is from the China subnet, and apparently Brian was still handling those allocations. My guess is that he did not have a volunteer coordinator for China who both had sufficient experience and that Brian trusted to do the job well. > 2. What are the current rules on allocation now? A snapshot of the latest version of ToS is at: https://web.archive.org/web/20190731094938/https://www.ampr.org/terms-of-se… -- It does not requires personal information beyond ASN addresses. The current rules on allocation have not changed. However, Brian is no longer with us to make decisions based on years of expertise. So anyone who would take over that job will make a number of mistakes as they gain similar expertise. Some of those mistakes will be in allocating addresses to requesters who don't deserve them. Some of the mistakes will be in denying addresses to requesters who do deserve them, or in demanding more scrutiny than is warranted when requests are made. An allocation of 768 IP addresses, such as yours, which has considerable monetary value if used commercially, will naturally get more scrutiny than a typical request for a /29 that only has 8 addresses and can't be routed via BGP. The Chinese agency that licenses amateur radio operators, the State Radio Regulation of China (http://www.srrc.org.cn) does not appear to provide an English-language portal for looking up amateur radio licenses. This currently makes it a more manual process to verify the license status of Chinese hams. See: https://en.wikipedia.org/wiki/Amateur_radio_licensing_in_China (I hope some 44net users from Asia will improve that Wikipedia page, which is still mostly a stub page.) > 3. What is G1FEF's role in the allocation, which are the rights that ARDC holds has been delegated to this guy along. G1FEF has been informally trying to continue providing service to amateurs while the ARDC board and other volunteers scramble to pick up the work that Brian was doing during his lifetime. ARDC and G1FEF have been negotiating a contract that would specify just what rights and powers ARDC would delegate to G1FEF, and which ARDC would retain for exercise by its board (and eventually by a hired staff, which we have been trying to hire the first person of). The first draft contract was full of legalese that one side or the other didn't like, and it also raised some more complex issues such as international privacy practices, so we are re-drafting, consulting lawyers, and continuing to negotiate. > 4. The holding-the-ID-in-a-photo-of-you practice is pretty common when dealing with financial institutions and websites frequently deals with fraudsters. Since LIR, RIR, and BGP upstream also requires and validates these ID, Why this is necessary to do it again? People who get legacy 44.x.y.z IP addresses from 44net don't have to get addresses from an LIR or RIR, so LIR/RIR practices don't provide any safeguard for 44net addresses. Our previous policy, created and enforced by Brian, was not to demand such identity documents of everyone. But Brian did reserve the right to ask more questions and collect more information when he encountered a situation that he thought was questionable, and to use his own judgment in deciding whether to make an allocation. And he sometimes consulted with the board about how to resolve such situations. > 5. Is Chris Smith, G1FEF capable of handling sensitive personal data? He's handling data as natural person, or an legal entity that ARDC approves? At the moment, as a natural person; he's a volunteer. One of the issues being negotiated in the draft contract, and with lawyers, is to what extent ARDC will collect sensitive personal data, how it would safeguard that data that it does collect, and to what extent ARDC will be subject to privacy controls such as the European GDPR. These issues have been handled informally up to the time that Brian died. The current situation is that when Chris requests identification photos or documents, he examines them and then deletes them after approval. > 6. If there's another change, do anyone with a allocation has to go through the same process again? Since we haven't defined any changes yet, we also haven't decided that issue. > I see that we already have a problem with transparency, now we got bureaucracy? Also it's not my problem that the assignment wasn't added to the portal. It is fortunate that small, informal organizations still have room to operate in today's world, and can provide positive benefits to society. ARDC under Brian's leadership was such an organization; the board helped him around the edges, but he was our leader, and he also did most of the work. Now we have no leader experienced in exactly what Brian did. As organizations grow and become more formal, the world expects a degree of impartiality, predictability, and adherence to rules that reduces the flexibility of the informal processes. Quan, you are simultaneously asking that you be given the benefit of an informal process that provided you with the allocation you claim, and yet also asking that we provide predictable rules and adhere to them, rather than continuing informally. There is clearly a tension between these extremes. The ARDC board (all volunteers) and the technical volunteers such as Chris and the regional coordinators are trying to chart a middle course. Thank you for your help in pointing out some of the implications of the choices we are trying to make. It DOES seem to be your problem that the assignment wasn't added to the portal. If your assignment was in the portal, then your allocation would not be getting the scrutiny it is currently getting. As the wiki says in the "Requesting a block" page: https://wiki.ampr.org/wiki/Requesting_a_block "You must request an amprnet block direct from the Portal. First you must create your account at the Portal. Once you do, you must login..." https://wiki.ampr.org/wiki/Announcing_your_allocation_directly "Apply for your AMPRNet allocation via the Portal. Check the Direct box to indicate that your connection will be using a direct announcement of the subnet (via the BGP protocol). "Upon verification and approval, the AMPRNet administrator will provide authorization to your ISP allowing them to announce your allocation." If only one of your three /24 allocations is in the portal, then how did Brian, the very meticulous AMPRNet administrator end up providing you with a Letter of Authorization for the others? > Best Regards, > Quan Best regards back to you, John Gilmore, W0GNU ARDC board member

5 years, 2 months

5
6
0 0

Re: [44net] GL.iNet openWRT Rip44 support?

by lleachii＠aol.com

Tracy N4LGH, I drafted the OpenWrt Wiki with the help of others on the mailing list. The instructions in the Wiki definitely work - I've been running an AMPRNet node on OpenWrt for approximately seven years. I have ampr-ripd compiled for most of my routers. I'm not sure how I missed your previous requests for assistance; but I'm willing to help setup an official OpenWrt firmware installation. 73, - LynwoodKB3VWG

5 years, 2 months

1
0
0 0

BGP portal management after WB6CYT's passing

by Phil Karn

Hi. As you all know, Brian Kantor WB6CYT passed away suddenly last month. Brian did so much for AMPRNet from the very beginning that he'll be impossible to fully replace. We're trying but it's hard, especially since he was a close personal friend. Chris Smith, G1FEF (chris(a)g1fef.co.uk) has kindly volunteered to take over Brian's portal work and to handle portal and BGP allocation requests. Please direct queries to him. 73, Phil Karn, KA9Q President, ARDC

5 years, 2 months

14
22
0 0

Manual BGP validation

by Corey Dean

I switched over to vultr a few weeks ago. To get my BGP announced there, they needed to do the manual verification. After 1 week of no response by the ampr.org team I have had to start with a new ticket and the manual process again. Is there more than one person than can validate the manual BGP verification process? Corey N3FE

5 years, 2 months

2
1
0 0

Re: [44net] A few more questions Re: BGP portal management after WB6CYT's passing

by Rob Janssen

> 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

5 years, 2 months

2
1
0 0

Re: [44net] Need TraceRoute from UCSD router

by R P

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

5 years, 3 months

3
3
0 0

Re: [44net] PKTerrors.

by lleachii＠aol.com

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 years, 3 months

5
4
0 0

Need TraceRoute from UCSD router

by R P

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

5 years, 3 months

6
9
0 0

Re: [44net] PKTerrors.

by lleachii＠aol.com

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

5 years, 3 months

1
1
0 0

PKTerrors.

by W.B.Hill

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)

5 years, 3 months

4
8
0 0

Re: [44net] PKTerrors.

by lleachii＠aol.com

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

5 years, 3 months

1
0
0 0

Re: [44net] PKTerrors.

by lleachii＠aol.com

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

5 years, 3 months

1
0
0 0

Re: [44net] PKTerrors.

by lleachii＠aol.com

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

5 years, 3 months

4
9
0 0

Link(s)

by gm4upx＠gb7jd.co.uk

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>

5 years, 3 months

1
0
0 0

Help troubleshooting AXIP link

by VE3OY Matt

Hello 44Net. I'm looking for some help from those who have experience! I have recently set up my first AXIP link through the 44Net, but I'm having trouble connecting to my AXIP partner. My IP is 44.135.88.200 and my partner is 44.135.32.201 So far I can TELNET and PING back and forth from ANY 44 node, yet all attempts to make a AX25 connection to my AXIP partner fail. I can TELNET/PING from my partner to my node okay. I can TELNET/PING to my partner from my node okay. I can PING the 44 gateway without issue. I have also been broadcasting my NODES table to my partner. My partner does not seem to "hear" my CONN REQ's or NODES broadcasts. My partner is also broadcasting his NODES table to me. I am not hearing his broadcasts. Using TCPDUMP and WIRESHARK, I can see the traffic going out my tunnel to my regional gateway. I have tried to capture AX25 packets FROM my partner ... nothing heard. I have been able to capture AX25 packets TO my partner ... all looks correct. I have been able to capture packets when TELNETing or PINGing. TRACEROUTEs to my partner work fine (2 hops). My situation is a little more complex because I am not going direct to the UCSD gateway. Instead, I am sending all my 44Net traffic through my regional gateway (44.135.88.252). It has been suggested that my ISP may be "source filtering", but i have no way of verifying that. I am running both my router and node on a Raspberry Pi (I know ... plug your nose! LOL) I am using IPTABLES, which I have disabled for testing to see if it was interfering (it wasn't). My router/node is behind a CPE router, and is in the DMZ. I have several AX-UDP ports working fine. So here are my questions: Does it sound like I am suffering from source filtering? How can I verify whether my ISP is source filtering? What have I overlooked in my troubleshooting? What would you suggest as my next step? Any and all suggestions are welcome. I'm going bald quickly pulling out my hair! Thanks in advance, Matt VE3OY (FN03gq) Toronto, Canada -- /My mind is like a web browser. 27 tabs are open, 9 aren't responding, lots of pop-ups...and where is that annoying music coming from?/

5 years, 3 months

1
0
0 0

Re: [44net] 44 compatible Routers

by lleachii＠aol.com

Angelo, You can search the archive; but everyone's been fairly diligent in adding configuration information for supported devices/NOSes and linking on the main Wiki page: http://wiki.ampr.org/wiki/Main_Page 73, - Lynwood KB3VWG

5 years, 3 months

1
0
0 0

Re: [44net] Need TraceRoute from UCSD router

by lleachii＠aol.com

Charles and Quan, Please read Friday's email digest, the password was provided. Also, since you have an account in the portal...doesn't that mean you have a gateway? - Lynwood KB3VWG

5 years, 3 months

1
0
0 0

Vultr BGP routing KO in Paris ?

by Toussaint OTTAVI

Hi all, Our subnet 44.190.11.0/24 does not seem to be reachable anymore from Internet. It's announced in BGP via a Vultr VPS located in Paris. I had notices from Vultr in the last few days about network upgrades. Currently, the route to our gateway 44.190.11.1 seems to be the default route via UCSD. I opened a support ticket. I know some of us are using Vultr. Do you encounter similar problems ? Thank you in advance, 73 de TK1BI

5 years, 3 months

5
10
0 0

Re: [44net] Need TraceRoute from UCSD router (R P)

by lleachii＠aol.com

David, https://gw.ampr.org/private/ Username: gatewaysPassxword: MTashram2007Ron It's in the archive. Also, my trace tool is available: http://kb3vwg-010.ampr.org/tools/trace/php-trace44.php 73, - Lynwood KB3VWG

5 years, 3 months

4
3
0 0

Ubiquiti Networks ER-10X set up

by Angelo Glorioso

I have not played with NOS and JNOS in years. I would like to use some of my 44 network address again. I see that a lot of the IRIP, Allstar Dstar etc are using 44 for stations, reflectors and so on. I purchased an Ubiquiti Networks ER-10X as a tunnel to the 44 network. Is there anyone that has done this already?? Anyone would like to be an Elmer to me in helping get this setup up and running?? Angelo Glorioso / N5UXT gw.n5uxt.ampr.org ( still there )

5 years, 3 months

2
1
0 0

EC2 Router Reference Implementation

by Stephen Thomas

To learn the routing protocol, I created an Amazon EC2 instance of a Linux Ubuntu router inside a virtual private cloud (VPC) where I have full control over IP and can open 0.0.0.0/0 in both directions over all protocols (EC2 without a VPC only permits TCP/UDP/ICMP access control). When I run the daemon in verbose mode it is stuck calling home: ubuntu@ip-192-168-44-12:~$ sudo ampr-ripd -d -v -L KZ0FOX@EM89mx Using metric 0 for routes. Using TCP window 840 for routes. Using gateway 192.168.44.1 for direct 44net endpoints via interface eth0. Calling home Waiting for RIPv2 broadcasts... Calling home Calling home Calling home This system is online in the portal as 3.135.62.22 ( ec2-3-135-62-22.us-east-2.compute.amazonaws.com) and subnet 44.76.0.12/32. Setting up a reference implementation like this one may be good for learning the basic premise and ability to test out a configuration with less variables than one may have at home with an ISP. I welcome any constructive comments or suggestions. Best regards, Stephen Thomas

5 years, 3 months

3
2
0 0

Re: [44net] 44Net Digest, Vol 8, Issue 178

by Roger

Very sad news. I was talking to him just the other day. What a shock. My condolences to his family and those close to him. As busy as I imagine he must have been, he always had time to help. Roger VA7LBB > On Nov 23, 2019, at 12:00, 44net-request(a)mailman.ampr.org wrote: > > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Brian Kantor, WB6CYT, SK (Phil Karn) > 2. Re: Brian Kantor, WB6CYT, SK (vk2tv) > 3. Re: Brian Kantor, WB6CYT, SK (Donald Jacob) > 4. Re: Brian Kantor, WB6CYT, SK (Doug) > 5. Re: Brian Kantor, WB6CYT, SK (John Ricketts) > 6. Re: Brian Kantor, WB6CYT, SK (Fortney, Jim - K6IYK) > 7. Brian Kantor, WB6CYT, SK (Brian) > 8. Re: Brian Kantor, WB6CYT, SK (vk4aa(a)vk4aa.com.au) > 9. Re: Brian Kantor, WB6CYT, SK (Albert Lawson) > 10. Re: Brian Kantor, WB6CYT, SK (pete M) > 11. Re: [44ngn] Brian Kantor, WB6CYT, SK (Marius Petrescu) > 12. Brian Kantor, WB6CYT, SK (Paul) > 13. Re: Brian Kantor, WB6CYT, SK (Tony Langdon) > 14. Re: Brian Kantor, WB6CYT, SK (Tommy Chen) > 15. Re: Brian Kantor, WB6CYT, SK (Tim Po??r) > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

5 years, 3 months

3
2
0 0

Re: [44net] 44Net Digest, Vol 9, Issue 2

by Michael Herring

I just read the Terms of Service & Acceptable Use Agreement. It could be updated to reflect the changes in the allocated ip blocks 44.0.0.0/9 and 44.128.0.0/10 On Sun, Jan 12, 2020 at 3:00 PM <44net-request(a)mailman.ampr.org> wrote: > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Re: BGP portal management after WB6CYT's passing (Scott Nicholas) > > > > ---------- Forwarded message ---------- > From: Scott Nicholas <scott.nicholas(a)scottn.us> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Sun, 12 Jan 2020 14:29:27 -0500 > Subject: Re: [44net] BGP portal management after WB6CYT's passing > Will Chris be named as a POC in ARIN to be able to provide LOA to > upstreams for BGP announcement? > > On Mon, Dec 30, 2019 at 12:39 PM Phil Karn via 44Net > <44net(a)mailman.ampr.org> wrote: > > > > Hi. As you all know, Brian Kantor WB6CYT passed away suddenly last > > month. Brian did so much for AMPRNet from the very beginning that he'll > > be impossible to fully replace. We're trying but it's hard, especially > > since he was a close personal friend. > > > > Chris Smith, G1FEF (chris(a)g1fef.co.uk) has kindly volunteered to take > > over Brian's portal work and to handle portal and BGP allocation > > requests. Please direct queries to him. > > > > 73, Phil Karn, KA9Q > > > > President, ARDC > > > > > > > > > > _________________________________________ > > 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 >

5 years, 3 months

1
0
0 0

44 compatible Routers

by Angelo Glorioso

Hi All, I remember seeing a list of hardware router that would work with the 44 network. Anyone know where this list is located?? If I remember there was a list of Ubiquiti Edgerouters . Thanks.

5 years, 3 months

1
0
0 0

Memorial service for Brian Kantor, WB6CYT

by Phil Karn

As you know, Brian Kantor, WB6CYT passed away suddenly on November 21, 2019. We will hold a memorial service for Brian on Saturday, Feb 1 2020 at 1:30 PM in La Jolla, CA (part of San Diego). Please see this link for details: https://www.evite.com/event/0135NF64ATPRMYGRMEPKGPM2G3LMLQ/rsvp?utm_campaig… Please bring any photos, mementos and (above all) stories and anecdotes about Brian to share. Brian wasn't exactly a highly formal person who stood on ceremony, so we'll keep this informal. If you have a story to tell, it's up to you whether you stand up and relate it to the whole group or just a few others at a time. There will be plenty of time for both. Everyone who knew Brian is welcome. His friendships spanned at least three distinct social circles, and I know he'd be very happy to see everyone meet and enjoy everyone else's company. Even if he'd be a little embarrassed that we were doing it in his honor. Free snacks and refreshments will be provided, so please RSVP through the evite link so we can tell the hotel how much to make available. If you have special dietary needs, please say so; the hotel has a menu we can choose from. Please forward this email to anyone you think might be interested. Hope to see you on the 1st. Phil Karn, KA9Q

5 years, 3 months

1
0
0 0

test Sat, 04 Jan 2020 21:21:45 -0500

by n2nov＠n2nov.net

This is a test mailing

5 years, 4 months

2
1
0 0

Re: [44net] Bad name in DNS

by Thomas Osterried

Hello, Am 05.01.2020 um 11:25 schrieb Rob Janssen via 44Net <44net(a)mailman.ampr.org>: [..] > After investigating it appeared that an invalid name has been added to DNS by someone: > > dhcp-44-149-72-.db0eif IN A 44.149.72.89 thank you for your open eyes. It must have been a bug while doing cut+paste. The archive of the source of changes shows the correct entry. I wish a bugfree new year ;) vy 73, - Thomas dl9sau

5 years, 4 months

1
0
0 0

Bad name in DNS

by Rob Janssen

I noted that since a couple of days the updates to DNS have been stuck and it caused a problem with out local DNS server as well. After investigating it appeared that an invalid name has been added to DNS by someone: dhcp-44-149-72-.db0eif IN A 44.149.72.89 Note the trailing minus sign in the name, which is not allowed. Bind with (default) strict name checking will issue an error on this, and (I think that is bad) it will refuse to load or transfer the entire zone. So the previous version of the zone will remain active. This was version 2001012115, while the current version is 2001050245 so it has been stuck for a couple of days (the format used for the version is YYMMDDHHMM). For now I have deleted the bad name, but it would probably be prudent to add: check-names warn; to the zone configurations of the bind daemons running the ampr.org zone so that they have the more reasonable behavior of just ignoring that single name instead of the entire zone. Rob

5 years, 4 months

1
0
0 0

BGP Request Process

by VK4AA

Hi Guys Has the process for BGP approvals been finalised yet? Samantha VK4AA Australian Co-Ordinator AMPRnet

5 years, 4 months

4
3
0 0

Re: [44net] 44Net Digest, Vol 8, Issue 185

by kd6oat

Brett: Thank you for your decades of service to one of the digital sides of amateur radio.. My jnos convers server has been linked to wa7v for many years 24/7 and I am most grateful that you have been able to provide a gateway and for all the work you have done. Merry Christmas and Happy New Year to you and yours. Ken - KD6OAT > > > Date: Sat, 21 Dec 2019 12:43:00 -0800 > From: Brett Mueller <wa7v(a)wa7v.com> > To: 44net(a)mailman.ampr.org > Subject: [44net] WA7V Services to End > Message-ID: <7a53f433-ed44-508b-83fd-5bce59361592(a)wa7v.com> > Content-Type: text/plain; charset=utf-8 > > Hello, 44net ops, > > An assortment of circumstances have gradually led me to the decision to > terminate the WA7V gateway/BBS and related services at College > Place/Walla Walla, Washington, USA. > > Services are scheduled to go offline on Monday, December 30, at > > >

5 years, 4 months

1
0
0 0

SMTP Gateway

by Jean Létourneau

Good day, I am looking for a smtp gateway where I will be able to send mail from my jnos (va2om.ampr.org) to the internet. Any taker? Happy Holiday!. 73 de Jean, VA2OM / VE2PKT -- -- Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode) : VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net) : VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway) RF: 147.435 Mhz (1200 Bps), Internet: Telnet://nodes-ve2pkt.dyndns.org port 23 (Network Node) Telnet://fbb-ve2pkt.dyndns.org port 6300 (FBB BBS) Telnet://ve2pkt.dyndns.org port 9000 (DXCluster) E-Mail: packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam ampr net: ve2pkt(a)ve2pkt.ampr.org Inet: ve2pkt(a)gmail.com

5 years, 4 months

1
0
0 0

WA7V Services to End

by Brett Mueller

Hello, 44net ops, An assortment of circumstances have gradually led me to the decision to terminate the WA7V gateway/BBS and related services at College Place/Walla Walla, Washington, USA. Services are scheduled to go offline on Monday, December 30, at approximately 00:00 UTC (Sunday afternoon/evening in the Americas). These services include: * Hub_NA saupp convers hub * ALWGW:WA7V-8 NOS Gateway/BBS * ALWBBS:WA7V FBB BBS * ALWHUB:WA7V-4 UROnode * PNW:WA7V-2 (X)Net Router I believe we have a replacement lined out for Hub_NA. I should have a confirmation shortly, and another announcement will be following. It's been an interesting 2+ decades for me, and I'm very grateful to a number of extremely bright and motivated hams around the world who have contributed so much in advancing the all-encompassing art of amateur radio. I've been the undeserving recipient of their creativity, expertise, time and energy. For most it is a labor of love, and certainly not something that has put any bread on their tables. To those amateurs, I heartily say, "thank you!" Thanks for your links, chats, assistance and friendship! We'll see what the future holds. :) Merry Christmas, and happy holidays! 73, Brett Mueller Pendleton, Oregon, USA

5 years, 4 months

1
0
0 0

Linux GRE Tunnels

by Jason McCormick

I'm running into an interesting problem I thought maybe someone in this community would have run into before. We're working on a project to redesign and re-IP our entire radio network. Part of the goal is to stop using OpenVPN and IPSec tunnels (long story) and move exclusively to GRE-based tunnels. The plan is to have two Linux VPS hosts running at a provider with our 44Net allocation and an IPv6 allocation advertised and then routed into the radio network over GRE tunnels to 3 different locations that are all backhauled together. One of the primary goals is to do dual-stack throughout the network. I have one site setup working perfectly - "gre0". It's passing IPv4 and IPv6 traffic over the GRE tunnel. One *key* point to this is that the GRE connection endpoints are iPv6. IPv4 isn't doable for this connection (again, long story but not an option). When setting up the second GRE tunnel "gre2", nothing would work even though the configuration was the same EXCEPT for the fact that the second GRE tunnel was using IPv4 addresses for the GRE tunnel endpoints. Linux keeps spitting out a very odd error when I try to ping across the tunnel I cannot find reasonably documented anywhere: ip6_tunnel: gre2 xmit: Local address not yet configured! The key was the "ip6_tunnel" part that took me awhile to figure out. After experimenting, I've found that if I have one GRE tunnel using IPv6 endpoints (ip -6 tunnel add gre0 mod ip6gre) and one using IPv4 endpoints (ip tunnel add gre2 mode gre), only the gre0 tunnel will work and the gre2 tunnel seems to believe it's missing an IPv6 address. If I delete the gre0 tunnel, the gre2 tunnel immediately beings working with both IPv4 and IPv6 traversing the GRE. I cannot find any documentation that describes this behavior or why it would be the case. I can't switch to IPIP tunnels because I haven't found a way to do a dual-stack tunnel between the endpoints - seems like you can only do one IPIP tunnel between two endpoint IPs regardless of type (ipip, ipip6, ip6ip6, sit) Anyone have any deep wisdom on GRE tunnels? Jason

5 years, 4 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net