开云体育

The following announcement was just released on the QuadNet website: In order to better serve the QuadNet D-Star Routing community, we are moving our D-Star Routing IRC Servers. The new URLs for the IPv4 and IPv6 IRC servers are ircv4.openquad.net and ircv6.openquad.net, respectively. There will still be a diminished server operating on rr.openquad.net to fulfill the login needs of clients still using that address, but it will no long provide IRC update messages to its clients. In other words, clients still using rr.openquad.net will no longer be able to find IP addresses for their desired routing targets. If you use routing on QuadNet, be sure to update the IRC routing server name in your hot-spot or reflector software. If you operation a Smart Group Server or are STARnet Server, you will also need to update those clients. If you don't do D-Star Routing, no action on your part is required. This move will not affect REF, DCS, XRF or XLX linking to any of our reflectors, XLX307, XLX587, XRF735 or XRF757. I just pushed up a new version. If you are using the default values for connection to our ircddb server, you will need to do an uninstall, git pull and install. If you are operating in dual-stack mode (IPv4 and IPv6) you just need to update your irc connection server hostnames with qnconfig and restart your system.

There are a couple of new features: If you never do any routing (you only do linking), you can disable IRCDDB by clearing the ha parameter in the IRCDDB Menu of ./qnconfig. This normally defaults to "rr.openquad.net", so you have to set it to an empty string by entering "ha" followed by a <return>. Also make sure the hb parameter has its default value. This will shut off the traffic between your gateway and the QuadNet Servers and so will be especially useful to users that have a low-quality, low-speed connection to the internet. Because you're not connected to the QuadNet Servers, you won't see your transmission on the www.openquad.net Last Heard page, but you will still see your activity on any reflector dashboard, including XLX307, XRF757 and XRF735. Two new columns have been added to the Last Heard dashboard: the sender's 20-character text message, and, if the sender has enabled the GPS in his radio, his current 6-character Maidenhead grid square, linked to google maps. To make these new columns work, qngateway now reads the slow data that is sent in the AMBE voice packets. This slow data is not FEC encoded, so it's is not that reliable, you may occasional see some unusual characters in the text message, or you may see a message in the qngateway log that it can't figure out how to parse the GPS data. There is also a big internal change. Inter-process communication now uses bidirectional Unix sockets. QnetGateway has been using one-way Unix sockets as a way to emulate the previous UDP communications over the loopback device (127.0.0.1), but this new protocol is even more efficient than the one-way Unix sockets. Finally, there is also a new capability in this release that can't be used yet because there is no infrastructure to support it. We're working on that and when that infrastructure becomes available, I'll make an announcement here.

There are several changes in this release. It is very important to uninstall your system before upgrading. The Makefile had been installing system scripts in /lib/systemd/system and I realized they should have been going in /etc/systemd/system instead. It's not a really big deal where they end up, but I should follow Linux convention. So you will want to completely uninstall your system before downloading the new code (including a new Makefile) and reinstalling. This version fixed IRC logging. It had been broken for several releases, ever since I redesigned the IRC routing cache used by qngateway. If you turn IRC Logging on, you'll see most of the traffic that comes to qngateway from the IRC server, updating mostly what reflectors users are using and gateways as they log into the openquad.net network. The qnconfig script will not let you accidentally specify an IRC hostname with commas instead of periods. I also found a much faster way for the dashboards to report you IP addresses. Instead of using "curl", which can be incredibly slow at times, the dashboards now use a dns utility called "dig". Most Linux distributions include dig in a package called dnsutils, but unfortunately it is not included in the Raspberry Pi OS, at least in the Lite version. So, Raspberry Pi Owners, you have two choices: Install the dns package with "sudo apt update && sudo apt install dnsutils", or, Simply uninstall and reinstall the dashboard with "sudo make uninstalldash && sudo make installdash".

IP address moved. Here is the dashboard relating to my previous request for help. Carty KA2Y

