- 44net - mailman.ardc.net

by Leon Zetekoff

Hi there...just noticed in my Mikrotik log this is bouncing. Anyone know anything? seems to have started 9:33:34 AM EST --- This email has been checked for viruses by AVG. https://www.avg.com

6 years, 6 months

2
1
0 0

Re: [44net] Why if you are yahoo.com or gmail.com mail user, you probably won't see this message :-)

by Rob Janssen

> The subject line of this message is clearly wrong. > 255 of the 821 subscribers to this mailing list use @gmail.com > mailboxes. > If there were a problem with gmail, it would have shown up long > ago. I have a bit mixed feelings about it. As a coordinator I get regular mail from gmail users and often experience that my replies do not arrive or get marked as SPAM. I get reminders about requests that I have already processed, and sometimes a message "oh sorry I found your reply in the SPAM folder". At first I blamed my use of an @amsat.org address, and also using that address as a From: address in my replies. Due to the SPF record on amsat.org it can be expected that such use leads to marking of mail as suspicious. So I switched to using another alias service (@vrza.nl being offered by one of our amateur radio societies), but the situation did not improve. I still get reports of my mail ending up in the SPAM folder at gmail. But the vrza.nl domain has no SPF record. Apparently there is some relation to the user receiving the mail. Some users receive all my mail without problem, no matter if sent from @amsat.org @vrza.nl or another source. Others report that it is treated as SPAM for each of those. Not being a gmail.com user myself, I do not exactly know what features it offers for whitelisting or other special treatment of mail, or maybe what it learns automatically. It could be that sending back and forth several mails eventually leads to an address getting on the whitelist automatically. The same could be true for mail server IP addresses (like a mailinglist server), and it could be that knowledge built in the past also affects the results of new SPAM criteria added later. It is all a bit opaque, and when you want reliable and predictable mail service, using those mailservices certainly is not the best choice... or at the least check the SPAM folder regularly. (but I have also received reports of mail being dropped and not placed there) Rob

6 years, 7 months

8
13
0 0

Why if you are yahoo.com or gmail.com mail user, you probably won't see this message :-)

by Neil Johnson

TL;DR: In never ending battle against SPAM and phishing attacks, some email providers are now using DMARC, rejecting or marking as SPAM email if the originating mail server doesn't match the authorized ones for the provider's service. For example: - Yahoo! is flat out rejecting e-mail from yahoo! mail users if it comes from non-authorized servers. - Google is marking e-mail from gmail users as SPAM if it comes from non-authorized servers. Unfortunately this breaks mailing list software like mailman (used for this list) which tries to make e-mail from the list appear as if it is coming from the original sender. The changes that are required to fix the issue change the functionality of the list software in ways users may not like. I found this out while applying DMARC for my my own domains. More info can be found at these sites: https://wiki.list.org/DEV/DMARC https://dmarc.org/ Fun. -Neil -- Neil Johnson

6 years, 7 months

10
11
0 0

FYI - Amazon acquires 3.0.0.0/8 from GE

by Neil Johnson

https://news.ycombinator.com/item?id=18407173 Note: I'm NOT advocating anything like that for 44.0.0.0/8. It's just going to be fun to watch the market for IPv4 address space boom and then bust when IPv6 adoption finally reaches critical mass. -Neil, N0SFH -- Neil Johnson

6 years, 7 months

12
21
0 0

ampr-ripd

by Jean Létourneau

Hello group, what can cause ampr-ripd to stay at " waiting for RIPV2 Broadcast".I opened the DMZ port of my main routerwhere my raspbery PI is connected. I know the DMZ work. I tested if from outside. Any tought? 73 de Jean -- 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 <http://xrouter-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

6 years, 7 months

4
5
0 0

Vps VPN apmrgateway.

by pete M

Hi! I am kind of new to all this ampr thing. Been following this mailing list and trying to have my setup in a way that will be stable. I have a vps running openvpn server. I have an edge router I want to take my 44 IP address range and distribute them to a port on my edge router but I want to keep my wan/lan configuration as it is and transparent to the 44 range In what way should I do it? I am totaly lost.

6 years, 7 months

1
0
0 0

Doing Gateway from Cellular Modem feed ?

by R P

Hi there Has someone tried doing A gateway with cellular modem ? I understand that cellular modems (at least in our country) do few times NAT (carrier-grade nat) and therefore the IP it get is not an IP accessible from the outside world so probably cant do any IPIP to the 44 net router Is that true ? or is there any solution ? We dont have IPV6 systems here yet which might overcome this problem only IPV4 any Info on the subject is appreciated Regards Ronen -4Z4ZQ http://www.ronen.org [http://www.ronen.org/My-QSl.jpg]<http://www.ronen.org/> Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com www.ronen.org

6 years, 7 months

3
2
0 0

Re: [44net] Unregistered gateway?

by Rob Janssen

> Possibly a router not having updated the script to 3.2 after upgrade to > ROS 6.41 and later. Yes, that would be the reason for sending MNDP broadcasts. Actually I don't mind that those are sent, it can be useful as it provides the info I gave in the first post. But of course it would be nice when system->identity is changed e.g. to the callsign so it is easier to contact people when something is wrong. However, the main issue is that it is using a public IP that is not in the gateway list so these packets cause a log message and are dropped here. Likely the public IP has changed without the owner noticing it or without him realizing that he needs to update the portal entry. (of course this can be avoided when using a DNS name in the portal and some dynamic DNS update script, or even simply "IP Cloud" when this MikroTik is directly in the public IP) Rob

6 years, 7 months

1
0
0 0

Unregistered gateway?

by Rob Janssen

Who is running an unregistered gateway at public IP address 72.192.178.228 ? (Cox communications) It is a MikroTik RB750Gr3 router running 6.42.6 firmware with default identity "MikroTik" broadcasting MNDP packets to all other gateways, apparently running Marius' ampr-rip script, but the address is not appearing in the portal. Maybe its address has changed but not updated in the portal? Rob

6 years, 7 months

3
2
0 0

LoRA module

by Steve L

This caught my attention on the wetnet list: https://www.enhancedradio.com/products/hamshield-lora-edition-high-power For those seeking new ways to move data and ones that exceed what you can do connected to conventional analog rigs, this is worth looking into. Circuit Cellar magazine had a pretty decent multi-part LoRA overview last year. And if you look on github, Travis, KK4VCZ has some code adapted as a starting place for ham radio: https://github.com/travisgoodspeed/loraham Figured I'd point it out there as it's what we do.

6 years, 8 months

1
0
0 0

John Postel - 20 years

by Brian Kantor

Network Working Group V. Cerf Request for Comments: 2468 MCI Category: Informational October 1998 I REMEMBER IANA October 17, 1998 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Remembrance A long time ago, in a network, far far away, a great adventure took place! Out of the chaos of new ideas for communication, the experiments, the tentative designs, and crucible of testing, there emerged a cornucopia of networks. Beginning with the ARPANET, an endless stream of networks evolved, and ultimately were interlinked to become the Internet. Someone had to keep track of all the protocols, the identifiers, networks and addresses and ultimately the names of all the things in the networked universe. And someone had to keep track of all the information that erupted with volcanic force from the intensity of the debates and discussions and endless invention that has continued unabated for 30 years. That someone was Jonathan B. Postel, our Internet Assigned Numbers Authority, friend, engineer, confidant, leader, icon, and now, first of the giants to depart from our midst. Jon, our beloved IANA, is gone. Even as I write these words I cannot quite grasp this stark fact. We had almost lost him once before in 1991. Surely we knew he was at risk as are we all. But he had been our rock, the foundation on which our every web search and email was built, always there to mediate the random dispute, to remind us when our documentation did not do justice to its subject, to make difficult decisions with apparent ease, and to consult when careful consideration was needed. We will survive our loss and we will remember. He has left a monumental legacy for all Internauts to Cerf Informational [Page 1] RFC 2468 I REMEMBER IANA October 1998 contemplate. Steadfast service for decades, moving when others seemed paralyzed, always finding the right course in a complex minefield of technical and sometimes political obstacles. Jon and I went to the same high school, Van Nuys High, in the San Fernando Valley north of Los Angeles. But we were in different classes and I really didn't know him then. Our real meeting came at UCLA when we became a part of a group of graduate students working for Professor Leonard Kleinrock on the ARPANET project. Steve Crocker was another of the Van Nuys crowd who was part of the team and led the development of the first host-host protocols for the ARPANET. When Steve invented the idea of the Request for Comments series, Jon became the instant editor. When we needed to keep track of all the hosts and protocol identifiers, Jon volunteered to be the Numbers Czar and later the IANA once the Internet was in place. Jon was a founding member of the Internet Architecture Board and served continuously from its founding to the present. He was the FIRST individual member of the Internet Society I know, because he and Steve Wolff raced to see who could fill out the application forms and make payment first and Jon won. He served as a trustee of the Internet Society. He was the custodian of the .US domain, a founder of the Los Nettos Internet service, and, by the way, managed the networking research division of USC Information Sciences Institute. Jon loved the outdoors. I know he used to enjoy backpacking in the high Sierras around Yosemite. Bearded and sandaled, Jon was our resident hippie-patriarch at UCLA. He was a private person but fully capable of engaging photon torpedoes and going to battle stations in a good engineering argument. And he could be stubborn beyond all expectation. He could have outwaited the Sphinx in a staring contest, I think. Jon inspired loyalty and steadfast devotion among his friends and his colleagues. For me, he personified the words "selfless service". For nearly 30 years, Jon has served us all, taken little in return, indeed sometimes receiving abuse when he should have received our deepest appreciation. It was particularly gratifying at the last Internet Society meeting in Geneva to see Jon receive the Silver Medal of the International Telecommunications Union. It is an award generally reserved for Heads of State, but I can think of no one more deserving of global recognition for his contributions. While it seems almost impossible to avoid feeling an enormous sense of loss, as if a yawning gap in our networked universe had opened up and swallowed our friend, I must tell you that I am comforted as I contemplate what Jon has wrought. He leaves a legacy of edited documents that tell our collective Internet story, including not only Cerf Informational [Page 2] RFC 2468 I REMEMBER IANA October 1998 the technical but also the poetic and whimsical as well. He completed the incorporation of a successor to his service as IANA and leaves a lasting legacy of service to the community in that role. His memory is rich and vibrant and will not fade from our collective consciousness. "What would Jon have done?", we will think, as we wrestle in the days ahead with the problems Jon kept so well tamed for so many years. There will almost surely be many memorials to Jon's monumental service to the Internet Community. As current chairman of the Internet Society, I pledge to establish an award in Jon's name to recognize long-standing service to the community, the Jonathan B. Postel Service Award, which will be awarded to Jon posthumously as its first recipient. If Jon were here, I am sure he would urge us not to mourn his passing but to celebrate his life and his contributions. He would remind us that there is still much work to be done and that we now have the responsibility and the opportunity to do our part. I doubt that anyone could possibly duplicate his record, but it stands as a measure of one man's astonishing contribution to a community he knew and loved. Security Considerations Security issues are not relevant to this Remembrance. Author's Address Vinton G. Cerf MCI EMail: vcerf(a)mci.net Cerf Informational [Page 3] RFC 2468 I REMEMBER IANA October 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cerf Informational [Page 4]

