Tag Archives: Networking

Ohio Section Journal – The Technical Coordinator – February 2021 edition

One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Tom – WB8LCD and articles are submitted by cabinet members.

Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.

You can receive the Journal and other Ohio Section news by joining the mailing list Tom has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.

Now without further ado…


Read the full edition at:

THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net

DSCF5081 K8JTKHey gang,

I don’t know about anyone else, since most of us have been told to cower-in-place, my productivity has gone through the roof! Must be that 10-foot commute between the work desk and home desk, might get the sun in my eyes on my way over. Finally tacking items on the perpetual “when I have loads of free time” list.

First cleaned out my data hard drive that had become a general dumping ground for downloads, pictures, data files, abandoned projects, and all other forms of miscellaneous files. Kept telling myself ‘I’ll organize this later.’ I figure accumulation started around the time I graduated with my undergrad (2008) and really got involved with ham radio. Go figure. Downloads had grown to 2,900 files at 16 GB and the general dumping ground was around 73,000 files at 314 GB. Much of that got deleted but enough was kept for reference or sentimental reasons.

Synology NAS

After sorting, mutilating, and “organizing,” this led into another task to better utilize my NAS, or Network Attached Storage, functionality more than I currently was. NAS devices are a way to attach storage, like hard drives or SSDs, to the network for sharing data across devices on a local network or, in special cases, users on the Internet. NAS devices can be anything from a Raspberry Pi with USB hard drives attached, an old computer filled with spare hard drives running FreeNAS, to specifically designed devices from companies such as Synology, QNAP, or Asus. Many think “storage” when they think NAS because storage: it’s in the name. Consumer NAS devices offer packages that can be installed to add additional functionality commonly available through always-on devices. Functionality options such as a mail server, web server, git server, database server, docker virtualization, replication (mirroring, backup with another provider), network level authentication, VPN, IP camera DVR, chat, and document collaboration. I’m a loooong time Western Digital user. Their Red line of NAS drives are my choice, though they tried to pull some crap of quietly introducing sub-par drives (don’t use WD Red drives with “EFAX” in the model). Seagate is stepping up their game too with the IronWolf line, which is gaining popularity.

My strategy is to move files I’m not actively using on a regular basis to the NAS. These types of files would be: digital pictures, Office documents, document scans, emails, news articles, previous taxes, internet downloads, audio/video clips, newsletters, ham projects, school work and projects, old programs that aren’t updated but are still useful. Unbeknownst to me when I started, this didn’t leave a whole lot left over on my desktop data drive. Maybe in the future, I’ll move all data to the NAS.

For the remaining data left on my data drive, I still wanted to maintain a backup strategy in case something happened to those files. Anything from my own stupidity (accidental deletion, encrypted by a malware strain) to hardware failure. Previously, I used a cloud provider for remote backup but they decided to exit the consumer market. With their change in business strategy, I was using my own scripts to keep things synced from the desktop to the NAS, whenever I remembered to run them. Not great because if I deleted something with a bunch of recent changes and the last backup I had was a week or two ago, that sucks. This syncing strategy also didn’t have file versioning.

When a file is changed, the backup system preserves a new copy of the file but keeps previous versions in case you wanted to go back in time to an earlier version. Real-world example: a computer becomes infected with a malware strain that encrypts all pictures and documents. A backup solution will still make a backup copy of the newly encrypted file, because it doesn’t know its user or user on the network did something stupid. Saving previous versions means you can recover the unencrypted version without paying Mr. Bad Guy’s ransom.

Syncthing web interface (wikipedia.org)

I tried solutions like rsnapshot but had serious issues getting systemd timers (supposed to replace cron, yeah, we’ll see) to work with persistence and waiting until the NAS was mounted before taking a snapshot. That was abandoned after a few months. I heard about Syncthing on a podcast. It met my requirements and more! It’s quite an amazing piece of free and open-source technology. I could run an instance on my NAS (or any computer), attach devices, those devices send file changes in real time, and the software takes care of preserving previous versions. “More” came in the form of Syncthing being available on every platform I use. Supported are: source code for manual compiling, Linux (many distributions and processor architectures), Windows, macOS, *BSD, and Solaris. There is an Android client allowing me to backup my phone to my NAS. Syncthing is exactly what I needed since I have some Windows machines (like the shack PC).

A couple warnings about Syncthing. Getting started will seem overwhelming with options and what they mean. Look at good tutorials and in the forums where there are lot of users willing to help. Even more important: Syncthing IS NOT a backup tool. Wait, you said you are using it as a backup tool! I’m syncing file changes to my NAS. Backup comes in the form of making images of the NAS drive and storing those off-site. Also acceptable is using a cloud backup service to backup the NAS off-site. Both are acceptable uses of Syncthing as a “backup” solution.

Another thing on the “to do when I have tons of free time” was digitize VHS tapes. In December & beginning of January, I was on a mission to digitize my high school and college video tapes as well as family home videos. Close to 100 tapes in total. Those that are not familiar with my broadcast television past, I was involved with WHBS-TV in high school, a local cable access station. Schools from across the county came to visit us because we were doing 7 camera shoots with replay for all football games, 5 camera shoots for basketball, and competing in college level categories for regional Emmy awards. Worked at WBGU-TV in college. Did a ton of cool stuff including weekly productions for Fox Sports Ohio, a program that was distributed internationally, and lots of remote shoots in different parts of the state, to name a few. This was all before over-the-air digital was a thing. I recorded a lot of stuff on VHS tapes over those years and, of course, wanted to preserve them.

Most say “put it on DVD.” Like it or not, we’re being pushed to a streaming society so companies can control when and how you view content. Not only is physical media dead, but you now have to take care of, and store, a bunch of DVDs. There are services allowing you to roll-your-own streaming service, where you to make your own content library. There would be a server on your network containing your music, videos, TV shows, home movies, etc. making it accessible to smart TVs, streaming devices like Roku or Fire Stick, smart phones, tablets, or any modern web browser.

