Re: QnetGateway dashboard issue
Yes, the bogus link status actually will survive multiple reboots. The only way I could get it to clear was to link to the reflector it mistakenly thought it was linked to... and then unlink. Then it would clear.
I uninstall and reinstall using the admin tool all the time. And I don’t have anything set to link at startup. I will try your other suggestions and report back.
|
Re: QnetGateway dashboard issue
Good point Colby.. Have had that happen on other sites more times than I care to count.
"Nothing adds excitement like something that is none of your business" Note I am not a doctor, I don't even play one on television John F Davis
On Thursday, May 28, 2020, 01:07:55 PM EDT, Colby Ross W1BSB <colbypr@...> wrote:
It could be his browser caching this information and not refreshing correctly. Colby ? ?
From: [email protected] < [email protected]> On Behalf Of Tom Early Sent: Thursday, May 28, 2020 1:04 PM To: [email protected]Subject: Re: [QnetGateway] QnetGateway dashboard issue ? Sorry Elden, I can't reproduce what you are seeing. If I link to XRF757 A, it shows that on my dashboard. If I then reboot my ZUMspot and it comes back up, the dashboard shows I'm not linked.? One of the first things QnetLink does when it starts it to automatically clear all linking information from the Sqlite3 database, so I'm not sure how that bogus linking information is surviving a reboot. Please double check you configuration to make sure that your module is not programmed to automatically link to a reflector upon boot up. (It's called "Link at startup" and is the first menu item in the configured module submenu.)
Another possibility is that somehow the database can no longer be opened with write permission. To check that, open a new terminal window and do "sudo journalctl -u qnlink -f" and then link and reboot you system and watch for database writing error message. If these occur, uninstall your system from the ./qnadmin tool. The uninstall should remove the damaged database, but just to be sure, you can exit qnadmin and do "sudo rm /usr/local/etc/qn.db". Then you can use ./qnadmin to reinstall you system.
Also, just to let everyone know, it is a feature of QnetLink that you can only link a module if it is currently unlinked.
|
Re: QnetGateway dashboard issue
It could be his browser caching this information and not refreshing correctly. Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Tom Early Sent: Thursday, May 28, 2020 1:04 PM To: [email protected]Subject: Re: [QnetGateway] QnetGateway dashboard issue ? Sorry Elden, I can't reproduce what you are seeing. If I link to XRF757 A, it shows that on my dashboard. If I then reboot my ZUMspot and it comes back up, the dashboard shows I'm not linked.? One of the first things QnetLink does when it starts it to automatically clear all linking information from the Sqlite3 database, so I'm not sure how that bogus linking information is surviving a reboot. Please double check you configuration to make sure that your module is not programmed to automatically link to a reflector upon boot up. (It's called "Link at startup" and is the first menu item in the configured module submenu.)
Another possibility is that somehow the database can no longer be opened with write permission. To check that, open a new terminal window and do "sudo journalctl -u qnlink -f" and then link and reboot you system and watch for database writing error message. If these occur, uninstall your system from the ./qnadmin tool. The uninstall should remove the damaged database, but just to be sure, you can exit qnadmin and do "sudo rm /usr/local/etc/qn.db". Then you can use ./qnadmin to reinstall you system.
Also, just to let everyone know, it is a feature of QnetLink that you can only link a module if it is currently unlinked.
|
Re: QnetGateway dashboard issue
Sorry Elden, I can't reproduce what you are seeing. If I link to XRF757 A, it shows that on my dashboard. If I then reboot my ZUMspot and it comes back up, the dashboard shows I'm not linked.? One of the first things QnetLink does when it starts it to automatically clear all linking information from the Sqlite3 database, so I'm not sure how that bogus linking information is surviving a reboot. Please double check you configuration to make sure that your module is not programmed to automatically link to a reflector upon boot up. (It's called "Link at startup" and is the first menu item in the configured module submenu.)
Another possibility is that somehow the database can no longer be opened with write permission. To check that, open a new terminal window and do "sudo journalctl -u qnlink -f" and then link and reboot you system and watch for database writing error message. If these occur, uninstall your system from the ./qnadmin tool. The uninstall should remove the damaged database, but just to be sure, you can exit qnadmin and do "sudo rm /usr/local/etc/qn.db". Then you can use ./qnadmin to reinstall you system.
Also, just to let everyone know, it is a feature of QnetLink that you can only link a module if it is currently unlinked.
|
Re: QnetGateway dashboard issue
Ok... I was able to reproduce my second scenario. I’m sure you’re asking, why would anyone do this???
But if I do reboot with an active connection to a D-Star reflector... the dashboard does think I’m still linked when it comes back up. AND... if I do link to a different reflector and then unlink... it once again shows me as being connected to that original reflector it showed me connected to when it booted up.
|
Re: QnetGateway dashboard issue
Any D-Star reflector. It might be tied to a situation where the connection is not dropped via the command to do so. Like... rebooting the Pi with a connection active. I think I also had some weirdness happening when I issued a link command without unlinking. After doing that... when I did unlink... it told me I was still linked to the original reflector.
Update: Ok... I just went back and tested this. The first scenario is true. When one reboots with a D-Star/reflector connnection active... the connection still shows active after things come back up.
The second scenario is false. Doesn’t happen. Because it clearly prevents me from linking anywhere if it’s already linked.
|
Re: QnetGateway dashboard issue
Sorry, I'm coming up with a blank. What sort of a connection?
On 5/27/20 1:00 PM, Elden W7LDN wrote:
Upon booting up the Pi... the dashboard shows that a connection
exists when it does not.
--
___________________________
73
n7tae (at) tearly (dot) net
|
QnetGateway dashboard issue
Upon booting up the Pi... the dashboard shows that a connection exists when it does not.
|
Ugh. I tried it again when I got home from work tonight. It worked perfectly. I changed nothing! Sorry to trouble you all. Thanks for the help.
|
I know this is a bit off-topic, but this KT4ROY club seems pretty cool. They are a student-based ham club from a college I believe. And they seem to like smart groups!
|
On Mon, May 18, 2020 at 04:03 PM, Colby Ross W1BSB wrote:
Its not an IP Address issue, its something else on their end. We’ve emailed them to let them know.
?
Thanks! That was nice of you. I appreciate it. I haven't used smartgroups all that much... but the list of them seems to be growing. So I figure I'll dedicate one of my radios to doing that with QnetGateway. Seems like a good combo.
|
Its not an IP Address issue, its something else on their end. We’ve emailed them to let them know. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Elden W7LDN Sent: Monday, May 18, 2020 19:01 To: [email protected]Subject: Re: [QnetGateway] DSTAR2 and DSTAR1 ? On Mon, May 18, 2020 at 12:28 PM, Tom Early wrote: Do you have QnetGateway configured to only use IPv6, rrv6.openquad.net? That would explain it. The server ILLINK runs on a server is not dual stack. It is only available on IPv4, rr.openquad.net.
No, my configuration is IPv4-only. I am in the process of initiating contact with the folks at the club who sponsor these KT4ROY groups. It does sound like perhaps an out of date IP address from what Colby is saying. I suppose it could be informative for someone else to test the ILLINK smartgroup. If others are having the same problem then there is no sense looking at my configuration.
|
On Mon, May 18, 2020 at 12:28 PM, Tom Early wrote:
Do you have QnetGateway configured to only use IPv6, rrv6.openquad.net? That would explain it. The server ILLINK runs on a server is not dual stack. It is only available on IPv4, rr.openquad.net.
No, my configuration is IPv4-only. I am in the process of initiating contact with the folks at the club who sponsor these KT4ROY groups. It does sound like perhaps an out of date IP address from what Colby is saying. I suppose it could be informative for someone else to test the ILLINK smartgroup. If others are having the same problem then there is no sense looking at my configuration.
|
Hi Elden,
Do you have QnetGateway configured to only use IPv6, rrv6.openquad.net? That would explain it. The server ILLINK runs on a server is not dual stack. It is only available on IPv4, rr.openquad.net.
Tom
|
The required information is the gateway and IP address that the group is located it. When you get the not in cache message, your IRCDDB client sends a request to QuadNet’s servers on how to locate the group you are trying to reach, and our servers return the IP address of the gateway the group is hosted at so your client then knows how to reach it. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Elden W7LDN Sent: Monday, May 18, 2020 2:12 PM To: [email protected]Subject: Re: [QnetGateway] DSTAR2 and DSTAR1 ? On Wed, Apr 15, 2020 at 10:25 AM, Colby Ross W1BSB wrote: After the first not in cache, it should add the required information to the local cache on how to route to that group, so the 2nd call will go through successfully.
Where does this "required information" come from? And what does the required information consist of? For instance... if I was having trouble connecting to a reflector... I'd suspect an outdated IP address or something.?
|
On Wed, Apr 15, 2020 at 10:25 AM, Colby Ross W1BSB wrote:
After the first not in cache, it should add the required information to the local cache on how to route to that group, so the 2nd call will go through successfully.
Where does this "required information" come from? And what does the required information consist of? For instance... if I was having trouble connecting to a reflector... I'd suspect an outdated IP address or something. My plan is to contact the person in charge of the ILLINK smart group. But I'd like to at least point him in the right direction.
|
Re: QnetGateway + ID-4100A in Access Point Mode + ID51A Plus
A new release is available that properly supports Access Point Mode. With this new release, if you intend on running in AP Mode, you need to enable it in your configuration. The ./qnconfig will show you the way. Go to your configured ITAP module menu and you'll see a new "ap" parameter. To update, uninstall your system, do a "git pull" and then reconfigure (./qnconfig) and re-install your system.
Please note that Terminal Mode will still work if you've enabled AP Mode, it just won't be quite as efficient.
If you run exclusively in Terminal Mode (or if you don't use ITAP), there is no need to update QnetGateway at this time.
I'd like to thank Rob VY1RG for helping me develop this fix.
|
On Sun, May 17, 2020 at 10:52 AM, John F Davis wrote:
I have had that happen as well when trying DSTAR1 or 2?
As was said..? Try again.. Usually the fist Kerchunk gets a NOT IN CACHE. the 2nd works fine and then it continues to work for two hours. (Reset every time you transmit) or till you kerchunk with DSTAR1 T (or whatever it is. T is in the command slot (8th Character).
Yes I understand that John. I did read the thread. And I’ve experienced that message many times. The difference here is, it never actually connects. It keeps repeating the message with every attempt.
|
Its not a smart group run by our team, its run by someone else so I couldn’t say if its misconfigured or not. ?If rebooting your hotspot doesn’t work, the problem is likely on their end. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Elden W7LDN Sent: Sunday, May 17, 2020 13:20 To: [email protected]Subject: Re: [QnetGateway] DSTAR2 and DSTAR1 ? Colby... last night I was playing with some of the other smart groups listed on the quadnet web site. When I tried ILLINK... I received the "not in cache" message. While I did try several more times... each time I continued to get that same message and was never able to actually log in. Is ILLINK misconfigured?
On Wed, Apr 15, 2020 at 10:25 AM, Colby Ross W1BSB wrote: When you get not in cache, key up again. ? Nothing is in the cache when a hotspot or repeater first boots up. After the first not in cache, it should add the required information to the local cache on how to route to that group, so the 2nd call will go through successfully. ? Colby ? ? ? When I try to connect to the smartgroups on DSTAR1 or DSTAR2 or some local repeaters I am getting not in cache message, Any help would be appreicated
|
I have had that happen as well when trying DSTAR1 or 2?
As was said..? Try again.. Usually the fist Kerchunk gets a NOT IN CACHE. the 2nd works fine and then it continues to work for two hours. (Reset every time you transmit) or till you kerchunk with DSTAR1 T (or whatever it is. T is in the command slot (8th Character).
Have had mixed luck. have done it.
I like using the Smart groups but.. it is easier to use xrf757A because the hotspots hook up under crontab control? ?No need to "Adjust" the radio.?
|
Elden AI7HL
Tom Early