Tom's instructions state that Bluetooth needs to be disabled. After many hours, I realised that's true ;(. I thought turning it off in the preferences on the Pi would do the trick, but finally figured out that's not good enough. There is no error message, it says the modem runs.. it just doesn't work! On the bright side, I have it all working now and gave one of my Pi's an extra job. It is used to run an APRS HF/VHF gateway using Direwolf, but it has plenty of spare capacity for other work.

For some time QnetGateway has supported MMDVMHost as a modem type. In the MMDVM.README file, I use to say that you could add other modes and left it up to you how to do that. Thanks to a lot of help from Ryan W4EAE and Will W4WWM, QnetGateway will now help you build and install not only MMDVMHost, but also DMRGateway, YSFGateway and APRSGateway. This is not a newbee exercise. It takes some skill to put together a multi-mode hot-spot. It would probably be very helpful if you already are familiar with how these other gateways operated. For example, you have used them in PiStar and understand how to configure them. BTW, you don't have to build everything. If you don't do YSF, don't add it to your system. If you don't do DMR, that can be ignored. Most of the modifications for this new release are in the MMDVM.README file and the qnadmin file. The ./qnadmin command can be used to build install and maintain you multi-mode hot-spot. You might ask, "Why would I want to do that, when PiStar is available?". The answer comes in two parts: First QnetGateway is a better ircDDB client than ircDDBGateway, especially if you do DStar routing. The second part has to do with the multi-mode stuff, and I will quote Ryan: "The main advantage of this build over Pi-Star is that the various individual repositories are fully up to date. PiStar is always going to be behind as changes must be incorporated into--or least be tested not to disrupt or break--the gui and other aspects of the Pi-Star image like pistar-remote or pistar-firewall. As an example, DMRGateway directly from the repository currently supports more DMR networks and more granular network configuration than Pi-Star, as well as ipv6 connectivity."

This is from Terry (N8LN)... and a related question is there any way to change the re-connect attempt time delay? I did get blocked for a bit on REF030 due to "hammering" with just the one "hotspot" (Qnet) active when my ISP acted up .. twice This is what Terry said for the record, a second connection attempt to reflector 001 or 030 is not automatically or immediately blocked. It is denied automatically. Then if it keeps trying to reconnect, gets denied, tries again over and over. The software on the hotspot should delay additional connection attempts after receiving a busy packet. It’s like a person banging on your door and won’t stop if you don’t answer. Multiply this 30 or 40 devices and you can see the amount of unnecessary traffic/overhead generated. If the end user realizes what they have done (because their 2nd device is not connecting), and they stop trying, all is well. If it continues banging at the door, it gets blocked. Typically I receive a notification and make every attempt to notify the end user of the issue and possible solutions. Once they acknowledge the issue they are unblocked. Unfortunately I am not always able to find an e-mail address, the address is no longer valid or I receive no reply back. Remember the folks who built and pay for the operation of these busy reflectors, hosted in data centers still have jobs and lives. We are all voluntarily maintaining and administering the system to keep it operational and stable for all at no cost to the end users. The purpose of the blocks are to keep the system stable and available. I have a difficult time taking seriously the complaints of a very few. Most use the system responsibly and have no problems. -Terry N8LN In both cases I only had one hotspot active or one on REF030 (The other if active woudl have been elsewhere 089)

Maybe I'm dense, but I configured and installed following the instructions for DVAPs. DVAP works and responds, but won't link to anything. I am registered on DPlus, but I can't even link to REF systems or D-STAR repeaters. Services show "up," but it seems like nothing is reaching out to link. After config, I run "is" to install and this is shown after all the activity: systemctl: unrecognized option '--value' systemctl: unrecognized option '--value' systemctl: unrecognized option '--value' systemctl: unrecognized option '--value' systemctl: unrecognized option '--value' systemctl: unrecognized option '--value' QnetGateway is not installed QnetLink is not installed DTMF is not installed systemctl: unrecognized option '--value' systemctl: unrecognized option '--value' Module C - qndvap is not installed I have tried using both my personal call as well as a dedicated gateway call for ircddb. Any help greatly appreciated. Cameron

Figured out why I could now SSH into Pi-star after changing wi-fi configuration Stupid user error in case anyone wonders (ssh 192l.. instead of ssh pi@192.....) But alas was a couple minutes too late now I have it up and running. Installed Splite 3 Git-ed Qnet gateway. Configured and workign But NO DASHBOARD.. yup says page not found

Ok I googled how to do it on Raspberry pi but remain confused Anyone have a suggestion. I know one way to change but not to add.

Wanted to clean out the last heard log on the Dashboard.. Decided to try "Restart" (GX) sure enough. worked like a charm. Remained connected to the other than default reflector and cleared out the last heard So now I'm all prepared for the net. Made a mistake in the original RX is Reboot GX is Restart gatewayu

First I had an issue with my ID-51 today. Dang thing just won't work after you do a US and GP and forget the IS step.. (Yup that's what it was) had a couple folks with ID-4100's they are trying Terminal mode with Pi-Star. Not having a lot of joy. Seems it just won't transmit from time to time. Pointed them here. Hope it helps.