Plex media center (plex.tx)

I used a Hauppauge USB capture device to digitize VHS tapes played from a VCR. VideoReDo to fix errors in the data stream (some players have issues playing video streams with data errors) and cut recordings into smaller files. HandBrake to encode the video and Plex Media Server to make the video available to devices. Plex server runs on, you guessed it, the NAS! I’m glossing over how to use Plex, organize files, and produce files optimal for streaming as there are many support articles and forum posts covering these topics on the Plex or any other similar service’s site.

Reading up on recommended practices to digitize VHS tapes, VCRs with newer Time-Based Correctors (TBC) were recommended. Looking online, those were $400 or more. Since it’s likely these videos will be watched a handful of times, I decided to forgo more expensive VCR options. TBC can correct timing issues, making 1 second = 1 second, not longer due to tape stretching. It aims to correct visual image jitter and “wiggling.” I did see those artifacts and re-recorded if the video was bad enough. The Hauppauge device captures video at about 13 mbps (2 hr is about 13 GB). “Lossless” 25 mpbs capture devices were recommended. Do you remember the quality of a VHS tape? Lossless is not going to lose much VHS quality! All tapes digitized weighed in at about 1 TB of storage. Sounds like a lot. Though, 4 TB drives are under $140.

Watching college videos from 2004 as they were being digitized, I came across one of the shows and said ‘that guy looks familiar.’ It was two shows on school funding in the state of Ohio. Our previous section SGL Nick Pittner – K8NAP was one of the guests. I happen to be working camera in the WBGU studio for that show and Nick was in Columbus coming in via satellite. Emailed Nick some screen grabs. He remembered the show, hosts, other guest, and said they are still fighting the same fight after the better part of two decades later. Sometimes you never know who you’re working with!

On a commute a little longer than 10 feet, I’m planning to be in person at the Portage County Amateur Radio Service (PCARS) meeting coming up March 8th. Meeting topic will be VoIP modes (Voice over IP), both analog and digital, and the DVMIS. Hope to see everyone. There should be a Zoom link posted on their site if you would like to attend virtually.

Mike Baxter, KA0XTT, played by Tim Allen (arrl.org)

Speaking of the DVMIS, the Last Man Standing Amateur Radio Club – KA6LMS is sponsoring a special event starting at 00:00 UTC on March 24, 2021 and end at 23:59 UTC on March 30, 2021. This coincides with the last day of shooting for the show which is concluding its long, successful run. This event is going to be a multi-band, multi-mode, special event celebrating the show for its portrayal of amateur radio. AmateurLogic.TV is planning a net for March 27 from about 7 pm – 1 am eastern and the net will be carried on my system! I’m honored to be part of this event as Last Man Standing is one of my favorite shows. Mark your calendars and check the KA6LMS QRZ page for details!

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – December 2020 edition

One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Scott – N8SY and articles are submitted by cabinet members.

Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.

You can receive the Journal and other Ohio Section news by joining the mailing list Scott has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.

Now without further ado…


Read the full edition at:

THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net

DSCF5081 K8JTKHey gang,

One of the things I’ve been working on during my time at home is the Digital VoIP Multimode Interlink System (DVMIS), also called the K8JTK Hub. About a year-and-a-half ago, I came up with this bright idea to setup a system that would interlink many different ham radio VoIP (Voice over IP) modes for interoperability and experimentation. Through trials and tribulations, it’s experiencing some success, caught the interest of some nets, and a podcast.

Many digital modes sit on their own island and are restricted from crossing over to the analog world or to other digital networks. Some may say this is for quality-of-service but does nothing for interoperability or the ability to link and communicate across different systems. Original D-STAR DPLUS reflectors banned analog connections. My Hub supports ham radio experimentation by allowing hams to discover ways of utilizing a system that can link different modes. Utilization of ham radio spectrum is a priority through the use of hot spots and repeaters. Connections without RF are not a priority. Hamshack Hotline was provisioned because of use in Emergency Operation Centers. Many times, I’ve been asked about stations that don’t have access to RF hotspots or radios. They still have options including the Echolink app on Android and iOS devices, Hamshack Hotline phone which can be purchased for $30 (I’ve heard deals as low as $5 for a compatible phone), or the DudeStar app. The servers are hosted in a Chicago data center to provide resiliency against hardware, power, weather, and Internet outages, but still be fairly inexpensive.

All this is possible through integration of open-sourced packages including: AllStarLink which is a world wide network of Amateur Radio repeaters, remote base stations and hot spots accessible to each other via the Internet and/or private IP networks. Built on an open-sourced PBX system called Asterisk, Jim Dixon – WB6NIL (SK) built the apt_rpt module emulating functionality of a repeater controller. Jonathan – G4KLX authored programs that support D-Star, DMR, System Fusion, P25, and NXDN which are utilized in MMDVM devices like most hotspots. DVSwitch is a suite of applications for provisioning and operating Amateur Radio digital voice networks maintained by Steve – N4IRS and Mike – N4IRR. The DVSwitch Mobile app was designed to operate analog and digital modes utilizing an Android phone in conjunction with server applications running on a Linux server or Raspberry Pi. The ASL to DMR documentation (groups.io account required) got me started experimenting with these applications and ultimately lead to the build out of the system. XLXD is a multiprotocol reflector server for D-STAR by Jean-Luc – LX3JL & Luc – LX1IQ. Skip – WB6YMH & others maintain thebridge, an Echolink compatible conference bridge.