6 years, 8 months

1
0
0 0

Reminder

by Brian

If you're a member of TAPR and you have not yet voted for the board of directors, please take a minute and do so. While you're at it please consider casting one for yours truly as well so we can have a voice within TAPR. -- Do Lipton Tea employees take coffee breaks? ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

6 years, 8 months

3
2
0 0

Re: [44net] Routing update issue

by Rob Janssen

> Done. > - Brian Thanks Brian! I think verifying an item in the data itself is more reliable than checking the result of the transfer. Which wget doesn't support anyway. It also covers the case where the .tar.gz file would be incomplete for some reason, e.g. running out of space. (I probably added the check for 255.255.255 at some point when that or another undetected error occurred...) Rob

6 years, 8 months

1
0
0 0

Re: [44net] Routing update issue

by Rob Janssen

It looks like we have the correct routes, but maybe the situation already rectified itself. 44.182.21.0/24 via 89.122.215.236 dev tunl0 proto ampr-ripd metric 4 onlink 44.182.21.1 via 89.33.44.100 dev tunl0 proto ampr-ripd metric 4 onlink This weekend we had another issue. I use a script to download the ampr.org zone from ftp://gw.ampr.org/pub/ampr.tar.gz to have it available locally in case there is a DNS problem on internet or we get isolated (lost connectivity on our gateway). Our local DNS servers 44.137.0.1 and 44.137.0.2 operate from this downloaded zone rather than from internet, and a regular check of the version number is made and the new file downloaded when it changes. As I experienced before that download of this file sometimes is not complete due to DDoS or other issues that make the download very slow, I added a sanity check: verify that the PTR entry for 44.255.255.255 is present in the 44.rev file before replacing our copies with the downloaded one. That entry was the last line in 44.rev, however someone has removed it so my script permanently rejected the download. Well... maybe a line can be added at the end of the files like there is at the end of encap.txt saved by ampr-ripd, so scripts can check for that to see if the file is complete: # --EOF-- Of course it is always better to have a documented check criterium than to rely on something like the 44.255.255.255 -> broadcast.ampr.org entry... Rob

6 years, 8 months

3
2
0 0

Routing update issue

by Marius Petrescu

Hello, I think we have an route update/setup issue in our network that may need some attention. First of all, I don't see the root cause so maybe we should investigate a little. As you may have noticed, a technical bulldozer issue forced me to move the yo2tm server to a VPS cloud machine, which is not a bad move by itself. I put a gw with amprd on it and added a new new portal entry, 44.182.21.1 via 89.33.44.100. The route appeared in the RIP broadcasts a few minute later and everything seems to be working as expected. Ping was ok, connecting also. So at the moment there are 2 overlapping subnets, 44.182.21.1/32 at the new gw, and 44.182.21.0/24 at the old one. Since I moved the call home map to the new location, too, I was expecting that all nodes would show up in the new map, since all notifications go to 44.182.21.1. Normally, for routing purposes, the more precise route (/32) should take precedence over the old one, and everything should be fine. On the maps, there where some nodes appearing promptly via the new gateway, like N1URO and some related radio nodes, but that was it. So after 2 days, only 8 nodes switched to the new route, all others sending their notification to the old address, WHICH SHOULD NOT HAPPEN. The gateway was certainly updated as the internet pings hitting it moved to the new target (some 20 public IPs). Also, my netrom partners also followed after setting up the end axip endpoints on the new machine. I can not find an explanation for this, other than that there is some route caching involved. Maybe some of you have ideas/explanation on this behavior, and how to fix it. Marius, YO2LOJ

6 years, 8 months

7
18
0 0

Re: [44net] IP-IP Mikrotik

by Rob Janssen

> thanks! I will read and do some tests on a spare MT router prior to > modifying our primary router Remember you can use CHR to do testing. Install it on a virtualization platform and you don't even need a physical system. It can do 1 Mbps for free (usually enough for IP-IP). When you have an existing ESXi host it is very easy to deploy it (using OVA template). It can also run on many of the available VPS services so you can have an IP-IP gateway when you cannot meet the requirements to reasonably run it at home (static IP, incoming protocol 4 without issues). You can then run an outbound VPN from your home to the CHR instance. Rob

6 years, 8 months

1
0
0 0

IP-IP Mikrotik

by Dan Keizer

Hi there - Dan ve4drk here. I want to setup an IP-IP gateway on one of the Mikrotik devices we have on our network. We have a number of subnets defined in the 44 address space that we host locally via BGP. We'd like to ensure they are available to the IP-IP tunnels. I looked at this link: http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_MikroTik_Routers and there is a reference to the MIkrotik setup by yo2loj - but it's a bad URL. Is there an update somewhere else I can't seem to find? I was checking the list and I see his link is down for a bit. 73, Dan ve4drk

6 years, 8 months

3
3
0 0

Server down

by Marius Petrescu

Hello, Due to some bulldozer guy, yo2loj.ro and yo2m.ampr.org are down for the moment, probably for the whole week (they cut a main cable with some 200 pairs). I am migrating to a VPS, to get the download section up asap. Tnx, 73s, Marius, YO2LOJ

6 years, 8 months

1
0
0 0

Recent news regarding Mikrotik remote root access

by John Ricketts

Fresh from DerbyCon/Jacob Barnes: "Hey @derbycon if you didn't wake up early enough to catch my talk, I just dropped a variation on CVE-2018-14847 that allows attackers to remotely root a Mikrotik router: " https://github.com/tenable/routeros/tree/master/poc/bytheway

6 years, 8 months

4
6
0 0

TAPR Elections

by Brian

I was asked by one of the current TAPR board members to throw my name into the hat for this year's elections which I have done. One thing I would like to try to do is help us get some exposure on TAPR with our projects amongst other things I'd like to help accomplish. TAPR has been at some of our EastNet meetings and they know what we're about and are supportive of our use of IP over RF. I also would like to think having someone from within amprnet on the TAPR board could be beneficial to both. They should have emailed you a ballot with your membership ID number and expiration date of your membership. You'll need that to cast your 3 member vote. With that said, please cast a vote for me so that I'll be able to help achieve some great things for us all. Thanks in advance. -- Do Lipton Tea employees take coffee breaks? ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

6 years, 8 months

1
0
0 0

Re: [44net] Right Way to Add IPIP Connections to BGP-Announced Network

by Rob Janssen

Jason, It is difficult to define "right way" because there always is someone with a setup that breaks when you do it in some way. Who is wrong and who is right is difficult to tell in such cases. We have a BGP-announced /16 for the Netherlands and we also announce the same /16 on the IPIP tunnel network. Subnets from this are routed internally (using BGP as well, but not related to the internet BGP, we use private AS numbers) and also some people have IPIP tunnels with subnets or addresses that are within the /16. We use ampr-ripd to get the IPIP routes. This works OK. People communicating to others that are on IPIP as well use the IPIP tunnel, when they want to talk to others they send it via IPIP to our gateway (i.e. our gateway is the default gw on the 44-net routing table, instead of amprgw as in the examples) and we decapsulate it and forward the internal IP packet to our internal systems or to internet. To have it working this way it is important that all routes are in the same routing table. You can use different metrics to avoid collisions between BGP routes and IPIP routes for the same subnet, but it is not a good idea to use different routing tables for BGP and IPIP routes and then use ip rules to lookup in those tables until a route is found. This is because a more specific route should always be preferred, independent from the routing protocol. So when a packet is to be routed, it is looked up in the table and either a route via the IPIP mesh or some other route is used to forward it. A destination on IPIP can be within the BGP routed subnet without problem, and vice-versa. It will work fine when the remotes on IPIP correctly route back to you via IPIP as well. But some stations use clever hacks to work around certain problems and the result can be that they are unreachable for people using this solution. Who is right and who is wrong is difficult to determine, as has been shown in earlier discussions on the list. Rob

6 years, 8 months

1
0
0 0

Right Way to Add IPIP Connections to BGP-Announced Network

by Jason McCormick

With is the correct AMPRNet way to connect a BGP-announced AMPR netblock to the IPs that live behind IPIP tunnels? Should I just use one of my IPs in the /24 for the IPIP tunnel on my side, connect to 44.0.0.1/169.228.66.251, and use ampr-ripd? Or do I need a second subnet as in a "pure" IPIP setup and route between those networks myself? I'm not finding any good docs on the topic, but if I'm missing something please point me in the right direction. My understanding is that AMPR networks behind IPIP-based gateways can't necessarily get out to the wider Internet but rely on IPIP tunnels to different networks they want to reach via the rip44 service. We're working on setting up a larger Allstar-based repeater network and once we get it finally going, I want networks elsewhere in AMPRNet to be able to connect if they desire. Thanks. Jason

6 years, 8 months

1
0
0 0

Re: [44net] Difference between RIPv2 and RIP44

by lleachii＠aol.com

Aaron, As Brian said, I have the following IPs online: 44.60.44.1 - ping, NTP44.60.44.3 - ping, DNS44.60.44.10 - ping, HTTP44.60.44.254 (only accessible on AMPRNet) - ping I allow ping from your Public IP endpoint address and your 44 subnet(s) in the Portal. If you're on AMPRNet, a folder containing the ITU Radio Regulations and compiled ampr-ripd versions will be visible on the web server at: http://44.60.44.10/amprnet_docs/ -------------------------- Miguel, Also, I've added Marius' information to the Wiki: http://wiki.ampr.org/wiki/RIP -------------------------- Marius, FYI, I am able to ping 44.0.0.1: root@OpenWrt:~# ip route get 44.0.0.1 from 44.60.44.144.0.0.1 from 44.60.44.1 via 169.228.34.84 dev tunl0 table 44 uid 0 cache expires 582sec mtu 1480 window 840 root@OpenWrt:~# ping 44.0.0.1 -I 44.60.44.1 -c 3PING 44.0.0.1 (44.0.0.1) from 44.60.44.1: 56 data bytes64 bytes from 44.0.0.1: seq=0 ttl=62 time=67.768 ms64 bytes from 44.0.0.1: seq=1 ttl=62 time=67.814 ms64 bytes from 44.0.0.1: seq=2 ttl=62 time=67.492 ms --- 44.0.0.1 ping statistics ---3 packets transmitted, 3 packets received, 0% packet lossround-trip min/avg/max = 67.492/67.691/67.814 ms 73, - Lynwood KB3VWG

6 years, 8 months

2
3
0 0

Difference between RIPv2 and RIP44

by Aaron Jackson

I am curious to understand the specific differences between "standard" RIPv2 and the "RIP44" used by AMPR. I read on the wiki that 44net uses a "modified RIP advertisements". I find that tcpdump can decode these packets, showing the destination nextwor and next hop address. Why is a standard ripd unable to process these? Not complaining - just curious :) Thanks, Aaron, M6PIU

6 years, 8 months

8
23
0 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> I updated ampr-ripd in line with recent changes. Running v2.3. I do > use multiple routing tables as recommended in the documentation. Using multiple routing tables is good when you have to work around source address filtering, so you want to send traffic from your 44 address to systems outside 44.0.0.0/8 via another default router, e.g. amprgw, than your usual internet traffic. However, I think ampr-ripd >= 2.0 should insert a route for 44.0.0.1 in your table for net44 like: 44.0.0.1 via 169.228.34.84 dev tunl0 proto ampr-ripd onlink Strange that you don't have that. But when you use multiple tables you should also have: default via 169.228.34.84 dev tunl0 onlink in the net44 table (unless you use another system to work around source address filtering) so it should not matter much that 44.0.0.1 is missing as this happens to use the same gateway. Rob

