44net

44net@mailman.ampr.org

3179 discussions

Update on AmprGW, UCSD, and Network Telescope

by John Gilmore

Someone asked a few weeks ago: ... the Trustees would presumably be completely free to give an update on the planned relationship with CAIDA (UCSD Network Telescope), and long-term sustainable plans for AmprGW? The relationship between ARDC and UCSD's CAIDA research group remains as it was before Brian Kantor's death. There is a Memorandum of Understanding (MoU) between UCSD and ARDC that defines this relationship. The MoU was negotiated between Brian (for ARDC), and the UCSD management (for CAIDA). In particular, Brian wanted and succeeded to get this arrangement nailed down before he retired from being on staff at UCSD. The Network Telescope and the amateurs-to-Internet relay operate from the same network infrastructure in a lab at UCSD. Both parties gain from the arrangement. UCSD observes traffic sent to a large section of unused address space, and has created an analysis environment to facilitate its sharing of this data with vetted researchers. ARDC gets a well maintained, high speed interconnect between its users and the Internet. Typical amateur tunneled traffic through AmprGW is well under a gigabit per second, averaging about 30-60 megabits/sec, with bursts 60-90Mbps. (This traffic occupies twice that bandwidth, since every packet that comes in, then goes back out through one of hundreds of tunnels; and vice verse.) Typical non-amateur, Telescope traffic, bursts to 800Mbps and averages between 500 and 600 megabits/sec. There are currently no plans to change this arrangement. However, the main source of funding for the Telescope project expired this year, and it is not yet clear whether or how the data-sharing (i.e., the expensive) aspect of the project will continue. On the plus side, the existing hardware and software that supports ARDC is all paid for, installed, and running; it would involve work to tear it down. From the ARDC side, Chris Smith, G1FEF, has full access to AmprGW from the UK, and continues to maintain it as Brian did, with intermittent "hands-on" help from a local CAIDA sysadmin. As BDale recently reminded us, Chris also maintains other ARDC infrastructure such as the Portal and the website, which run in virtual machines hosted in various data centers. If UCSD and CAIDA ever decided to cancel the MoU, shut down the Telescope, and/or stop collaborating with ARDC, ARDC could move AmprGW to a virtual machine in a well connected data center anywhere in the world. Now that ARDC has more than nominal amounts of money, it can afford to pay for bandwidth and servers. AmprGW remains at UCSD today, partly because continuing that arrangement was simplest while scrambling to pick up the pieces after Brian died; and partly to honor the MoU, and Brian's history there, and to continue enabling Internet research worldwide, since CAIDA provides access to telescope data to vetted academic researchers. There are 4 pages of explanation, signatures, etc in the MoU, which is a public record of the Regents of the University of California, accessible under the California Public Records Act. Here are the relevent bits: This agreement is not intended to be legally binding, and instead is an aspirational document between the parties outlining responsibilities, and expectations of the parties. UCSD SHALL: o Operate network hardware and software to provide colocation services for the AMPRNet(TM) TCP/IP networks for Amateur Radio on UCSD infrastructure. o Agree to safeguard the UCSD equipment and network resources using best practices for network management. o Agree to use and comply with best practices for safeguarding data to mitigate privacy and security concems and to comply with legal requirements when using the data collected on AMPRnet's network for research critical to the Center for Applied Internet Analysis (CAIDA) research group located at the San Diego Super Computer Center. COLLABORATOR SHALL: o Agree to allow UCSD to collect, filter and curate data destined for the AMPRNet(TM) network for the purposes of network research and responsible data sharing with the network and security research communities. COMMENCEMENT/EXPIRATION DATE. This agreement is executed as of the date of last signature and is effective through [July 31, 2023] at which time it will expire unless extended. The U.S. federal research funding that supports the Telescope is: https://www.nsf.gov/awardsearch/showAward?AWD_ID=1730661 The proposal that NSF funded is this one: https://www.caida.org/funding/stardust/ CAIDA's most recent slide deck about the Telescope is: https://www.caida.org/publications/presentations/2019/stardust_dust/stardus… The Principal Investigator of the Network Telescope is Alberto Dainotti <alberto(a)caida.org>. He intends to release a new web site and documentation for this project by the end of 2020. This will include a list of research enabled by the telescope (papers, data, analysis tools). In the meantime, there is a preliminary Grafana dashboard that shows that the Network Telescope is seeing (in real time, or from the past). https://explore.stardust.caida.org/d/ClIeIwOMk/stardust-public-protocols (It's work in progress! BTW, it uses Keycloak for authentication, so people can now use github or globus credentials to log in). Access to the Telescope data is controlled to preserve the privacy of the users all over the Internet whose (typically malware-contaminated) sites originated the packets. Researchers who use the data must sign a contract agreeing to maintain that privacy. Note that none of the data in this Network Telescope is the traffic of authorized amateur users. All that traffic is filtered out before it is recorded for researchers by the Telescope. We are happy to take questions or feedback on this list or at the community meeting next week. John Gilmore, W0GNU Board member and Secretary, ARDC