Originally, hosted on 2 servers, after troubleshooting some issues, it was more reliable to host everything across 3 VPSes (Virtual Private Servers) running Debian Linux. Parts of the system can go down and individual parts will continue to function. Aside from the VPSes, a Raspberry Pi with a Northwest Digital Radio DV3000 provides D-STAR audio transcoding to the system. Wires-X is available through the use of additional remote hardware. Wires-X is proprietary to Yaesu radios and repeaters. Wires-X is not available through open-source implementations such as YSFReflector or MMDVM without additional devices. I’d like to get the DV3000s in a reliable data center but doing so is prohibitively expensive. AllStar Link is the “Hub” that provides connectivity and linking control between all networks.

Putting all of this together provides a system with access to ten different networks and eight different modes! Any user on one network can communicate with users on other networks. Access is available through these nodes and connections:

  • AllStar Link: 50394
  • DMR: Brandmeister Talk Group 3172783
  • DMR: TGIF TG 31983
  • D-STAR: XLX983A (A = Analog Bridge. Pi-STAR = DCS983A, OpenSpot = XLX983A)
  • Echolink: *DVMIS* conference 600008
  • Hamshack Hotline: 94026 (*99 – TX, # – RX)
  • NXDN: TG 31983
  • P25: TG 31983
  • YSF: K8JTK-Hub 31983
  • Wires-X: K8JTK-ROOM 40680 (available upon request)

Dashboards:

Amateur Logic episode 149

Building this system has not been without problems. Luckily, I’m able to work around known issues. In order from least frustrating to most frustrating: all programs use IP addresses and ports to communicate, keeping all of that straight was a challenge initially. Using IPs allows for great flexibility utilizing network links such as private networks and VPNs. Dependency hell as a result of additions and changes to programs made a constant deployment from one day to the next an issue. XLXD changed its implementation to include YSF which then conflicted with the port used for the YSFReflector. Changing the YSFReflector port required propagation to Pi-STAR host files and OpenSpot DNS. DVSwitch has been rewritten two times since I’ve implemented it and they’ve released another round of changes. Data center provider choices resulted in issues with packet loss. Moving the servers to another provider yielded much better results. The previous provider finally acknowledged and supposedly resolved the issue a year after it was reported, and after I moved.

Use of physical hardware for D-STAR. OP25 software codec can transcode D-STAR but “you won’t be happy” to quote a post in the forums. D-STAR looooves IP addresses. DNS is great for switching IP addresses easily (like when moving data centers or spinning up different servers). However, D-STAR relies only on IP addresses. As a result, reflector IP changes take about a day to propagate to online hotspots/repeaters. Using AMBEServer with the DV3000 on a remote device resulted in very choppy audio. After some time, had the idea to move Audio Bridge to the same device as the DV3000 then use IP routing to send audio to and from AB. Worked great.

In order to compile AllStar Link from source takes a lot of time to get right and includes A LOT of dependencies. Finally, one that drove me crazy was the chan_echolink module for AllStar which provides Echolink connectivity natively to AllStar. When load testing with many connections, something was making stations sound as though they were transmitting underwater. After observing patterns, determined it was audio originating on the Hub being sent out to Echolink connections. Incoming audio from Echolink stations was OK and audio sent to all other nodes was also good. The problem seemed intermittent until I consulted groups.io and further determined chan_echolink has audio quality problems when more than three EL stations are connected simultaneously. Not ideal for a hub. Best workaround was to implement an Echolink Conference server. Then only allow chan_echolink connection to that conference server. Echolink users would then connect to the same conference server. This issue took a lot of time and a lot of hair pulling but implemented a workable solution that offers a quality system. Root cause is still unknown as an AllStar developer hadn’t chimed-in with any suggestions or possible reasons.

K8JTK Hub/DVMIS connections

The DVMIS hub hosts a couple nets. Tuesday nights at 9pm eastern, since about the first-time stay-at-home orders were put in place, is the Amateur Logic Sound Check net. The net encourages checkins to utilize as many modes as possible during the net to test equipment. If you haven’t seen the Amateur Logic podcast, it has been going for over 15 years and they release two shows monthly. The regular podcast has segments about technology and Ham Radio. “Ham College” is an educational show for those wanting to get licensed or upgrade. The guys asked me to put together a segment for the show. My segment can be found in episode 149. A huge thanks goes out to the ALTV crew and everyone checking into the net which helped me identify and resolve system issues. They’ve also been great in keeping up with all the changes over the last 9 months. At the end of December, I’ve been testing with the West Chester Amateur Radio Association – WC8VOA to add digital modes to their net on Monday evenings at 8pm.

Around the time my segment was airing on ALTV, Brandmeister did not approve of the linking method and linking to other networks. Brandmeister uses the MCC standard and they manage talkgroup IDs consisting of 3, 4, or 5 digits. 6- or 7-digit IDs are repeater IDs and user IDs respectively, and can be used however the assigned owner would like. The BM TG in the ALTV episode is now 3172783 and is correct in the listing above.

The Hub is open for all to use in testing equipment, software, or linking up with friends. I keep status updates listed on the page linked at the beginning of this article. For this and any linked system, please remember a couple practices. When keying your radio, pause a second or two to allow all links to rise, otherwise the first couple words maybe lost. Pause a minimum 3-5 seconds between transmissions to give time for links to reset and other stations to break in. Do not “tailgate.” Enjoy and join the nets to get a feel for the Interlink System’s capabilities.

Slow Scan TV has become big over the last couple years due to ARISS (Amateur Radio on the International Space Station) events. One of the longer events will have begun before OSJ publication: starting December 24 at 16:40 UTC and continue through December 31 ending at 18:15 UTC. Dates are subject to change due to ISS operational adjustments. Images will be downlinked at 145.800 MHz +/- 3 KHz for Doppler shift and the expected SSTV mode of operation is PD 120. Radio enthusiasts participating in the event can post images they receive at the ARISS SSTV Gallery at https://www.spaceflightsoftware.com/ARISS_SSTV/. After your image is posted at the gallery, you can acquire a special award by linking to https://ariss.pzk.org.pl/sstv/ and follow directions for submitting a digital copy of your received image. Even an HT can receive images from the space station. If you would like to receive images using MMSSTV on Windows, head over to my tutorial.

Congratulations to Scott Yonally – N8SY who won his election as Great Lakes Division Vice Director! Since he cannot hold more than one elected position at a time, he will be stepping down from his current Section Manager position when he assumes the Vice Director position on Jan 1. I wish him nothing but the best in his new role as he has done a lot for the Ohio Section during his tenure. We will then welcome Tom Sly – WB8LCD who will be appointed the new Section Manager for Ohio!

Thanks for reading. Happy holidays, Merry Christmas, and Happy New Year!
73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – August 2019 edition

One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Scott – N8SY and articles are submitted by cabinet members.

Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.

You can receive the Journal and other Ohio Section news by joining the mailing list Scott has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.

Now without further ado…


Read the full edition at:

THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net

DSCF5081 K8JTKHey gang,

July 18, 2019. The date ham radio and the Internet changed forever. Most hams didn’t know it or even know that we had a block of 16.7+ million Internet IP addresses for our exclusive use. Keyword: had.

If you’re not familiar with networking and CIDR notation, CIDR (pronounced similar to the drink, cider) is a method used to note networks and ranges of IP addresses. A computer network is a connection of devices or nodes that can communicate and share resources with each other. For example: Your home PC may have the IP address: 192.168.1.100, subnet mask: 255.255.255.0. In CIDR notation, this is written as 192.168.1.100/24. Similarly, the network 192.168.1.0/24 means the same subnet mask and includes the IP above. Usable IP addresses are 192.168.1.1-192.168.1.254. “.0” is unusable as it is the network address, “.255” is not either because that is the broadcast address between all devices on that network. Since the PC has 192.168.1.100, it can communicate with devices in the 192.168.1.0/24 range. Know that smaller CIDR notations mean bigger networks (more IPs). Larger CIDR notations mean smaller networks. Networks can be broken down into smaller networks or combined to form larger ones – maybe not quickly or easily, it can be done.

In the early days of the Internet, it was believed if a node were to communicate on the Internet it had to have a public Internet address. With this thinking, very large /8 networks (16,777,216 IPs each) were assigned to companies and institutions such as: HP, Xerox, IBM, Ford, Boeing, MIT, Halliburton, Stanford, MSU, Bell Labs, DuPont, the USPS, and the DoD. They were cheap and easy to obtain! Having large networks is no longer necessary due to advances in Network Access Translations or NATs which remap one network space into another network space.

Dr. Jon Postel (Wikipedia)

Back 40 years ago when the Internet was new and the original creators thought 4.2 trillion IP address were enough for the entire world, Hank Magnuski, KA6M and others saw the possibilities of the Internet. They obtained an Internet allocation from Dr. Jon Postel who, at that time, was responsible for overseeing allocations on the Internet. Today, allocations are the responsibility of IANA. Much like property, IP address spaces can be bought, sold, squatted, and even taken over in some cases. The non-profit organization Internet Assigned Numbers Authority (IANA) oversees Internet IP address allocations.

The allocation that was obtained is called AMPRNet (AMateur Packet Radio Network) or Network 44. In 1981, it was provided exclusively for Amateur radio operators to use packet radio, TCP/IP, and digital communications between computer networks managed by Amateur radio operators. The network consisted of addresses 44.0.0.0 through 44.255.255.255, in Internet notation 44/8 or 44.0.0.0/8, consisting of 16.7+ million IPv4 addresses.

TCP/IP was, at one time, an emerging standard and in minority use because of the protocol complexity. In typical fashion, packet node owners were outraged with this IP protocol and few systems on HF operated with this protocol because of the amount of overhead. TCP/IP then goes on to become the foundation of the Internet and in use by every device on the Internet today. Think about that anytime someone complains they don’t want to support or do something because they don’t like it.

In 1986, an agreement mandated about 8 million addresses of 44/8 be assigned for use within the United States under FCC regulations (44.0/9) and the other 8 million (44.128/9) for deployments in the rest of the world.

San Diego Supercomputer Center, host of AMPRNet internet gateway, and CAIDA/UCSD network telescope (Wikipedia)

Since 1990, most packets destined for 44/8 were handled by a router at the University of California, San Diego. This forwarding router was originally named mirrorshades.ucsd.edu, later gw.ampr.org or “AmprGW.” This Internet “border” router (gateway) is used to route packets to and from the ordinary Internet to computers or nodes on AMPRNet. When a request hits the Internet for network 44.0.0.0/8, it is routed to UCSD. Different protocols are used to deliver the packet from the Microshades router to the destination IP address in any part of the world. Internet routers like these would be similar to an Internet Service Provider (ISP) router often handling multiple networks at once and at multiple gigabits/second transfer rate.

In 2001, UCSD used 44/8 for research as an Internet Telescope which allows observation of large-scale events taking place on the Internet using Internet Background Noise and backscatter. Backscatter is used to determine Denial of Service (DoS) attackers and victims. They were able to monitor the Code Red computer worm in 2001. All data was captured and used to generate historical trends and data. For example, when attackers on the internet start probing systems with a known set of criteria, they can go back and look when those probes first started appearing on the Internet. In 2003, 0.75 terabytes per month was recorded. In 2016, 37 terabytes per month is seen.

Since hams have had AMPRnet, many have taken advantage of it for single use applications or using small blocks on a long-term lease at zero cost. It has been used for communications ranging from simple TCP/IP connectivity, digital voice, telemetry, and repeater linking. However, not more than half of the network was ever used. Peak usage happened between 1985-1995. According to the group now overseeing 44/8, Amateur Radio Digital Communications (ARDC), a U.S. 501(c)(3) organization, less than one-third of the network is in use today and some address blocks have never been used.

It wasn’t too long ago (5-10 years) that I learned about AMPRnet when I became involved in supporting an APRS Igate. I knew APRS was using the space in some aspect, the EchoLink mobile app uses the 44 network, Michigan is actively using their allocation, and Europe was using it for their HamNET Mesh. I assumed the network probably wasn’t utilized but hopeful it had enough use to keep it in the Amateur Radio community. I would have like to have liked to see ham radio Internet technologies utilize network 44 like mesh, hot spots, and newer digital voice modes (D-STAR, DMR, and Fusion). It’s a cost and complexity issue. While there is no way to put a device on the Internet with a random IP address and expect the Internet to know how to reach that device. Routes and paths need to be established as was done with the UCSD router or other routing equipment which can be very expensive to setup and

HamNET Mesh (Wikipedia)

maintain. Too costly and too complex to support, other easier methods were utilized.

American Registry for Internet Numbers (ARIN), who is responsible for distribution of IP addresses on the Internet, declared on September 24, 2015 their available IPv4 pool was exhausted. The Internet was quickly running out of IP addresses! This lead the push to IPv6, which is exponentially larger. IPv4 has 4.2 trillion IP address (minus some for special uses). IPv6 has 340 undecillion, or 340 billion billion billion billion, addresses. You could assign multiple entire IPv4 sized networks per household under IPv6 and still have some left over! Exhaustion caused IPv4 allocations to become much more valuable.

Companies and institutions who still owned all or large parts of their originally assigned networks were now sitting on a gold mine. Supply and demand: a resource (IPv4 addresses) is scarce but many people want IP addresses. The price will rise, at least until IPv6 is closer to universal adoption.

This led to the ARDC decision to sell off about 4 million addresses from 44/8 on the marketplace. Total network value of 44/8 was estimated to be $100 million. From their press release:

"...in mid-2019, a block of approximately four million consecutive AMPRNet addresses denoted as 44.192.0.0/10 was withdrawn from our reserve for Amateur use, and sold to the highest qualified bidder at the then current fair market value. This leaves some twelve million addresses devoted exclusively to Amateur Radio uses, which is far greater than the number of addresses which are currently or have ever been in use. We believe this is far more than the number of addresses that will ever be needed by hams before IPv6 takes over the Internet. We also believe that was the prudent and proper time for this sale to take place, for a number of good reasons, among which are a recent levelling off in address prices and a lessening demand as only a few large buyers are left in the market for such a large block of addresses."

We now know the highest bidder was Amazon at a price of $50 million completed July 18, 2019. There is no intention by the ARDC to sell any more of the network. Post sale, AMPRNet consists of addresses 44.0.0.0 through 44.191.255.255 (44.0.0.0/9 and 44.128.0.0/10). Portion sold was the uppermost 25% of the address space, 44.192.0.0 through 44.255.255.255 or 44.192.0.0/10.

Some of the guys at work heard about this before I did because it was trending on Reddit. Initially, like most of the comments, I too was outraged. Though, figured it was coming sooner or later. An IPv4 shortage, a valuable /8 not being utilized. Wasn’t hard to put two and two together. I’m never one to say never. ‘We’re never going to use something.’ How do we know? Maybe hams develop the next Internet with that address space. Putting the politicking and whining aside, taking them at their word (continuing from the press release):

"It is our intention to grant funds across all reaches of the educational, research, and development spectrum, with awards being made to support qualified organizations whose programs could well serve to advance the art of digital communication, with special emphasis on that which would benefit Amateur Radio.

Additionally, another way we will be able to help our community is to contract with research firms and consultants to carry out related research and development to produce procedures, techniques, methods, designs, and intellectual property that would then be made freely available for the benefit of all."

While I think this is a monumental asset having this money available to promote the hobby and research, I think it puts us in a dangerous spot. To me, the similarities between this example of limited resources on the Internet and the limited resources of our radio spectrum are uncanny: ‘it’s there and not being utilized,’ ‘we’ll never use it,’ ‘resource sold for public benefit,’ ‘take the money and run,’ ‘sellouts!’ This shows that everything is up for grabs and we cannot take it for granted. Just ask France. WRC-23 is considering a proposal to make Aeronautical Mobile as the primary service in the 2-meter ham band. This is how it starts.

Now more than ever, get on our resources and use them. We have more hams now than ever (in the U.S. anyway). Get on our bands. Get on our IP space. Improve the network. Grab some IPv6 space for Amateur Radio. Get involved with organizations and offer support. Yeah, everyone’s busy. If everyone’s too busy to support these organizations, we may lose all of this. Use it or lose it, so “See ya 44/8.”

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – March 2019 edition

One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Scott – N8SY and articles are submitted by cabinet members.

Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.

You can receive the Journal and other Ohio Section news by joining the mailing list Scott has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.

Now without further ado…


Read the full edition at:

THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net

DSCF5081 K8JTKHey gang,

Do you have your Network Radio? I do, well, maybe. Not the way most people define Network Radios. In the last number of years, outside Voice over IP (VoIP) services have found their way into ham radio. Services cAUZRdnMNrU?start=2051utilize mobile data connections like 3G, 4G, and WiFi to connect users over the Internet. The app turns a cell phone or tablet into a HT-like device, complete with PTT button. “Network Radios” has been used to define these types of transceiver and channels available on those transceivers.

Probably 4-5 years ago, and still used today, a number of hams were all abuzz about this service called Zello. Another service called IRN (International Radio Network) is built on TeamSpeak. TeamSpeak is most frequently used as an audio chat service for players in multiplayer video games. Both of these services were probably adopted by ham-radio operators because of the similarities. Use a speaker, microphone, and can carry on round-table style chats. One person talks and the rest receive. These are called “channels” – similar in ham lingo to a reflector, conference, or talk group.

The term “Network Radios” is making the rounds because devices are being sold that integrate with VoIP services and are made to look like an HT or mobile radio. Most run the Android operating system meaning they come with the Google Play store. Having the Play store means any app can be installed, such as other VoIP apps like the EchoLink app or Repeater Book repeater directory.

RFinder was the first to design and sell Network Radios. They took a cellphone and attached a dual-band VHF/UHF transmitter capable of analog or DMR. Make phone calls or phone-calls. A similar tablet version is also available. Their devices are integrated with and promote the RFinder application (digital version of the ARRL repeater directory). Running the application and using the GPS makes it easy to locate near-by repeaters. Clicking a repeater would program the radio for use with the selected repeater, including offsets and sub-audible tones. Press PTT and you’re on the air!

A store with the completely original name, Network-Radios, is selling a whole range of Network Radios including the RFinder devices. The HT Network Radios have, what looks like, an antenna but few lists the capability of transmitting in the ham bands. None of the mobile Network Radios have any kind of RF connector.

This brings up the question: is this ham radio? My definition: if a legal identification is required, it is ham radio. More-or-less, I’m looking for Internet-linked endpoints to be connected to some kind of RF transmitting device in the ham bands that follows Part 97. I would like to have all linked end points transmitting in the ham bands, but I’ll take what I can get. My reasoning: our bands continue to be under attack by commercial entities that would pay big money for our frequencies and EVERYONE always complains our repeaters and frequencies are underutilized. Actually using our bands shows whoever is out there listening (FCC, commercial interests, people scanning the bands, potential hams, …) that ham frequencies are being utilized and we’re doing stuff with our bands. Call me crazy!

I’m not opposed to hams using these Network Radio services to find a better tool. Some Network Radio channels are even linked to repeater systems. That’s OK if private channels are properly controlled, seems like a lot of extra management. However, the overarching use of these services is mobile-device to mobile-device using non-ham bands. That is not at all ham radio. One argument is that some people need a place to let loose a little more than would be allowed on a regular repeater. Whatever.

I heard, from hams, in recent Emcomm situations how great it was that Zello was being used by the public to phone in needed rescues. Other channels were created for family members looking for relatives to make sure they were OK. Great use of technology. If average people can be mobilized at a moment’s notice with boats and rescue gear through a phone app, are hams still relevant? Anyone else see the irony?

The argument is always made: “the cell network can, and will, go down.” The exact opposite argument is being made promoting Network Radios as seen at the beginning of this blog post (some language NSFW, that is “not safe for work”) on the Network-Radios site: “I get 99,99999% of cell signal no matter where I am. I wonder if you can reach a VHF or UHF repeater for 10% of the time of your travelling with a typical 4 Watt handheld with its rubber duck antenna. And if GSM is not available, I could use a global wifi hotspot.” We’re doomed. Too soon?

New Podcast

The ARRL is sponsoring a new podcast that launched March 7. “So Now What?” is geared toward those who have obtained their license and need mentoring on the next steps to get the most out of the hobby. “Topics to be discussed in the first several episodes include getting started, operating modes available to Technician licensees, VEC and licensing issues, sunspots and propagation, mobile operating, contesting, Amateur Radio in pop culture, and perceptions of Technician license holders.” I’m sure there will be ideas for new and old hams alike. Subscribe to this new podcast and get the most out of ham radio!

Networking Basics

I made a career move over a year ago from programming into a networking position and quite enjoy it. Pascal – VA2PV, has a quality Youtube channel where he frequently does product reviews, how-to videos, and shares his experiences with things like PL-259 installation and re-cabling his shack. Video and audio quality are excellent with many videos available in 4K (great opportunity to experience a 4K stream). He released a video on the basics of IP networking. It won’t go in depth to the level of things I do at work, but if you ever wanted to know how devices on your home network can communicate with devices on the Internet, what is DHCP & DNS, then his video is required viewing.

FreeDV QSO Party

A group in Australia has announced the first ever FreeDV QSO party starting on April 27th 0300z to April 28th 0300z 2019. FreeDV is an open source digital voice mode, commonly referred to as Codec 2. I’ve played around with this mode before and was impressed by the resulting audio quality in such a narrow bandwidth. I hope this will create some FreeDV activity on the bands. It does require two sound cards (or sound devices) to operate. If you have an internal soundcard and a SignaLink, you’re set. The internal soundcard records and plays voice audio while the SignaLink (or other) transmits and receives digital modulation to and from your radio. Look for you on the bands using FreeDV!

Thanks for reading and 73… de Jeff – K8JTK

Ohio Section Journal – The Technical Coordinator – June 2018 edition

One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Scott – N8SY and articles are submitted by cabinet members.

Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.

You can receive the Journal and other Ohio Section news by joining the mailing list Scott has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!

If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.

Now without further ado…


Read the full edition at: http://arrl-ohio.org/news/2018/OSJ-Jun-18.pdf

THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net

DSCF5081 K8JTKHey gang,

The Wood County Amateur Radio Club (which I’m a member) has a Fusion digital net on Thursday nights. Longtime club member Phil – W8PSK, posed the question: can I operate a Wires-X node mobile from my RV?

A little background about Wires-X setups. Wires-X is part of Yaesu’s System Fusion and is a closed Internet linking system. Only Yaesu hardware is allowed. Other digital devices like the OpenSpot, DVMega, and Pi-Star are not permitted. The obvious answer, if it were a viable choice, would be to use a digital hotspot but Yaesu doesn’t allow them. Wires-X hardware requirements include: a Yaesu FTM-100D or FTM-400XD radio or Fusion repeater, Yaesu HRI-200 interface between the radio and PC, a Windows 7 or 10 PC (yes, it must be Windows machine), and an Internet connection with a global IP address. A common example of a global IP address is one provided to you by your DSL, Cable, or Fiber provider. This IP is accessible from anywhere on the Internet and (generally) unrestricted. Lastly, another radio is required to use the Wires-X node locally.

Having setup my own Wires-X node in addition to LEARA’s repeater node, my first assumption was Phil would be able to connect out from his node in the RV to any other Wires-X node, but no other node could connect to him. This theory was based on the need to open or “port forward” 7 ports from the Internet to the PC running the Wires-X software. Port forwarding is a computer networking method used to allow data to bypass a firewall which would normally block that communication. Those that run websites from their network or have access to IP cameras while away from home will have these port forwards configured in their router.

Phil planned on using his smartphone as the Internet connection to the PC. Modern Smartphones have the ability to use the cellular network to serve an Internet connection to other devices like a laptop or Raspberry Pi via Wi-Fi connection. This is labeled something like “Mobile Hotspot” or “Personal Hotspot” in the phone. Standard disclaimer: check with your provider first in case there is an extra charge for this service or bandwidth cap. Bandwidth is standard for a Voice over Internet system at about 60kpbs/connection or about 30 MB/hour/connection with constant TX/RX. Port forwarding is never allowed on consumer cell plans. The unknown was can the Wires-X software connect without the port forwarding outlined in the configuration.

I tested my theory to see if the Wires-X software functioned by modifying a known working Wires-X configuration. I closed (temporarily disabled) the forwarded ports on my network. This meant communication over those ports would now be blocked, similar to that of a cellular connection. Then restarted the Wires-X software and hoped for the best. Was my theory correct? Drumroll please… the answer was: no. Wah waaaah. Not having the required ports forwarded to the PC did not allow the software to receive data from the Wires-X network. That result almost killed any hope of Phil using Wires-X mobile in his RV.

Phil was determined and we looked further into different solutions. VPNs were an option because they can often bypass network restrictions. However, a small number of VPN providers allowed forwarding ports as part of their service. Reviews weren’t positive and VPNs tend to easily fail with unstable data connections as one might have while mobile. Not something to be messing around with while driving. It introduced another point-of-failure in this setup. Hilariously enough, there were applications that touted the ability to ‘open ports on your phone.’ These wouldn’t work because it might open ports on the phone, almost assuredly the provider was blocking any ports upstream to the phone. Verizon offers a business account which allows port forwards but there is a one-time setup cost of $500 plus the service. Yeah, no. I suggested asking in the Yahoo group. John – N9UPC, Fusion representative for Yaesu, reinforced the conclusion I came to: operating mobile wasn’t possible because wireless providers don’t provide a global IP. Though Phil posted his question in late April, oddly enough John did not give any indication to an announcement at Dayton. One solution that looked promising used AMPRNet which is block of Internet routable IP addresses for ham radio operators. It could give us the global IP address we needed. After finding out more, someone else’s data center was being used and we weren’t sure Phil would have permission to use it as well.

Sensing no way to get around the port forward restriction, an announcement came during the Fusion forum at Dayton that (we hope) will solve Phil’s problem. Yaesu is going to release an update in the coming months that will allow the FT2DR, FTM-100D, as well as the FTM-400XD to operate as a portable node. With additional cables, these radios would connect directly to a computer for Wires-X operation without the need of an HRI-200. This was created specifically for mobile setups and users who don’t have the ability to forward the necessary ports (like in a hotel). Ding, ding, ding, we have a winner!

A couple caveats: purchase of an HRI-200 is still required. To use the portable node, you still need to register on the Wires-X system which requires a serial number from an HRI-200. The portable setup will not have ‘all of the features’ of the traditional setup such as hosting a Room (round table-type node) or messaging. Purchase of two cables is required to make the necessary connections: an SCU-19 USB and CT-44 audio cable. It wasn’t clear if both are needed for the 100/400 radios. There are no plans “at this time” to integrate any other Fusion radio other than the three listed above.

It would have been nice to have a heads-up about this new option before we spent time researching a solution. I think this will solve Phil’s problem and get him mobile with Wires-X. Announcement from the Fusion form, Dayton Hamvention 2018.

Speaking of digital hotspots, my favorite has been discontinued: the openSPOT. Saw it disappeared form dealer sites just after Dayton. June 8th it was removed from the SharkRF website with an announcement that a new product was going to be introduced soon. What could it be??! If you need a digital hotspot device today, I really like the ZUMSpot with the Pi-Star software. I picked up one with a case at Dayton. More info in future articles.

The next big ham holiday, Field Day, is right around the corner. Get out and join your club or find a club to join if you’re not a member of one. It’s a great time to bring friends and get them excited about ham radio. Hams that come out get bitten by the bug to expand their station or learn a new mode. Check the Field Day Locator for operations taking place near you. Sending 10 messages over RF from your site gets you 100 points – including Winlink messages. I love to receive messages about your setup, stations operating, or social activities taking place. These can be sent via the National Traffic System (NTS) or Winlink – K8JTK at Winlink.org – to my station. Winlink post about Field Day points.

With July around the corner, two of my favorite events will be kicking-off soon. The 13 Colonies Special Event is coming up July 1 – 7, along with the RAC Canada Day Contest on July 1st only.

Thanks for reading and 73… de Jeff – K8JTK

Bridge a Remote Site Network with OpenVPN Access Server

Having access to your devices over the Internet is a requirement for any admin deploying a project. Instead of running to a remote site to administer devices (making changes, applying updates and patches), it’s easier to connect remotely and make changes. Remote access poses many issues and concerns.

Security

First and foremost is security. You always, always, ALWAYS want devices connected to the Internet behind a router with a built-in firewall (NAT router). A firewall filters traffic between two networks (your ISP and home for example) and will block attempts to connect to your internal (private) network.

Device manufacturers take security for granted. Little testing and auditing takes place because the analysis is expensive for throw-away devices. This is noted in many stories including Bug Exposes IP Cameras, Baby Monitors where simply clicking “OK” on the login dialog allowed access to the Internet connected video camera. It is trivial to find these devices on the Internet because of Shodan. Shodan is dubbed the “Internet of Things Search Engine.” If you’re not familiar, think of it as the Google for devices connected directly to the internet. These could be: web servers, printers, cameras, industrial machines, bitcoin mining… Putting devices behind a firewall minimizes the risk because anything trying to peer into the network would be blocked by the firewall.

This holds true for networks you don’t control (granted access on someone else’s network). Put your stuff behind a router/firewall so they can’t see your devices and you can’t be exploited by devices on the other network.

Port Forwarding is a popular technique to only allow traffic on a specific port to a device you specify in your firewall (router). This provides little security as it still allows a potentially vulnerable service to accept incoming connections from the Internet.

Choose a good router

Couple of tips for a good router:

  • You get what you pay for. Don’t opt for cheap.
  • Opt for ones that support third-party firmware like DD-WRT and Tomato or setup a dedicated computer running pfsense or Untangle. These have proven to be more secure than stock firmware in addition to offering a more complete feature set.
  • Stick with popular models as found on Amazon, Newegg, or other tech store. They’re more likely to be reliable, well updated models.
  • Look for ones that accept USB cellular modem dongles for installations that have no accessible network connection like a remote site.

Virtual Private Network

The preferred way to connect to a remote network is to use a VPN. A VPN connects to a private network securely over the Internet. It allows the user to exchange data, use services, and connect to devices as if they were directly connected to that network. An open-source project that implements VPN technologies security is OpenVPN. OpenVPN is an application that allows for secure point-to-point communication. There are many implementations of OpenVPN including using it in many third-party router firmware (mentioned above). OpenVPN Access Server is one of the many implementations and the one used for this project.

This project was inspired by Hak5 1921 – Access Internal Networks with Reverse VPN Connections. As an Amateur Radio operator into the newer computer and digital technologies, more devices are located at remote sites.

This setup consists of:

  1. A remote network behind a firewall where devices exist you want to access. This will be a Linux server on the remote network that will act as the gateway and persistently connected to the bridge. This could be a full desktop computer purposed for something else or Raspberry Pi. Also on the same network will be a Windows machine.
  2. An unsecure/unknown network, AKA the Internet.
  3. A private server that will act as the bridge between the remote network and a device you choose.
  4. A device in a separate location that will connect to the cloud server and will be able to access the remote network. I will use a Windows machine to act as a ‘home’ computer.

This setup works in nearly all cases because the only device receiving incoming connections is the bridge server in the cloud. Firewalls block incoming connections by default. Very few block connections originating inside the network out to the Internet (egress). If a device along the way filters by content, connection attempts will be blocked. Many corporate networks are doing this kind of filtering. Otherwise the traffic looks the same as secure web traffic on port 443. No port forwarding is used.

Hosting

I recommend using an infrastructure hosting provider for the bridge server. This can cost anywhere from $5-$15 per month. The device can be anywhere on the public Internet. It must accept multiple connections on different ports but only by a couple users at a time are needed. Minimal configuration is more than sufficient. Bandwidth, latency, and up-time of all points in this setup effect reliability. My personal recommendations for infrastructure hosting providers are: Rackspace and DigitalOcean.

IP addressing

All remote networks and the home user networks cannot overlap in address space. That is they need to be differently numbered. For example, typically home networks have addressing as 192.168.1.x. The remote site(s) can’t have the same numbering (192.168.1.x). It must be different. I suggest making the remote site different enough to not cause conflict with any home users’ networks. Remote sites as 192.168.25.x, 192.168.26.x, and 192.168.27.x would work fine when the home users’ networks is addressed 192.168.0.x, 192.168.1.x, 192.168.2.x, and so on (except 25-27). Similarly addressed networks create routing conflicts and the packets will not reach the correct network.

Downsides

Cost.

In addition to hosting, a downside to using OpenVPN Access Server is licensing. While OpenVPN is Open-Source Software and OpenVPN Access Server is free, the license allows for only two concurrent tunnel connections at any one time. This means the remote site counts as one connection and the home device the second. If a second person (third device) needed access to the remote network, they would get a message saying ‘Access Server has reached its concurrent connections limit.’ The first person would need to disconnect first before the second could connect otherwise current connections will begin to be booted. Additionally, connecting two or more remote sites and a home user is not possible without purchasing licenses or running an additional bridge server. Additional licenses can be purchased for “$9.60 License Fee Per Client Connection Per Year. Support & Updates included. 10 Client minimum purchase.” $96 per year.

An alternative to OpenVPN Access Server is to setup your own (roll your own) OpenVPN server which is free. I hope to do an OVPN server setup at some point in the future.

Assumptions

This guide is step-by-step in nature, meant for beginners, with brief explanations of the steps. It will help to have an understanding of Linux commands and scripting. Capitalization is important in Linux! Understanding of basic networking concepts including determining network prefixes and CIDR notation is also required.

Program versions

I used a Windows 7 64 bit PC for configuration (and Home PC). Applications and versions used in this writeup:

  • OpenVPN Access Server 2.0.24
  • Putty 0.67
  • Ubuntu 14.04 x64 (bridge and remote servers)
  • Filezilla 3.16.0