6 years, 8 months

2
1
0 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> I think I'm going to have to draw a diagram of the amprgw setup and > trace the journey a packet takes going to and from it before I > understand exactly what's going on. I'm no longer sure. It could also help a lot when you separate the ampr.org system and the amprgw system, e.g. by running ampr.org (or both) in a VM. Rob

6 years, 8 months

1
0
0 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

Does the ampr gateway know about the networks routed via BGP? Maybe the mistake is that it consults the route tables in some order (first check if there is a BGP route, if so then route that way, then check if there is a tunnel route, if so route via tunnel). This will fail on my test system because it has a /32 route via IPIP but the address is within 44.137.0.0/16 routed using BGP. The routing tables should be all merged into one so that it recognizes this /32 as more specific than the /16 and it routes via the tunnel not via BGP. Part of our routing table: default via 213.222.29.193 dev eth0 44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1 44.0.0.1 via 169.228.34.84 dev tunl0 proto ampr-ripd metric 4 onlink 44.2.0.1 via 191.183.136.1 dev tunl0 proto ampr-ripd metric 4 onlink (213.222.29.193 is the router of our ISP) Rob

6 years, 8 months

1
0
0 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> >/Is there a route for 44.0.0.1 in your routing table?///> Not that I can see. I'm running ampr-ripd. Probably an older version (before 2.0)? These had a hard-coded ignore of routes to 44.0.0.1 so it does not appear in your routing table, and as a result you may send traffic to 44.0.0.1 via your default route, with your public IP as source address. Then, you get replies. (whether this actually works depends on your configuration w.r.t. "ip rule" and using multiple routing tables) Rob

6 years, 8 months

2
1
0 0

tcpdump of ping on ipip

by Brian

It looks as if pings do come via the tunnel as well: n1uro@gw:~$ sudo tcpdump -i tunl0 -vvvvv|grep ICMP tcpdump: listening on tunl0, link-type RAW (Raw IP), capture size 262144 bytes 18:19:41.105553 IP (tos 0x0, ttl 64, id 63523, offset 0, flags [DF], proto ICMP (1), length 84) portland.n1uro.ampr.org > ampr.org: ICMP echo request, id 23674, seq 1, length 64 18:19:41.107566 IP (tos 0x0, ttl 63, id 63523, offset 0, flags [DF], proto ICMP (1), length 84) portland.n1uro.ampr.org > ampr.org: ICMP echo request, id 23674, seq 1, length 64 18:19:41.210652 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 1, length 64 18:19:41.212484 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 1, length 64 18:19:42.219244 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 2, length 64 18:19:42.221105 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto ICMP (1), length 84) ampr.org > portland.n1uro.ampr.org: ICMP echo reply, id 23674, seq 2, length 64 18:19:42.534924 IP (tos 0xc0, ttl 64, id 43001, offset 0, flags [none], proto ICMP (1), length 99) -- Men over 50 no longer fight at the drop of a hat. They've learned it's hard Enough to hit a toilet, much less an agile younger fellow who is kicking Their butt. ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org

6 years, 8 months

1
0
0 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> I'm only on the mesh here Rob and I can ping 44.0.0.1. Is there a route for 44.0.0.1 in your routing table? It may be that you are actually sending your traffic to 44.0.0.1 "direct", not via a tunnel. (this depends on the setup of your machine and the version of the rip daemon you are running) Rob

6 years, 8 months

2
1
0 0

Re: [44net] EdgeRouter (was Re: Difference between RIPv2 and RIP44)

by Rob Janssen

> I believed the problem with pinging from tunneled hosts was > still there, but if it works for you, I must have forgotten. It is a bit unclear what is going on. From a host that is exclusively on the IPIP mesh the ping does not return (I see only the outgoing IPIP packet). From a host that is both on the IPIP mesh and BGP-routed on internet it does work. It looks like it replies "directly" (via the BGP route) to the replies sent as IPIP. Rob

6 years, 8 months

3
2
0 0

Re: [44net] Difference between RIPv2 and RIP44

by Rob Janssen

> A standard ripd won't ever see the RIP44 packets because they're > encapsulated in an IPIP tunnel packet. The standard ripd doesn't > know how to de-encapsulate them first. Of course when you have a single multi-point tunnel interface like in Linux (tunl0), you could have ripd listening on that interface and it would see the correct packet format. However, I think the default ripd does some sanity checks that make it fail on the special assumptions made in RIP44. Rob

6 years, 8 months

1
0
0 0

AX.25 with digital signatures and binary compression

by Quan Zhou

Hi all, I just saw this project on the Github, and it looks related and might be very interesting to you. Check it out! https://github.com/brannondorsey/chattervox An AX.25 packet radio chat protocol with support for digital signatures and binary compression. Like IRC over radio waves. Chattervox implements a minimal packet radio protocol on top of AX.25 that can be used with a terminal node controller (TNC) like Direwolf to transmit and receive digitally signed messages using audio frequency shift keying modulation (AFSK). In the United States, it's illegal to broadcast encrypted messages on amateur radio frequencies. Chattervox respects this law, while using elliptic curve cryptography and digital signatures to protect against message spoofing. -- Regards, Quan Zhou

6 years, 9 months

2
1
0 0

Old newbe question.

by Jean Létourneau

Hello Group, I'd like to start experimenting building my own gateway (For learning purpose). I am reading different way to do it. Now I am in limbo bettwing : amprd 2.1 or Mikrotik RIPv2 AMPR Gateway Can you tell me your experience if you are using any of those options. Thank you 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 <http://xrouter-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

6 years, 9 months

1
0
0 0

Re: [44net] beware of IPIP scanner...

by Rob Janssen

> I'll read this carefully and figure it out...I was a BASIC and C++ > man...shouldn't be too hard. There is always a lot to learn... But in shell scripting, the following two do the same thing: if command then and: command if [ $? -eq 0 ] then Similarly: if ! command then is the same as: command if [ $? -ne 0 ] then It reads easier (once you know) and it avoids the situation where someone inadvertently puts something between the command and the 'if' that resets the $? e.g. some attempt at debugging like 'echo $?'. Rob

6 years, 9 months

1
0
0 0

Re: [44net] beware of IPIP scanner...

by Rob Janssen

> Also, don't put a space between these two lines: > > ipset -N ipipfilter hash:ip 2>/dev/null > > if [ $? -eq 0 ] It would not be a problem to have a space between those, but of course there should not be other things, and having a space there maybe invites that. You would better write this as: if ipset -N ipipfilter hash:ip 2>/dev/null then ... else ... fi so it is clear what is going on and that the result $? of the ipset is to be processed by the if. Rob

6 years, 9 months

2
1
0 0

Re: [44net] beware of IPIP scanner...

by Rob Janssen

> I believe a significant number of people who have AMPRNet addresses > and are BGP-connected really don't care much about communicating > with other IPIP mesh-connected hosts; their interest is the rest > of the Internet. Of course traffic mostly tends to be local and we see some IPIP mesh traffic to stations in the area that are IPIP mesh connected, including country networks like Germany. Most traffic is between AMPRnet addresses connected on radio or VPN, and between those and internet. It is understandable, because many IPIP mesh stations are small islands at the other side of the world and there is little chance that someone here would want to send a lot of data to them. On the other hand, connections internal to our network are used to interconnect repeaters (both voice and ATV) and for things like echolink and they transport a lot of data, mostly local. > Since there's no way to capture flow data for these folks, we'll > never know where their traffic is going. All we can do is guess > from anecdotal data. Maybe we can setup some ip flow export... Rob

6 years, 9 months

2
1
0 0

Re: [44net] beware of IPIP scanner...

by lleachii＠aol.com

You can also use ipset in Linux and OpenWrt to filter from the RIP44 announcements. I only allow Protocol No. 4 from you all. I have the script; it's a slight modification of the one found on the Firewall Wiki. It can be set to run with the -x argument after each RIP44 announcement on ampr-ripd. Let me know and I'll send a TXT file of it. - Lynwood KB3VWG

6 years, 9 months

4
5
0 0

Re: [44net] beware of IPIP scanner...

by Rob Janssen

> Ah ah ah, it's very complex to common mortals as me :) > Perhaps it is mature the time to adopt, after many > years, the *SIMPLE* implementation created by Maiko > VE4KLM for JNOS2, applying it to our systems: > ------------ > 3) Configuration > ------------- > When adding a 44 route, typically one uses something like this : > route add 44.0/8 encap a.b.c.d But does that automatically add the two levels of firewalling that we are discussing here? If not, it does not seem very relevant. It is quite easy to make a configuration that basically works (especially when using RIP which makes route statements like the above unnecessary), but the point is that it is not secure against abuse by malicious people. That is why additional work is needed. Rob

6 years, 9 months

9
10
0 0

Re: [44net] beware of IPIP scanner...

by Rob Janssen

> It is also a good idea to block forwarding from/to AMPR interfaces other > than your own internal 44 network. That is right! At first you filter IPIP packets in the input chain to allow only packets from the list of gateways (public addresses). In Linux this can be done with ipset and on the MikroTik using an "address list" (which is just their UI around ipset), or you can dynamically maintain a list of rules. (which allows to maintain counters per rule, also possible with recent kernels and ipset) Then, there should be a forward chain rule on the tunnel interface that only accepts incoming packets to the net-44 subnets you have published in the portal. You don't want to accept traffic destined for other addresses and then forward that. It would also be good to filter traffic forwarded TO the tunnel interface to only accept valid source addresses (your own networks), mostly to cover one's own mistakes in handling NAT. Both of those rulesets would have blocked the described scan. Probably it would be a good idea to include some working firewall example on the Wiki (for the different environments desrcibed) so everyone can have a secure firewall without in-depth knowledge about this matter. Unfortunately I have little knowledge about the particular methods used to load iptables on the different Linux distributions: the first thing I always do when installing a machine that does advanced routing is to remove their firewall maintenance packages and replace them by a init.d script that just uses iptables statements to build it at boot (or reload) time. That allows me to use variables, comments, shell constructs, etc which is much more maintainable than those "iptables-save" or automatic firewall maintenance solutions (when you install some package, corresponding ports are opened). Rob

6 years, 9 months

2
1
0 0

beware of IPIP scanner...

by Rob Janssen