4 years, 7 months

Re: [44net] Education about networking (Was Re: Inviting you to ARDC Grantmaking Survey + Community Jitsi Call)

by Rob Janssen

>>>/AMPRNet / HamNet routing is quite complicated for a non-IT guy... / >>/The advantage of using BGP even in this trivial case is... / >I don't think the most important question is about selling BGP or any >particular technology (I'm well versed in internetwork engineering and >worked in that field professionally for many years; I'm in academia >now). >I'm writing this because education was a specific question in the >survey. >The reason that we have amateur radio is to enable experimentation with >using the radio spectrum in a way that is otherwise not permitted or >practical. With the Internet, there are certain things that are only >possible to experiment with if you have your own addresses and other >network numbers. AMPRNet is (perhaps that's too strong, and we could >say, "can be") a way of enabling a kind of experimentation on the >Internet similar to what we do with the radio spectrum. It is not clear to me what you are getting at here! These are different layers of the cake. Your radio experimentation will result in some way to transport bits from A to B, but not in a network. To build a network you need another layer, and a way to define what you need to send where to get your message to the destination. That is what BGP is handling. By using BGP instead of static routing, we can connect many radio links and other links together and make a network out of it without getting buried in manual routing chores. Please make sure you understand that the use of BGP I am mentioning here has nothing to do with the use of BGP on internet to route all the internet networks. It is the same protocol, but they are different use cases. Don't get confused when people say they have their AMPRnet subnet BGP routed to them on internet, and other people propose to use BGP internal to the AMPRnet network to route things the correct way, these are two different things. Rob

4 years, 7 months

Re: [44net] Inviting you to ARDC Grantmaking Survey + Community Jitsi Call

by Rob Janssen

> - AMPRNet / HamNet routing is quite complicated for a non-IT guy. BGP requires huge equipment and skills. IPIP requires hacking protocol redirect on Internet boxes. Those are not easy things for people operating a voice repeater or hotspot. They just build a Pi image, plug the machine, and it works. Why should they bother with complex addressing ? We have quite some repeaters that are connected via AMPRnet. We normally use MikroTik routers. I do not consider these "huge equipment" and they are not difficult to configure with BGP. I have some example configs for setting up an endpoint with L2TP/IPsec tunnel to our gateway router and using BGP to advertise their own subnet. This is much easier to get going than IPIP, for example there is no need to touch the existing internet router (open ports/protocols not required). This even makes it suitable for installation on buildings where the owner may make available some guest internet access but would not want you to tweak their network to pass IPIP. The advantage of using BGP even in this trivial case is that the network can now be extended when the opportunity arises without having another hurdle of complexity. A WiFi link to another station can be added, e.g. in some cases people have an internet connection at an amateur nearby the repeater, and then a WiFi link to the repeater itself. I would be all for rolling out such a system worldwide to replace the IPIP mesh. Routers (e.g. MikroTik CHR that can run as a VPS) in datacenters all over the world interconnected with a static tunnel mesh and offering VPN service for local amateurs to connect, and routing using BGP on private AS (this only routes AMPRnet, not full internet). In different places those routers could have the AMPRnet subnet(s) for that region announced on internet, like we do for 44.137.0.0/16 and others do for other country networks. And each of those can offer different VPN technologies so you are able to follow the trend of the day without having to do a migration in the entire network. Rob PE1CHL

4 years, 7 months

ampr.org DNS and rDNS entries

by Marc, LX1DUC

Good evening, it's been a while since I had to add/change/delete DNS entries in the ampr.org DNS zone. The email robot I've used in the past seems to have gone. Could someone please point me into the right direction how this is done nowadays? vy 73 de Marc, LX1DUC

4 years, 7 months

ARRL/TAPR Digital Communications Virtual Conference (DCC), September 11 - 12 (THIS WEEK)

by Mark Thompson

39th Annual ARRL / TAPR Digital Communications Conference (DCC) THIS WEEK - Friday, September 11th & Saturday, 12th DCC will be a virtual conference using Zoom video communications and YouTube video-sharing platforms. DCC information, Technical Papers, Presentation Schedule & Registration Available at: DCC Information DCC Technical Papers DCC Presentation Schedule DCC Registration Registered DCC attendees participating via Zoom will be able to interact with presenters and other attendees via a chat room as well as raise a virtual hand to ask questions. (you don’t need a Zoom account to register). Non-registered DCC attendees can watch the live stream for free on YouTube, however non-registered DCC attendees will not be able to ask questions or chat. No registration is required for YouTube access. The YouTube URL will be announced and posted on this webpage preceding the DCC. DCC registration is free for TAPR members and $30 for non-members. Members receive a 100% discount at checkout. Non-members who would like to join TAPR and receive the free DCC pass can simply add TAPR membership and DCC registration to their shopping carts. After checkout, they will receive the free DCC pass when their membership is processed.

4 years, 8 months

Re: [44net] DDWRT Gateway Instructions

by lleachii＠aol.com

Mike, DD-WRT is not known to provide a method to compile/install the necessary software (i.e. a RIP44 routing daemon). Aside from this, I cannot recall if a tunnel can be established. Nonetheless, if you were to succeed standing up a tunnel, you'd need the routing daemon to properly configure your reply traffic. This routing daemon concern may be overcome by employing a Munge Script (hopefully DD-WRT has some tools like: `curl`, `ftp`, `grep`, `fgrep`, `sed`, `sort` and `diff` installed in the firmware). https://wiki.ampr.org/wiki/Munge_script You can start testing using commands from the startampr, OpenWrt, Ubuntu and/or Linux setup guides on the Wiki. Feel free to ask any questions (when you can stand up a tunnel). I've never used the Munge Script method, I'm sure others have (I should note that there's a script posted that can parse the encap.txt file - it's located on the Firewall page). The `ip tunnel` commands in `startampr` should be of help to test establishing the tunnel. https://wiki.ampr.org/wiki/Startampr#Script --- - Prior to using OpenWrt, I personally forwarded IPENCAP (IP Protocol No. 4) to a gateway running Ubuntu Server. - https://wiki.ampr.org/wiki/Firewalls#DD-WRT - Also see "Static IPENCAP Filtering of AMPR Nodes" here: https://wiki.ampr.org/wiki/Firewalls#iptables 73, - Lynwood KB3VWG

4 years, 8 months

DDWRT Gateway Instructions

by Mike Swiatkowski

Does anyone know how to set up an AMPRnet gateway on a router with DDWRT? I don't want to use OPENWRT based on previous experience. Thanks, Mike, AA9VI

4 years, 8 months

OpenWrt MSS Clamping - 19.07.4

by lleachii＠aol.com

All, First, welcome to the new Director and thanks for the work Chris! I wanted to inform those with OpenWrt-based nodes that version 19.07.4 should fix an MSS clamping bug that was reported to the developers. Some of you that setup OpenWrt routers have noted to me that MSS seemed problematic in one direction. I've worked around this with other OpenWrt operators by placing MSS clamping on the LAN as well as the tunnel-facing sides of the OpenWrt config. Hopefully 19.07.4 fixes the need for this. https://openwrt.org/releases/19.07/notes-19.07.4#major_bug_fixes 73, - Lynwood KB3VWG

4 years, 8 months

Portal maintenance

by G1FEF

The Portal, Wiki & website will be offline for some much needed maintenance for the next hour. Regards, Chris - G1FEF

4 years, 8 months

ax25ipd setup with socat

by Marius Petrescu

Since I get questions about how to use the current kernels for axip or axudp tunnel setups, here is my solution for this, using socat: Here is an example for an axip tunnel. First, create a transparent pty pair, lets say axip an kip located in /var/ax25 (names and locations can be chosen freely): /usr/bin/socat pty,link=/var/ax25/axip,raw,echo=0 pty,link=/var/ax25/kip,raw,echo=0 & Next, attach the kernel side to one end and create a ax25 port let say 'aprs' with address 44.128.1.1 and netmask /32: /usr/bin/kissattach -l /var/ax25/kip aprs 44.128.1.1 ifconfig ax0 netmask 255.255.255.255 (ax0 is the first port created by kissattach) Also, configure port 'aprs' in the ax25 daemon and start it... /usr/sbin/ax25d The other end needs to be configured in the ax25ipd daemon config file to use the other end provided by socat: mode tnc (...) device /var/ax25/axip (...) route n0call 44.128.2.3. b (...) I think this will help, Marius, YO2LOJ

4 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net