Colby and I have finally completed our big upgrade of the QuadNet network and so now I can tell you about the new capability in QnetGateway. All four of our reflectors, XLX307, XLX587, XRF735 and XRF757 are now operating in dual stack mode and that means that linking can now be done using IPv6 addresses. Of course, QnetGateway is currently the only DStar client that is capable of linking over IPv6. Here is how you enable it: First, you need to make sure your hot-spot or repeater has a valid IPv6 address. Try "curl -6 icanhazip.com" from your system. If it reports an IPv6 address, you're ready! Make sure QnetGateway is configured for dual stack operation. In the IRCDDB sub-menu of ./qnconfig, make sure "ha" is set to "rrv6.openquad.net" and "hb" is set to "rr.openquad.net". In the Gateways sub-menu of ./qnadmin, execute the "i6" command to build a new gwys.txt file containing the IPv6 addresses for our four reflectors. Restart QnetGateway and then you will be able to link to any of our reflectors using DExtra, DCS or DPlus through an IPv6 connection! After you've linked up using IPv6, go to the "Links" page of the reflector and you should see the list 32 bits of the 128-bit IPv6 address for you system. If you want to link to the QuadNet Array, please consider linking to 735A rather than 757A or 307D, It's generally not nearly as busy as 757 or 307. Likewise, the QuadNet Tech Channel is available on 735C. But also, please remember we built the QuadNet network for IRCDDB routing and I greatly encourage you to give that a try.

My Gateway will not connect to Icom radio unless I have a HDMI plugged into the pi.. It boots ok but will not show Icom Radio connected until I plug in the HDMI .. Puzzled :(

Upon booting up the Pi... the dashboard shows that a connection exists when it does not.

Any chance that QNet could be overlayed with an existing Icom G3 installation. Some of our gateways have hundreds of registered USTRUST users we do NOT want to orphan! I have a Installation document that lets us add a DL5DI OpenDV with G3 that let’s us keep the registration piece, turn off dplus. Sure the gateway now looks like a hotspot, but users like the simpler command set. I’ve installed g2_link on many G2 and G3 systems and it works but users don’t understand the split dashboards and two different command sets. Terry

Hello Tom… And everyone in the QuadNet2 USA IRC Network QnetGateway group. Jeff, VE6DV, suggested that I try out this approach to DStar. It sounds like a challenge and fun so we jumped right in with both feet. I like the lightweight nature of this software. I have a DVAP that I hadn’t used for several years because it would never work consistently on my iMac without restarting it every couple of hours. The Mac would go to sleep and when it did, bye bye DVAP During the past year however I have built up four or five raspberry pi computers and are using them for several radio related projects. It struck me that this would be a great application for one of my raspberry pi’s. I now have the 70 CM DVAP connected via USB to my Raspberry Pi 3B. I installed the latest Buster version of Raspian on the 3B. I didn’t think I had any problems understanding and performing the configuration or the Building of the Qnet Gateway software. For the most part the logs look normal but I’m missing something because I can’t seem to link to one of the DSTAR Smart Servers and/or any Reflectors. Minor details… hi hi It’s has to be something simple I missed but I have been unable to find it. To help anyone that can point me in the right direction I have attached a text file containing the output of the tail of the logs for QnetGateway, QnetLink and QnetDVAP. I have also placed the details of my current configuration in this file! I hope this will make it easy to point me in the right direction. I use an Icom ID-51A on the radio side. And program it with the RT Systems Programming software. I’m pretty sure I have it setup correctly. But I could have a mistake in there also. I also own an Anytone 868 and use it with Jeff’s multi-network configuration settings on Pi-Star installed on a ZumSpot. The combination is great! Do I have to turn off the DMR hotspot when I want to fire up the DSTAR DVAP? Thank you to anyone who can help me get this system on the air. 73 de Dale - K0HYD -- Dale L Puckett K0HYD Goddard, KS 67052 Member Society of Professional Journalists