Since two days ago someone is scanning the internet for IPIP decapsulation gateways, hitting our gateway system. The packets look like this (shortened tshark output): Internet Protocol Version 4, Src: 35.231.13.238 (35.231.13.238), Dst: 44.137.164.26 (44.137.164.26) Version: 4 Total Length: 69 Time to live: 236 Protocol: IPIP (4) Source: 35.231.13.238 (35.231.13.238) Destination: 44.137.164.26 (44.137.164.26) Internet Protocol Version 4, Src: 44.137.164.26 (44.137.164.26), Dst: 35.231.13.238 (35.231.13.238) Version: 4 Time to live: 255 Protocol: UDP (17) Source: 44.137.164.26 (44.137.164.26) Destination: 35.231.13.238 (35.231.13.238) User Datagram Protocol, Src Port: 35261 (35261), Dst Port: 5974 (5974) Source Port: 35261 (35261) Destination Port: 5974 (5974) Length: 29 Data (21 bytes) 0000 74 68 69 73 20 69 73 20 6e 6f 74 20 61 6e 20 61 this is not an a 0010 74 74 61 63 6b ttack Data: 74686973206973206e6f7420616e2061747461636b [Length: 21] The sender is always 35.231.13.238 (a Google cloud customer), the destination is some random address (in this case within AMPRnet because the trace was made on a BGP-routed system) and the payload is an IPIP packet which contains a UDP packet back towards the sender. Despite the text in the packet, the sender is obviously looking for traffic coming back at that UDP port, and then knows at which addresses on internet they may find systems that decapsulate IPIP traffic and route it back to internet. This can then be used to forge source addresses in attacks. I advise those that run IPIP gateways to configure a firewall that only allows IPIP traffic from peers that are listed in the route info distributed in the RIP packets. This can be done with some scripting, possibly with the help of "ipset" to keep a set of valid gateway addresses. Of course as a first fix you can block all traffic from 35.231.13.238, but that address could change any time. Rob

6 years, 9 months

3
2
0 0

ARRL/TAPR Digital Communications Conference this weekend

by Brian Kantor

Friday, Sept 14 through Sunday, Sept 16 is the annual ARRL/TAPR Digital Communications Conference, held this year in Albuquerque, New Mexico, USA. https://www.tapr.org/dcc.html I only saw one talk directly relevant to AMPRNet, titled "Bringing Net-44 and IPv6 to your Station via VPN" by John Hays, K7VE, scheduled for 9:45 am Saturday. I'll be attending; if you are also going to be there, look for the guy wearing the large "44" t-shirt, and we can chat. If there's interest, perhaps we can have breakfast on Saturday or Sunday morning. - Brian

6 years, 9 months

1
0
0 0

Re: [44net] edgerouter

by lleachii＠aol.com

Would you be interested in using OpenWrt on the EdgeRouter instead? https://wiki.openwrt.org/toh/ubiquiti/ubiquiti_edgerouter_x_er-x_ka There is a manual to setup using OpenWrt. http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT - Lynwood KB3VWG

6 years, 9 months

6
6
0 0

Portal dead?

by Ruben ON3RVH

Hey guys, Anyone else having issues reaching the portal? Dns has is going to the uk instead of uscd? Ruben - ON3RVH

6 years, 9 months

5
5
0 0

Re: [44net] edgerouter

by Andrew Spencer

It has been a long time since I have done any serious networking so am still struggling with getting my head around the instructions for the Edgerouter even after reading Marius's Microtik wiki. Does anyone have a Dummies Guide version of building a new gateway on the Edgerouter X? I have a HamServerPi and HamNet node (Ubiquiti Bullet M2) ready to go and a large group of hams waiting for my setup before they start active involvement in the development of our local HamNet - something we really need in the middle of tornado alley. My thanks in advance. Andy KA5BBC

6 years, 10 months

6
5
0 0

Re: [44net] Remote BGP Peering (Event)

by Rob Janssen

> We were wondering if it would be possible to tunnel in the AMPRNet from > UCSD into the exchange over BGP for the weekend of the event. If so what is > the best way to go about this? I'm more than happen to land it on a VM > elsewhere (Likely in London) then deal with getting it to the field myself > if need be. The standard way to have traffic tunneled to you, in the absence of a regional gateway that is BGP-routed, would be to register a subnet at the portal and setup an IPIP gateway for it, if desired using a VM somewhere to do the tunneling and a further tunnel (VPN) to the site to forward the traffic. Of course it would be possible to setup BGP routing to your VM, but would it be worth it for a 3-day event only? Maybe you could setup something more permanent that can be used by local amateurs after the event has ended. Rob

6 years, 10 months

1
0
0 0

Remote BGP Peering (Event)

by Alistair Mackenzie

Hi, There is an upcoming event here in the UK, EMF Camp ( https://www.emfcamp.org/). There are a bunch of villages doing various things, included is an amateur radio village ( https://wiki.emfcamp.org/wiki/Village:Amateur_Radio) as well as an internet exchange (https://wiki.emfcamp.org/wiki/Village:EMF-IX). We were wondering if it would be possible to tunnel in the AMPRNet from UCSD into the exchange over BGP for the weekend of the event. If so what is the best way to go about this? I'm more than happen to land it on a VM elsewhere (Likely in London) then deal with getting it to the field myself if need be. Thanks, Alistair

6 years, 10 months

3
4
0 0

Strange Connect problem across Com ports to BPQ32 and XROUTER

by vk1kw

Hello All, Have you noticed if you do a "C port Call" connect via a com port from Linux JNOS window with your own (JNOS) call sign to BPQ, BPQ32 or XROUTER that the connection is established but there is no further response in the connection and seems to not respond any more. However if you use another call sign via say Telnet or TNC via JNOS com port, all works fine and the connection across the com port is established and proceeds normally. It makes it hard to test the configuration and have not gotten to the bottom of it yet. This has happened thru several versions of JNOS, but I am using similar autoexec, etc files. Any Ideas please? Secondly, why does McAfee keep quarantining my WIN10 BPQ32.EXE file and also the contents of downloaded BPQ32 EXE ZIP file from the official web site? Thanks Rob Vk1kw

6 years, 10 months

2
4
0 0

Network + Broadcast Blocked?

by Kris Kirby

If -- for example -- one has a /24 delegated, are the .0 and .255 blocked at gw.ampr.org? I haven't tried this, just figured I'd ask. -- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager

6 years, 10 months

2
1
0 0

Re: [44net] network equipment passwords

by Rob Janssen

> Before, or as soon as you attach a piece of equipment to our network > (or anywhere else, for that matter) IMMEDIATELY CHANGE THE PASSWORD. > Oh, and be careful when upgrading firmware: in far too many devices > when you flash new firmware into it, the password gets reset to the > factory default. Be sure to check it afterwards! But, do not see this as a reason to not upgrade firmware! It is really important to keep firmware uptodate, as e.g. was seen in the recent case of MikroTik routers being compromised because they were running firmware before version 6.42.1 which has a vulnerability that allows a remote user to retrieve the correct password from the router! This was fixed some time ago (current version is 6.42.6) but people didn't upgrade, and their router became infected with a botnet that essentially allows it do do anything. In this case, it is also important to change the password after the upgrade, not because it would be reset, but because it could be known to an attacker who retrieved it before the upgrade. In that case they can still login after upgrade! (more details on how to avoid such things can be found on the MikroTik forum, but even the "cannot do! too difficult for me!" type of operator still can upgrade the software as this is only a matter of two clicks in the user interface) Rob

6 years, 10 months

4
4
0 0

network equipment passwords

by Brian Kantor

Most network equipment comes from the manufacturer with a common default password. The bad guys know what these are. Before, or as soon as you attach a piece of equipment to our network (or anywhere else, for that matter) IMMEDIATELY CHANGE THE PASSWORD. If you don't, your device will be hacked in a matter of seconds and you may lose control of it. It might be used to launch attacks on other systems, and may become part of an evil botnet spreading badness across the Internet. Hardly a week goes by that I don't get an official complaint from somewhere that a device on our network has been compromised and is being used to attack other devices. The root cause is almost always that someone attached their shiny new computer/router/accesspoint/camera/toy to the network and it got taken over because they forgot to CHANGE THE PASSWORD. Oh, and be careful when upgrading firmware: in far too many devices when you flash new firmware into it, the password gets reset to the factory default. Be sure to check it afterwards! Thank you. - Brian

6 years, 10 months

1
0
0 0

IPv6, for authentication with IPSEC

by Robert Keyes

I've read the FAQ, and see there is no equivalent IPv6 for our lovely 44/8. My question is, can we utilize IPv6 with our IPv4 address embedded in it? The reason I want to be able to easily utilize message authentication with IPSEC AH. 73, N1YRK

6 years, 10 months

6
6
0 0

Re: [44net] IPv6, for authentication with IPSEC

by Rob Janssen

Yes. but that is not related to this discussion as far as I understand it. He wants to send IPv4 traffic inside IPv6, which can be done locally without issue. E.g. we have GRE6 in use (GRE over IPv6) transporting 44.x.x.x IPv4 traffic between routers. It is always possible to do that, but you need cooperating hosts at both ends. E.g. when you cannot get IP tunnel mesh working due to ISP or router restrictions. Rob

6 years, 10 months

1
0
0 0

Re: [44net] IPv6, for authentication with IPSEC

by Rob Janssen

> I've read the FAQ, and see there is no equivalent IPv6 for our lovely 44/8. > My question is, can we utilize IPv6 with our IPv4 address embedded in it? > The reason > I want to be able to easily utilize message authentication with IPSEC AH. As the discussion got sidetracked into unrelated issues, let's go back to the question. What exactly are you trying to accomplish? Of course it is possible to make some form of tunnel over IPv6 between two AMPRnet systems, and transport the 44/8 IPv4 traffic over that. But you will have to admin both sides of the tunnel. The existing tunnel network operates only over IPv4. When you want to make your own branch, that connects to an existing place with AMPRnet connectivity, and you want to do that over IPv6, that is certainly possible. Rob

6 years, 10 months

2
1
0 0

Setting reverse DNS

by Alistair Mackenzie

Hi, I've got my /24 running via bgp now and was wondering how to set the all the reverse DNS. Is it possible to point the arpa zone to my name servers? Thanks, Alistair

6 years, 11 months

2
1
0 0

Re: [44net] edgerouter

by Rob Janssen

> got myself a nice little edgerouter X from ubiquity. > I was reading the wiki on how to setup the system and something does not ring properly in my head. ( must be the pills I take 😉 ) > So here : http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Ubiquiti_EdgeRouter Note that that article does not describe a complete configuration for an AMPRnet IPIP gateway. Maybe it was just a first attempt at writing a WiKi article, maybe the author did not realize that this method is not correct. With this configuration you would only be able to connect towards internet (which he proves by testing) but not to fellow AMPRnet participants. That requires quite some more effort, see what Marius has created for the MikroTik routers. Rob

6 years, 11 months

2
1
0 0

edgerouter

by pete M

got myself a nice little edgerouter X from ubiquity. I was reading the wiki on how to setup the system and something does not ring properly in my head. ( must be the pills I take 😉 ) So here : http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Ubiquiti_EdgeRouter On a line I see: • ubnt@ubnt:~$ set interfaces ethernet eth0 address <put your AMPRNet network assignment> And when I go to my allocation I have 44.135.51.0/26 Is that what I need to enter? I am no network guru. I play with stuff and want to learn 😉 Tks Pierre VE2PF

6 years, 11 months

2
2
0 0

FAO BK

by Chris

Hi Brian, Are you receiving my emails? Sent you a couple over the past two days but no replies, why is not like you! Suspect they may have been diverted to your spam folder? Chris

6 years, 11 months

5
5
0 0

Beta Documentation for Setting Up BGP Routed OpenVPN Gateway

by John D. Hays

I have found a network service provider who will, upon confirmation form ARDC, advertise an AMPRnet subnet and route traffic to a virtual host (VPS). I have put together minimal instructions on how to setup the OpenVPN server that can then support multiple clients and distribute/route subnets for connectivity to the Internet using AMPRnet addresses. The cost is $5/mo. for the VPS, which could be split among a group to support multiple clients. Have a look at https://groups.io/g/net-44-vpn/wiki/home -- there is a connected file repository for scripts and templates, and a message board for sharing and support. Additional documentation will be provided as it is developed. I have used this with clients on Windows, Raspbian, MacOS, OpenWRT, ... and it works. -- ------------------------------ John D. Hays Edmonds, WA K7VE <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>

6 years, 11 months

2
1
0 0

Freebox bridge mode and option "multiposte"

by Frederic Zulian

Hello, I've put my Freebox in bridge mode and I begin to configure my microtik router. In bridge mode the option "multiposte TV" dosen't seem to work. I think, I must "forward" some ports but which ? Any idea ? -- F1sxo

6 years, 11 months

2
1
0 0

Update of elproxy (my EchoLink proxy/relay server)

by Rob Janssen

I have updated the elproxy.tar.gz file on my webserver: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz There was a race condition in the code that ultimately resulted in some proxies being stuck in the authentication phase. It can be recognized by the debug info in square brackets appearing in the QSO column of the /dev/shm/elproxy status file, like [st4 fd20 t0] It is normal when such info briefly appears, but when it remains for a few seconds that proxy is stuck into a BUSY state without an actual user. This can be checked using: fgrep [st /dev/shm/elproxy and when output appears, repeat it 30 seconds or so later and see if it is still there. On our PI9NOZ proxies, after running 230 proxies for over two months, 6 proxies were stuck. Hard-to-locate problem... Finally, Jann Traschewski has found this bug! Thanks for debugging it and mailing me the patch! The bookkeeping of the usage of filedescriptors was somehow getting out of sync (that I already knew...) and he found it happened in the error handling of TCP connections to the directory server. I had been looking in this area for quite some time, but somehow forgot about the fd used for that purpose and only traced all the paths of open/close of the fd used for the actual user connection... To update, re-fetch the elproxy.tar.gz and unpack (only elproxy.c is changed), re-run make and re-start the program (I run it from its /home/elproxy home directory, when you put it in /usr/local/bin or similar of course remember to move it there again) This is the patchfile of the change, you can apply that using "patch --ignore-whitespace elproxy.c" instead of downloading it again. --- elproxy.c.orig 2016-11-24 10:02:22.000000000 +0100 +++ elproxy.c 2018-06-26 23:43:22.908000000 +0200 @@ -1428,6 +1428,7 @@ buf[0] = 1; close(fd); + pr->tcp_fd = 0; } else { ds->proxy = pr; ds->timeout = now + ADDR_SOCKET_TIMEOUT; @@ -1638,6 +1639,7 @@ close(fd); unregisterfd(fd); + pr->tcp_fd = 0; if (pr->state == BUSY) proxy_message(pr,PROXY_MSG_TCP_CLOSE,0,NULL,0); Again thanks to Jann for finding this! Rob

6 years, 11 months

1
0
0 0

No communication from coordinator

by Alistair Mackenzie

Hi, I submitted a request for a netblock under 44.131.0.0/16 (United Kingdom) over a month ago. I've not heard anything back from the coordinator despite following up with emails. Is there a way we can look to proceed with this request at all? Thanks, Alistair

7 years

2
1
0 0

Where is amprhosts ?

by Pedro Converso

Hello fellows amprs, I've tried ftp://hamradio.ucsd.edu/pub/amprhosts but no avail. Tks for any answer 73, LU7ABF, Pedro

7 years

2
1
0 0

44.190.8.0/24 update

by Tony Langdon

Just an update to let everyone know how things are progressing. Of the allocation of 44.190.8.0/24 that I was allocated a while back, I have allocated a block of 150 IPs for Echolink proxies, which have been operational for around a month. The server that the proxies run on had some pre-existing Echolink proxies and conference servers. I migrated the existing (private) proxies to the new binary, which was seamless. I wasn't sure whether the proxy binary could coexist with the existing conferences, because the proxy binds UDP ports 0.0.0.0:5198 and 0.0.0.0:5199, but in practice, this works fine. On the weekend, I added a new Echolink conference to the server. This conference is the first to use one of the new 44net IP addresses (outside the range the proxies use). Again, everything is working well. The new allocation is getting a bit of use here. And I can confirm that running proxies with the binary alongside conference servers works well. You just have to ensure you use different IP addresses for each in their configs. :) I have allocated a block of 10 IPs for the integrated IRLP/Echolink conferences. Any new conferences will be using these IPs, while legacy ones will remain where they are, unless I need to renumber for some reason, in which case, they will simply be moved to their reserved 44net address. There's a couple of extra items that will be allocated new IPs in this instance. Also, the IRLP side may end up on 44net, in the instance of a renumber. I may simply drop the /28 altogether. And I'm now very happy, the old juggling to find IPs (I was fully utilising a /28 and starting to bump proxies that weren't getting used) is no longer necessary. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

7 years

1
0
0 0

DNS record additions

by Eric Busch

Hello All, I've just got my first allocation and tunneling setup, and now would like to have public traffic routed to my allocation, which I have read requires DNS records to be made for the IPs to be routed. I'm not seeing any obvious way to contact my coordinator in the portal. How is this usually accomplished? Thanks! Eric, W8ETB

7 years

2
1
0 0

Test msg, Ignore Please

by kd4iz＠frawg.org

Apologies. Need a test message to set message sorting rules here. KD4IZ

7 years

1
0
0 0

Encap Database/AMPR Portal Problems?

by Charles J. Hargrove

Is anyone else having problems connecting to other stations? I have about a dozen forwarding partners and until a few minutes ago none were connecting. I still only have 3 connecting now and the rest are all unreachable. I have rebooted my JNOS and it is still occurring. -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 449.025/123.0 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

7 years

6
6
0 0

Fwd: Re: VPNFilter Router Malware

by info＠pb0fh.nl

You did what? This is not very nice! I Really dont like this! Making everyone blind for a pressing security issue is not the fix! Please undo this, censorship is not right. Adding to that, i use shodan and its alternatives more than frequently, and i would like to be ablo to doublecheck my own infra via those web services. M.v.g. Pb0fh Roy van Dongen On 25 May 2018, at 11:07, Rob Janssen <pe1chl(a)amsat.org> wrote: >> I'm not at all sure that Shodan is blocked on amprgw. There are >> more than 2,000 IP addresses that are blocked, with more being added >> from time to time, plus there are a number of tcp and udp destination >> ports that are blocked from all IP addresses, but there's no way >> to be sure that these lists include all Shodan and other scanners. > > I have blocked some known Shodan addresses and subnets, and indeed even > a hoster that is known to be a cesspool and accomodates Shodan and the > likes: > > 66.240.192.138 # census8.shodan.io > 66.240.205.34 # malware-hunter.census.shodan.io > 66.240.219.146 # burger.census.shodan.io > 66.240.236.119 # census6.shodan.io > 71.6.128.0/17 # cesspool! (including shodan.io, project sonar) > 80.82.64.0/20 # ECATEL/QUASI (including shodan.io 80.82.77.139) > 82.221.105.6 # census10.shodan.io > 82.221.105.7 # census11.shodan.io > 89.248.160.0/20 # ECATEL/QUASI (incl shodan.io 89.248.167.131 > 89.248.172.16) > 93.174.88.0/21 # ECATEL/QUASI (incl shodan.io 93.174.95.106) > 94.102.48.0/20 # ECATEL/QUASI (incl shodan.io 94.102.49.190 > 94.102.49.193) > 107.6.151.192 # security.census.shodan.io > 107.6.151.193 # security.census.shodan.io > 107.6.151.194 # security.census.shodan.io > 107.6.151.195 # security.census.shodan.io > 185.163.109.66 # goldfish.census.shodan.io > 185.181.102.18 # turtle.census.shodan.io > 198.20.69.72/29 # shodan.io > 198.20.69.96/29 # shodan.io > 198.20.70.112/29 # shodan.io > 198.20.87.96/29 # shodan.io > 198.20.99.128/29 # shodan.io > > (of course many others, these are just the shodan.io entries) > > I also have some iptables rules that capture TCP SYN to addresses that > are not registered in DNS and > forwards them to an nflog socket to be picked up by some scripts that > finds those that are repeat > offenders. Those are logged as candidates for blocking. But I don't > bother to block everything, > I run reverse-DNS on them to see if it has some signature patterns like > "research", "scan" etc or > one of the known names like shodan.io stretchoid.com etc. > And irregularly I just sort the entire list and glance over it to see > if there are clusters of > addresses and do a whois to see if they belong to some common network. > Names like DigitalOcean > pop up quite regularly but of course they are just cloud hosters that > could also host bonafide > services. > > Rob > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

7 years

2
1
0 0

Re: [44net] VPNFilter Router Malware

by Rob Janssen

> especially before Shodan was > blocked on AMPR... Has Shodan been blocked on amprgw or have they been convinced to stop scanning AMPRnet? There are still various agressive scanners active from internet, and I have some scripts to automatically add them to a blocklist but it still is an ever increasing load on the network. For example, "stretchoid.com" is an agressive scanner that changes addresses all the time (but does keep reverse-DNS records on their virtual servers so easy to identify). They do have an opt-out form but it is a NOP. (I have completed it 3 times at 1-month intervals but no reply and no effect on the scanning... maybe Brian should try it as he is listed in the whois as the owner of NET44) Of course there are others, like security.ipip.net and binaryedge.ninja. Plus the many many other scanners, "researchers", etc. Rob

7 years

4
7
0 0

Re: [44net] VPNFilter Router Malware

by Rob Janssen

> I'm not at all sure that Shodan is blocked on amprgw. There are > more than 2,000 IP addresses that are blocked, with more being added > from time to time, plus there are a number of tcp and udp destination > ports that are blocked from all IP addresses, but there's no way > to be sure that these lists include all Shodan and other scanners. I have blocked some known Shodan addresses and subnets, and indeed even a hoster that is known to be a cesspool and accomodates Shodan and the likes: 66.240.192.138 # census8.shodan.io 66.240.205.34 # malware-hunter.census.shodan.io 66.240.219.146 # burger.census.shodan.io 66.240.236.119 # census6.shodan.io 71.6.128.0/17 # cesspool! (including shodan.io, project sonar) 80.82.64.0/20 # ECATEL/QUASI (including shodan.io 80.82.77.139) 82.221.105.6 # census10.shodan.io 82.221.105.7 # census11.shodan.io 89.248.160.0/20 # ECATEL/QUASI (incl shodan.io 89.248.167.131 89.248.172.16) 93.174.88.0/21 # ECATEL/QUASI (incl shodan.io 93.174.95.106) 94.102.48.0/20 # ECATEL/QUASI (incl shodan.io 94.102.49.190 94.102.49.193) 107.6.151.192 # security.census.shodan.io 107.6.151.193 # security.census.shodan.io 107.6.151.194 # security.census.shodan.io 107.6.151.195 # security.census.shodan.io 185.163.109.66 # goldfish.census.shodan.io 185.181.102.18 # turtle.census.shodan.io 198.20.69.72/29 # shodan.io 198.20.69.96/29 # shodan.io 198.20.70.112/29 # shodan.io 198.20.87.96/29 # shodan.io 198.20.99.128/29 # shodan.io (of course many others, these are just the shodan.io entries) I also have some iptables rules that capture TCP SYN to addresses that are not registered in DNS and forwards them to an nflog socket to be picked up by some scripts that finds those that are repeat offenders. Those are logged as candidates for blocking. But I don't bother to block everything, I run reverse-DNS on them to see if it has some signature patterns like "research", "scan" etc or one of the known names like shodan.io stretchoid.com etc. And irregularly I just sort the entire list and glance over it to see if there are clusters of addresses and do a whois to see if they belong to some common network. Names like DigitalOcean pop up quite regularly but of course they are just cloud hosters that could also host bonafide services. Rob

7 years

2
1
0 0

VPNFilter Router Malware

by LLEACHII＠aol.com

https://www.us-cert.gov/ncas/current-activity/2018/05/23/VPNFilter-Destruct… https://blog.talosintelligence.com/2018/05/VPNFilter.html https://www.thedailybeast.com/exclusive-fbi-seizes-control-of-russian-botnet All, I need to ask you now...do any of you keep Netflow records? If so, can you scan your records from 01JAN2016-31OCT2016 for: > proto TCP and dst net 44.xxx.xxx.xxx/xx and dst port 2000 As you go back in time, I think you'll find the origins of the IPs tell a story different than the links above...especially before Shodan was blocked on AMPR... 73, - Lynwood KB3VWG

7 years

1
0
0 0

Gateway 75.101.96.109 not receiving full traffic for 44.4.39.8/29

by Jeremy Cooper

I run the gateway at 75.101.96.109 and have assigned my network, 44.4.39.8/29 to it in the portal a long time ago (more than a year ago). I receive packets destined for the first allocated address (44.4.39.8) but I'm not receiving traffic for any of the other hosts in my range. Did I miss a crucial update about network allocations? -- Longer version below: I've made sure to log into the portal every now and then to keep my assignment fresh, but just today I decided to actually try to start connecting hosts inside my allocation. To do some tests, I tried pinging the first assignment in my net, 44.4.39.8, from an outside host. That worked fine. I successfully received the tunneled IPIP packet from amprgw.ucsd.edu, de-encapsulated it, found that the inner destionation was 44.4.39.8, and sent it on its way to my inside network. When I attempt to hit other hosts in my allocation, however, I never even receive the IPIP packet for them. Traceroute from my test host seems to indicate that the packet never even makes it to UCSD; it stops one hop short, at sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50). WORKING HOST Traceroute to 44.4.39.8: traceroute to 44.4.39.8 (44.4.39.8), 64 hops max, 40 byte packets 1 50-0-193-1.dsl.static.fusionbroadband.com (50.0.193.1) 23.641 ms 19.205 ms 18.704 ms 2 xe-0-0-20.cr2.colaca01.sonic.net (70.36.228.117) 39.927 ms 72.901 ms 30.780 ms 3 0.ae0.cr3.colaca01.sonic.net (198.27.244.130) 37.454 ms 35.465 ms 33.255 ms 4 * * * 5 50.ae4.gw.pao1.sonic.net (50.0.2.5) 19.397 ms 19.728 ms 20.012 ms 6 palo-b22-link.telia.net (213.248.81.254) 19.673 ms 19.190 ms 19.935 ms 7 sjo-b21-link.telia.net (62.115.125.1) 21.363 ms 20.989 ms 20.647 ms 8 las-b21-link.telia.net (62.115.116.41) 26.836 ms las-b21-link.telia.net (62.115.136.46) 37.521 ms 33.204 ms 9 limelight-ic-320599-las-b21.c.telia.net (213.248.96.65) 68.480 ms 28.275 ms 28.070 ms 10 198.32.251.189 (198.32.251.189) 31.314 ms 32.787 ms 28.098 ms 11 137.164.11.25 (137.164.11.25) 33.761 ms 36.236 ms 137.164.11.23 (137.164.11.23) 33.997 ms 12 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 40.166 ms 137.164.11.11 (137.164.11.11) 34.933 ms 31.510 ms 13 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 36.912 ms 36.172 ms 32.772 ms 14 mcore-flow-bypass-mx0-p2p.ucsd.edu (132.239.254.61) 39.436 ms 38.211 ms 42.078 ms 15 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50) 37.436 ms 37.872 ms 36.955 ms 16 amprgw.ucsd.edu (169.228.34.84) 32.790 ms * 33.361 ms 17 ke6jjj-8.ampr.org (44.4.39.8) 35.951 ms 36.368 ms 32.583 ms NON-WORKING HOST Traceroute to 44.4.39.9: traceroute to 44.4.39.9 (44.4.39.9), 64 hops max, 40 byte packets 1 50-0-193-1.dsl.static.fusionbroadband.com (50.0.193.1) 69.583 ms 19.148 ms 19.244 ms 2 xe-0-0-20.cr2.colaca01.sonic.net (70.36.228.117) 120.800 ms 68.925 ms 88.207 ms 3 0.ae0.cr3.colaca01.sonic.net (198.27.244.130) 91.626 ms 34.418 ms 76.632 ms 4 * * * 5 50.ae4.gw.pao1.sonic.net (50.0.2.5) 23.116 ms 19.177 ms 19.248 ms 6 palo-b22-link.telia.net (213.248.81.254) 19.647 ms 19.396 ms 19.452 ms 7 sjo-b21-link.telia.net (62.115.125.1) 20.457 ms las-b24-link.telia.net (62.115.119.91) 36.542 ms sjo-b21-link.telia.net (62.115.125.1) 20.644 ms 8 las-b21-link.telia.net (62.115.136.46) 33.996 ms las-b21-link.telia.net (62.115.116.41) 26.532 ms las-b21-link.telia.net (62.115.136.46) 33.467 ms 9 limelight-ic-320599-las-b21.c.telia.net (213.248.96.65) 36.186 ms 28.669 ms 28.199 ms 10 198.32.251.189 (198.32.251.189) 30.786 ms 33.225 ms 31.040 ms 11 137.164.11.25 (137.164.11.25) 32.792 ms 33.481 ms 32.755 ms 12 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 38.265 ms 137.164.11.11 (137.164.11.11) 31.252 ms 32.276 ms 13 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 37.461 ms 37.917 ms 36.964 ms 14 mcore-flow-bypass-mx0-p2p.ucsd.edu (132.239.254.61) 36.682 ms 33.464 ms 36.222 ms 15 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50) 33.497 ms 37.393 ms 36.970 ms 16 * * * 17 * * * 18 * * *

7 years, 1 month

2
2
0 0

44.190.8.0/24 is online!

by Tony Langdon

Got my allocation online and have reconfigured elproxy to provide 150 public proxies, in addition to the existing 4 private proxies. Got a geolocation issue causing incorrect allocation of proxies, but have submitted change requests with 3 of the major geolocation providers. :) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

7 years, 1 month

2
1
0 0

Re: [44net] Network 44.190.5.x work!

by Rob Janssen

> Sorry, I can't agree on that. Without manual interaction Echolink > Repeaters behind traditional IPIP-Mesh gateways are not reachable > through the NLD Echolink Relays/Proxies. That is NOT CORRECT! It will work just fine when the repeater is behind a traditional IPIP mesh gateway which sends traffic to internet via amprgw (the setup described in the Wiki). It will only fail when shortcuts are made and traffic to internet is sent via some local NAT router instead of via the IPIP mesh. As the Echolink protocol cannot handle this situation (as described above) one needs to make sure that Echolink traffic is not sent via this NAT shortcut. The Echolink system is perfectly happy with clients, proxies and relays on NET44, it is only the bad configuration of gateway systems that will break it. Rob

7 years, 1 month

3
2
0 0

Network 44.190.0.0/16 - Further information

by Jann Traschewski

Description: The network 44.190.0.0/16 is available to host amateur radio internet services using direct BGP. Allocations will be made usually in /24 chunks. The focus of this network is to transfer data as direct as possible (no radio, no tunnels) to keep reliability high. AMPRNet systems with no dynamic routing protocol support are able to route 44.190.0.0/16 via their ISP. Background: AMPRNet allocations are not partitioned by connectivity type. Each individual network can either be of type "radio", "tunnel" or "direct". AMPRNet systems may be "dual homed" and have a line based and a radio connection, thus there needs to be a decision whether a packet should be forwarded by line or by radio. This _could_ be achieved by AMPRNet systems *with* dynamic routing protocols by learning the routes and treating each route by its type (or any other available "flag"). However this will _never_ be the case for AMPRNet systems *without* support for dynamic routing protocols. Endusers running a *radio* connection to AMPRNet infrastructure such as HAMNET User Acess Points, IPIP-Mesh Gateways or even direct-BGP Gateways might ask how to integrate the radio connection into their home-LAN to have permanent access using any device on their LAN. Unfortunately standard home routers do not provide dynamic routing protocols, but there is often the functionality to add additional static routes like "44.0.0.0/8 via radio" and "44.190.0.0/16 via ISP". Sometimes customers are *forced* to use the router provided by the ISP to access the Internet (such a requirement is prohibited by law in Germany). Those might have no functionality to set static routes at all and you might end up attaching another router to the router to gain more functionality... As of today the standard setup for "dual homed" AMPRNet systems *without* support for dynamic routing protocols is to add 44.0.0.0 netmask 255.0.0.0 via <radio device within the home-LAN>. Outbound connections to 44.x.x.x will be made by their radio with the source-44 address and outbound connections to the Internet will be made with the source address obtained from the ISP. This worked without any issues as long as there were no direct BGP allocations within the network44. Nowadays we have several amateur radio internet services provided on the Network44 by direct BGP and the accessibility for the above mentioned AMPRNet systems highly depends on a proper radio connection and the backbone infrastructure to transfer the packet to its destination. The idea of 44.190.0.0/16 is to give willing stakeholders the opportunity to improve the situation. Amateur radio internet services can be hosted in that range while AMPRNet systems can make use of the additional route 44.190.0.0/16 via their ISP. The following issue has much more impact: Once direct BGP allocations started within the Network44 we encountered situations of full incompatibility. It is the case for amateur radio internet services (e.g. Echolink) working with a directory to map callsigns to IP addresses. Echolink does learn the IP address of an Echolink station (respectively of the used Echolink Proxy or Relay) from the inbound connection to the directory service. This leads to the problem, that AMPRNet systems forwarding 44.0.0.0/8 to the radio device on the roof will not have a slow or weak connection to a Echolink station using direct BGP but even *no* connection at all. Since they are registered on the Echolink network with their IP address obtained from the ISP but appearing with their Network44 address used over radio at the Echolink station using direct BGP, the connection is dropped due to a mismatch between "IP address <-> callsign". This will not happen if Echolink Relay/Proxy Servers or Echolink Stations will make use of address space from 44.190.0.0/16 while AMPRNet systems route 44.190.0.0/16 via their ISP. There will be no IP mismatch anymore. I made a diagram explaining the situation: http://db0fhn.efi.fh-nuernberg.de/~dg8ngn/echolink-amprnet.pdf 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX / DB0FOX / DB0ZM / DB0DBA / DB0HZS

7 years, 1 month

11
19
0 0

DNS Web tool

by Brian

For those who use my Amprnet DNS management web tool, just a note to let you know it's been completely rewritten. Your login credentials will still work, and it still forces SSL/TLS, but now reCaptcha has been added. I tried to keep the look and feel of it somewhat similar to the old one. Don't be shocked when you see a captcha box on the screen now. -- Did you know that dolphins are so smart that within a few weeks of captivity they can train people to stand on the very edge of the pool and throw them fish? ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org IPv4: 44.88.0/28 IPv6:2001:470:8a1e::/48 https://uronode.n1uro.com (dual stacked) https://n1uro.ampr.org (dual stacked)

7 years, 1 month

1
0
0 0

Re: [44net] Network 44.190.0.0/16 - Further information

by Rob Janssen

> Each 44.190.x.0/24 subnet arranges its own BGP advertising, > so there isn't just one point. They are spread all over the > world. > - Brian Note that due to this, the approximate location in IP geolocation databases has to be set for each of the /24 subnets. The default location for 44.0.0.0/8 is San Diego, California, USA. I have set the location for 44.137.0.0/16 to Amsterdam, Netherlands and other country ip coordinators have done similar for their countries. And of course an individual amateur can set a more accurate location for their smaller subnet. It comes into play for some services that use IP location aware DNS to direct users to a geographically closest (and hopefully this translates to closest in network topology) service. With all the 44.190.0.0/16 networks located in San Diego this of course isn't going to work. Echolink is such a service that users IP geolocation. You can enter an address from your subnet in lookup services like this: https://www.iplocation.net/ It shows what some of the more important services return for your location. And when clicking on the link for each service it is usually easy to submit location data for a subnet to that service provider. Rob

7 years, 1 month

5
5
0 0

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site

by Rob Janssen

> One thing I'm unclear on with Mikrotik is their different generations of > hardware. I DO want to make sure I get the newer generation so, in > theory, I get the longer supported OS support. Does anyone know if the > CCR1009-7G-1C-1Splus is a new generation of hardware or is it older? > Regarding buying a box that can run "The Dude" on an internal SSD, do > Wifi, or other stuff on the side. That was something I was planning on > running on a separate machine with say TICK, Zabbix, etc. Not sure but > I seriously worry if something goes south in that system, can it harm > the router. That's NOT acceptable in my book. The CCR1009-7G-1C-1Splus is the latest model in the CCR series, but the RB1100AHx4 is a newer router that could well be the root of more new models in the future. Of course one never knows such things for sure, but the Tilera TILE processors in the CCR series appear to have less current development than the processor used in the 1100. I would expect MikroTik to support the CCR in software updates at least for some years. Remember that all MikroTik routers include software support for the support lifetime of the device, no need for a separate support contract for that. The selection also depends on the network architecture. The RB1100AHx4 has two hardware switch chips each driving 5 ports so you can have hardware switching between those ports, while the CCR series ports are all independent router ports, they are expected to be connected to an external switch when you want hardware switching. So the CCR is a true router while the RB1100AHx4 is a router-switch combination. And the CCR has an SFP and SFP+ slot for fiber etc. The CCR does not have internal M.2 SSD like the RB1100AHx4 Dude edition, but it has a slot for an SDHC card and a USB port that both can be used for external storage. Rob

7 years, 1 month

1
0
0 0

OT: Recommendations for a small to medium size router for a multi-purpose repeater site

by David Ranch

Hello Everyone, Considering there is a good chunk of routing-savvy HAMs here, I thought I'd use you as a sounding board on what would be a good router to buy. Specifically, I have a project to consolidate the current adhoc setup of three consumer grade "routers" to one larger, better router. I'm considering something like a: https://mikrotik.com/product/CCR1009-7G-1C-1Splus <https://mikrotik.com/product/CCR1009-7G-1C-1Splus> or maybe https://mikrotik.com/product/rb1100ahx4 <https://mikrotik.com/product/rb1100ahx4> I'm looking for something that is: - very stable - offer long term software updates (a support contract might be fine) - Has strong support for IPv4 NAT (to better the consumer routers mentioned above) for the three IPs we have onsite - maybe some L2 segmenting and vlan'ing support for traffic isolation - has performance to grow into - has a decent GUI UI for others in the club who can't / won't cope with a CLI - ACLs to limit incoming traffic to specific hosts (say limit RDP traffic to just some people to some hosts, etc) - maybe.. just maybe support SSL VPNs or IPSEC - maybe dual power supplies - stretch goal: native support for IPv6 - I have no need for dynamic routing protocols. This is a single site and statics are fine For background on our needs, the site supports a multi-RF link repeater system has: - two unique IRLP nodes (low use) - one Echolink node (low use) - one WIresX enabled Yaesu System Fusion repeater (decent use) - One three band Icom Dstar stack (1.2Ghz DD system as well) (decent use) - One Internet enabled Motorola DMR repeater (decent use) - backhaul of rarely used multi-county 3.4Ghz wifi network - other random needs for remote management (SSH, RDP, etc) I believe something like a Miktrotik would be fine for our low-end needs but maybe something from Ubiquiti or others would be fine. I'm perfectly comfortable with a CLI and I'm decently versed in Mikrotik (a bit weird of a UI), IOS (but I don't want to pay for Cisco prices, JUNOS (same point), etc. I personally think a lot of the lower tier vendor's products have come a LONG way so I don't need/want/care for "carrier" grade. If you have any other recommendations for a quality but not too expensive router, I'd love to hear it! --David KI6ZHD

7 years, 1 month

5
5
0 0

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site

by Rob Janssen

> The power can be provided by a picopsu 150 watt is usely more then enough The CCR1009 (a router with 9-core 1200 MHz TILE CPU, 1 10Gbps and 8 1Gbps ports) consumes 20 watt in actual use. It comes with dual (redundant) powersupplies, dual (redundant) fans (or passively cooled) and is ready to use for $495 The RB1100 is even less, $299 without or $349 with the 60GB disk option. Rob

7 years, 1 month

2
1
0 0

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site

by Rob Janssen

> I would go with a small itx pc with dual gygabit nic and a 4 port pcie gygabit nic. that give you 6 nic in a box. > Run this under Openwrt, or opensense or pfsense. You could even run miKrotiK OS > you can have a small ssd in there and 4 gig of ram to be sure all is ok and this setup would be able to do all of your need and even more. Of course it also uses more power, and takes more effort to construct and install. It can sometimes be useful to have more flexibility, but for general router usage it usually is overkill. Those MikroTik boxes work after unpacking and some basic config tasks. However you can still spend hours and hours to make them do a lot more :-) Rob

7 years, 1 month

4
5
0 0

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site

by Rob Janssen

I agree with what Marius wrote. Those models will perform very well in a network like that. We use a CCR1009 in our gateway for the 44.137.0.0/16 network (BGP routed on internet) and use it to provide VPN services to users and nodes inside the country, and to feed the radio network as well. The RB1100AHx4 should be equally capable of that. I would avoid the RB3011, should there be a tight budget or should there be a need for smaller devices at other places in the network it is better to use models like RB750Gr3 or the proven RB2011. As with any router and in fact with any device connected to internet, you will have to make sure it runs uptodate software (software can be upgraded for free as long as the device gets software updates, which will be quite some time for these models) and also you have to configure it in a reasonably secure way, e.g. make sure the management interfaces (telnet, ssh, webfig, winbox) are only accessible for your own people and not for the internet at large. This can be done by restricting them to certain interfaces, subnets, individual addresses on internet, and/or by using a VPN for management access. Keeping the management ports (22,23,80,8291) open on internet has proven to be a recipe for disaster. Rob

7 years, 1 month

1
0
0 0

Wrong portal entry 44.151.31.6

by Marius Petrescu

Hello, There is a problematic entry in the portal which needs our attention: 44.151.31.6 / 32 via 44.151.31.6, according to the portal allocated to F1SXO, France, Occitanie, Haute Garonne The problem is that the RIP entry 44.151.31.6 via 44.151.31.6 is wrong, ilogical, and creates a routing loop. On Mikrotik routers, this will sow as a flapping of the ampr-44.151.31.6 interface. The solution for the moment is to filter that entry in the RIP filters and delete the 2 routes to it and its associated interface by hand. I had no time to check the behavior on ampr-ripd and amprd systems but is basically lead to the flapping of the route. After correcting this issue in the portal, on these systems, a remove of the static route 44.151.31.6 via default gw should be necessary (ampr-gw and amprd do not remove those static routes - known problem). The final solution is to correct the entry in the portal. Marius, YO2LOJ

7 years, 1 month

2
2
0 0

Setting up a tunnel to my BGP's 44net range

by Tony Langdon

Now that my BGP announced 44.x range is up and running, I'd like to be able to make it transparently accessible for tunneled networks. I just need to double check a few things. First, I know I'd need to run ampr-ripd on the box. I also have non-44 net addresses to use as the ipip encap endpoint. What else do I need to do? Do I need to advertise the subnet as "tunneled" in addition to direct in the portal? Anything else? Reason for this is I'm likely to be running services other than Echolink proxies, which may require peer-peer connectivity. Currently, 44.x tunneled addresses connecting to the system would go via their local router, which most likely involves NAT. And on a similar note, is there a way to exclude other directly connected subnets capable of IPIP tunneling from using a tunnel? (since that's obviously not required!) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

7 years, 1 month

3
6
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> How does Echolink distinguish "incorrect password" from other > conditions? Or does it assume that if a connection is dropped at a > certain stage, then it's an incorrect password? Well my description was from memory and not entirely correct. There are only two error codes that a proxy server can return to the client, one for "bad password" and the other for "access denied" (i.e. the presented callsign fails the check to the CallsignAllowed or CallsignDenied patterns in the config, usually using wildcard checks like "deny -R" to deny repeaters) However, there is no error code for "proxy busy", a busy proxy simply disconnects new users before they even authenticate. There is also no way to return an error message text, the error is returned as a code and the client issues an appropriate message to the user. So you cannot communicate a more detailed message like "this proxy is reserved for ...". However, you can use a private proxy (different password) to achieve that. > But yes, good idea, I can block incoming connections on TCP 8100 (proxy > port) on the IPs that conferences are using. Thanks for that suggestion. Indeed, when you setup your firewall to just refuse connects from other systems they will believe this proxy is busy. However, when the proxy used by the conference is private and (nearly) always busy, there is not much you need to do as it works fine by default. The worst that could happen is that someone DoS'es you by repeatedly trying to connect to the proxy at a time the conference server isn't connected and then proceed through the authentication as slow as it can, and once it gets disconnected immediately re-connect before the conference had a chance to do that. I have not yet encountered such behaviour. Rob

7 years, 1 month

1
0
0 0

Re: [44net] Setting up a tunnel to my BGP's 44net range

by Rob Janssen

> Now that my BGP announced 44.x range is up and running, I'd like to be > able to make it transparently accessible for tunneled networks. I just > need to double check a few things. > First, I know I'd need to run ampr-ripd on the box. I also have non-44 > net addresses to use as the ipip encap endpoint. What else do I need to > do? Do I need to advertise the subnet as "tunneled" in addition to > direct in the portal? Anything else? That is all you need to do. There is no need to setup policy routing ("ip rule") in this case, and also you should not add any static routes such as a default route for AMPRnet traffic. Only use the routes provided by ampr-ripd and load them into the main table. Indeed you need to check "tunneled" in the portal. It is a desirable step for any BGP advertised subnet, not only for the echolink proxies, to do this. It will allow communication with those that are "only" on the tunnel mesh (i.e. they do not route towards internet, or do NAT when routing to internet), and it is more efficient than doing that via another gw like ampr-gw. And it is quite a simple setup. Of course you should also consider the effect on the firewall settings. Rob

7 years, 1 month

2
1
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> One thing I would like to be able to do with the proxy server is have a > whitelist and blacklist of local IPs, so no one can accidentally DoS a > conference running on the same server, or find themselves with a non > functional proxy (and a lot of head scratching!), because the UDP ports > are being used by a conference. If they connect on a blacklisted IP, > the proxy would simply issue an error saying connection is not permitted > (since the TCP side can safely be opened, this should work). Proxy servers do not issue error messages. They only thing they can do when they don't want your connection is to simply close it immediately, or refuse it entirely. You can solve that in the firewall. However, when you want to reserve a proxy for a conference or other usage, you can simply set a different password than PUBLIC for it. That will make it a private proxy which can only be used by a user or service who knows the password. (and it will not appear in the proxy list) Rob

7 years, 1 month

2
1
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> >/I think your best and safest bet would be to find a conference server /> >/that can use a proxy. /> I don't understand what you mean, this looks self evident to me. What I mean is: is the conference server that you want to use configurable so that it does not open a set of UDP sockets, but instead connects to a proxy server you specify (address, port and password) ? If so, just configure it to connect to one of the proxies you run in elproxy on the same machine and there will be no issue and no uncertainties. Of course, when it works directly on a set of UDP ports without disturbing the proxies and relays running on the wildcard socket on the same machine, that is fine as well. Rob

7 years, 1 month

2
1
0 0

OpenWRT Pull Request and question about ampr-ripd

by lleachii＠aol.com

All, I hope some of you may be more familiar whit getting software added to Open Source projects than I am. Is this the primary location for the ampr-ripd makefile, or does anyone else maintain the makefile elsewhere? https://github.com/rufty/ampr-openwrt Also, in my ampr-ripd, I require the following line to compile for OpenWRT: #define IPPORT_ROUTESERVER 520 This is not reflected by a patchfile. Has anyone had success compiling ampr-ripd for OpenWRT without adding the line above? 73, - Lynwood KB3VWG

7 years, 1 month

2
2
0 0

Re: [44net] OpenWRT Pull Request and question about ampr-ripd

by Rob Janssen

> All, > I hope some of you may be more familiar whit getting software added to Open Source projects than I am. Is this the primary location for the ampr-ripd makefile, or does anyone else maintain the makefile elsewhere? > https://github.com/rufty/ampr-openwrt <https://github.com/rufty/ampr-openwrt> I use the makefile supplied by the maker in the source .tgz file supplied on his site: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.3.tgz I have found no need to apply any patch. > Also, in my ampr-ripd, I require the following line to compile for OpenWRT: > #define IPPORT_ROUTESERVER 520 That define is normally found in this file: /usr/include/netinet/in.h Maybe you can suggest the author to add this in the code: #ifndef IPPORT_ROUTESERVER #define IPPORT_ROUTESERVER 520 #endif Rob

7 years, 1 month

1
0
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> I have seen that with tbd, which opens 5198 and 5199 UDP on 127.0.0.1 > for commands and chat respectively, while the default configuration has > Echolink listening on 5198 and 5199 on 0.0.0.0, so there is hope. Will > have to test further, though I was able to connect from my new proxy to > one of the conferences on the same box. I think your best and safest bet would be to find a conference server that can use a proxy. A service connected via a proxy has full functionality (this is different from a relay) and there is really no disadvantage to having a service connected to a proxy hosted on the same machine. Doing this, only the elproxy program has to open sockets for 0.0.0.0:5198 and 0.0.0.0:5199 and there are no conflicts. Of course it would still be interesting to know if a program can be listening e.g. on 44.128.0.1:5198 (UDP) while another program on the same machine is listening on 0.0.0.0:5198 and will receive all UDP to port 5198 except to address 44.128.0.1 Rob

7 years, 1 month

2
1
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> Now that my IPs are propagating, I am attempting to convert my existing > 4 private Java proxies to your code. Looks like it is working, but I do > have some questions to avoid potential issues. The old proxies were > defined by IP address - IP addresses are very tightly controlled, > because there's a mix of proxies and Echolink conferences running on the > one machine. My program does not listen on individual addresses. It opens a wildcard socket for each port, receives the traffic and gets the addresses from the OS using special system calls. That way it can run serveral proxies and relays using only very few sockets, improving the efficiency of the select(). You can just move over the existing Java proxies to the C program. Stop the Java proxies and add their addresses to the config file of the C program. I have no experience with conferences, I do not know if they can co-exist on the same machine with the proxies. Probably not. It is probably best to use a separate (virtual) machine for them. However, I am not sure. It could also be that having the software that opens ports at an explicit address and these wildcard ports can co-exist. Rob

7 years, 1 month

4
7
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> If they both use the same ports they cannot coexist on the same machine. > Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine > Ruben - ON3RVH Yeah I sort of remembered that, but I wasn't sure. Thanks. (it might as well have been possible when the kernel first checks the specific address sockets and would fall back to the wildcard socket when none matches) Unfortunately I have no experience with running conference software at all. When a conference can run via a proxy, it can still be done on a single machine! Just configure all the conference addresses as proxies, make these private, and connect the conferences to those. All UDP I/O will be via the wildcard sockets and the TCP connects can be local on the same machine. (selected proxies can be made private by configuring something like Password_51=mysecretpassword while the global setting is Password=PUBLIC) Rob

7 years, 1 month

1
0
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> Rob and all, > Not sure if my other message got to Rob but sending it here to group. I have sent two mails to you in reply to your direct message. When you do not see them, please check your Spam folder, and if it isn't there please send another direct message and I will send from a different mail address. @amsat.org mail is blocked by some providers. Rob

7 years, 1 month

1
0
0 0

Re: [44net] Echolink proxy/relay hosting

by Rob Janssen

> >/3) Obtained and compiled Rob Jenssen’s C program, configured it per the instructions. /> I have read the docs, looks pretty straightforward, though I have a bit > of migration to do - after initial testing, I have several existing > private proxies to migrate to the binary, then create the public ones on > the 44.x addresses. For everyone's info: I have updated the file at http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz (also available on www.pe1chl.ampr.org on net44) to include an init.d script example and a logrotate.d config file. Everything else is unchanged. I welcome corrections or suggestions for changes in the README file when something is unclear. Make sure you follow everything written in the file as it is now. (especially the part about sysctl and the proxy_message logging) I should probably some description of what proxies and relays are and how they are used, that was already sent to this list however. Rob

7 years, 1 month

3
2
0 0

jnos2.0k problems

by vk1kw

Hello 44net, Not sure who I should address this issue to but I guess it's to you please Maiko. Would someone reassemble the jnos2.0k.tar.gz file to make it easier to compile and run please? It must be a nightmare for the newbie. Problem is that the installer2.1 is not included in the jnos2.0k.tar.gz. The correct files.h is not included, the tun.c file does not work and should be replaced by tun_sp1l.c under Fedora 26 and others. All these have separate downloads and driving instructions. The nos.cfg file does not seem to be included in the 2.1 installer either, and was recovered from a previous install. Not to mention the too and froing from my home directory to root after the install was run. So on top of all that, and after what seems to be a good compile of jnos2.0k, the NETROM function still does not work and crashes after the 11th line of the first nodes transmission. Almost looks like a memory overflow but there is plenty supplied in the "qlimit" Have tried jnos2.0k after a fresh installer2.1 and just added netrom and still crashes the same. I have tried to get "k" working after many attempts, directory changes, in root and home, etc, etc but directly replacing the compiled jnos2.0k with jnos2i or jnos2h exec and netrom works fine. The last time I tried to capture the crash it locked up the PC. Is jnos2.0k transportable between directories other than named "jnos" (tried that) I currently manually run jnos2i in my home directory under sudo successfully. Is anyone else running jnos2.0k netrom successfully and what is the fix please? The reason for the revisit to jnos is because I now have 50Mb down and 5Mb up thru new internet service provider NBN/iinet. Many thanks Rob Vk1kw

7 years, 1 month

1
0
0 0

Edits to OpenWRT Wiki

by lleachii＠aol.com

All, I have made some extensive updates and edits to the OpenWRT WIki: * Routes and rules are now included in the UCI * The Startup script only sets up the tunnel and ampr-ripd, it has been reduced to 7 lines. To do: * Edits if ampr-ripd is added to the OpenWRT repo. http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT 73, - Lynwood KB3VWG

7 years, 1 month

1
0
0 0

GW (amprgw, gw.ampr.org) downtime tomorrow evening

by Brian Kantor

UCSD is swapping out some networking equipment and amprgw (aka gw.ampr.org, 44.0.0.1) will be unreachable for a while starting around 7pm Pacific time Thursday (tomorrow). It should take only a few minutes, but as both the connection and configuration have to be transferred to the new equipment, there is always the possibility that it will take longer or something else may go wrong. - Brian

7 years, 1 month

7
11
0 0

Re: [44net] GW (amprgw, gw.ampr.org) downtime

by Rob Janssen

> The network equipment changeout at UCSD did NOT go well; they are > still having problems with the network 44 routing into UCSD. There > is yet no estimated time to repair at this moment. I'll update you > folks as I learn more. > As of 1:30 am Pacific time (GMT -7:00), everything is working again. > - Brian As you know very well, it always takes more time than estimated... It affected our gateway since a script that downloads the DNS zone when modified got stuck, halting a cronjob script that also performs other maintenance tasks. Modified with some more safeguards... :-) Rob

7 years, 1 month

1
0
0 0

Re: [44net] An apology for the Internet from the people who built it

by Rob Janssen

> Now you got me! Atari ST! I was responsable of the Montreal Atari Club BBS when it was on 8 bit and 16 bit. Still play a few games on my ST emulator.. Remember when we ware able to simulate a MAC with a few roms and a ST? 😉 > OK, back to our regular programing. Think we got back way too far on memory lane for this mailing list 😉 I still have a Mega ST4 with harddisk cabinet and original monitor sitting in a spare room but it rarely gets switched on these days. (those were the newer pizza-box style ST and disk. the disk cabinet in fact is a 44MB swappable plus a fixed disk) This one is fitted with an ethernet adapter I made (a PC ethernet card and adapter board to the internal bus) and I added a driver for it to KA9Q. However, the card has BNC and AUI only and I don't have coax ethernet anymore. Should have an AUI to RJ45 adapter somewhere. Also in storage there is a Mega ST2 with an 8-port Z8530 SCC card that we used for years on a major network node (TCP/IP and NET/ROM)... (of course I had a 520ST as well but that one has long been scrapped) Rob

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net