Re: Qnlink has some problems
The gateway file is gwys.txt, not gwy.txt. If you updated the gwys.txt file while qnlink was running, it won't automatically read the modified file. You need to send an "?????? F" to the gateway to load the gwys.txt file again.
From your screenshot, it looks like your linking to REF030 C okay.
|
Hi everyone,
Thank you in advance.
I have installed the QnetGateway and it has worked very well.
Today I am installing new QnetGateway which is updated within 30 days ago.
But It has problems in qnLink process.
When booting and/or changing the gateway, qnLink says the gateway not found in gwy list.
But the gateway exists in gwy.txt.
de DS5HVM Korea.
|
 -- Hi everyone, Thank you in advance. I have installed the QnetGateway for MMDVM Board, it works very well. Today I am installing new QnetGateway which is updated in 30 days ago.? It has problem to link at gateway, in especial qnlink process. The qnLink says that gateway not found in gwy listt.? But the gateway exists in gwy.txt. de DS5HVM
|
Re: newbee question on mixed or hybrid setups
how to get multiple public IP addresses into your station.?
On Fri, Apr 17, 2020, 20:19 Colby Ross W1BSB < colbypr@...> wrote: Not if you want routing to work, since you can only forward UDP Port 40000 to one system. This really shouldn’t happen in the wild.? I would suggest using a VPN or something for the second system so it can get its own IP address, or else there would be no reason to use QnetGateway or QnetICOMGateway, since its primary purpose is a reliable routing network. ? Colby ? ? ? Reading the mail, I think I understand that for QnetGateway works with homebrew repeaters and hot spots.? For Icom "stacks" you need QnetICOMGateway. Can both gateway programs co-exist behind a common public IP??
|
Re: newbee question on mixed or hybrid setups
Not if you want routing to work, since you can only forward UDP Port 40000 to one system. This really shouldn’t happen in the wild.? I would suggest using a VPN or something for the second system so it can get its own IP address, or else there would be no reason to use QnetGateway or QnetICOMGateway, since its primary purpose is a reliable routing network. ? Colby ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Ken Jamrogowicz via groups.io Sent: Friday, April 17, 2020 11:26 To: [email protected]Subject: [QnetGateway] newbee question on mixed or hybrid setups ? Reading the mail, I think I understand that for QnetGateway works with homebrew repeaters and hot spots.? For Icom "stacks" you need QnetICOMGateway. Can both gateway programs co-exist behind a common public IP??
|
newbee question on mixed or hybrid setups
Reading the mail, I think I understand that for QnetGateway works with homebrew repeaters and hot spots.? For Icom "stacks" you need QnetICOMGateway. Can both gateway programs co-exist behind a common public IP??
|
toggle quoted message
Show quoted text
On Apr 15, 2020, at 5:14 PM, John F Davis <wa8yxm@...> wrote:
?
When you are using Smart Groups like DSTAR1.. your "TO" field should show DSTAR1.. you do not go back to "Use Reflector" because you are NOT using a reflector. Thus till you decide to "Terminate" your chat with DSTAR1 (by sending DSTAR1 T) your radio should
show DSTAR1... No need for Qnet to duplicate that.. Just remember to T-erminate when you are done.
"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 Wednesday, April 15, 2020, 04:35:18 PM EDT, David Murray [DATACOM] <davidmu@...> wrote:
Great stuff!
?
Love your work Tom.
?
?
Cheers
?
David ZL2YZ
?
?
?
By default, the acknowledgement that you see on each key up is from qnlink. It's just reminding you that you are not linked.
Just as a quick reminder, when you are linked, there is a state maintained by both the server and client. This state is effected by a constant ping-ponging going on between the client and server. If either server or client drops, the other will find out
fairly quickly.
Routing is different. There is no state maintained by either the client or server. The QuadNet Routing Group web pages logs subscription and unsubscription events for Smart Groups, but not for legacy STARnet groups.
Once logged into Smart Group, the server will maintain a keep alive ping to the clients (no pong from the client is returned) but that pinging is strictly for keeping a client's fire wall open. (This is how Colby and I figured out how to make group routing
work with mobile clients.) It has nothing to do with maintaining a connection state. A routing group has no idea if a client is still listening. That's why routing groups (both Smart Groups and STARnet Groups) have client timeouts. Because there is no state
maintained, there has to be some "drop dead" time when the server assumes the client is no longer there.
It would be extremely difficult to teach QnetGateway to maintain a software state for each subscribed routing group. For one thing, a client doesn't have access to the timeout parameter of that group, so it could only guess when a server might drop it due
to timeout. It could tell by the pinging from a Smart Group, but what about legacy STARnet Groups? In any event, how could the QnetGateway software communicate the subscription status to a radio when the user is subscribed to multiple routing groups? That
problem is not easy to solve!
Tom N7TAE
On 4/15/20 10:57 AM, Elmer Delgado wrote:
Ahhh but it would help to include something to let you know your logged into the smart groups ?just saying?
no
On Apr 15, 2020, at 12:47 PM, Colby Ross W1BSB<colbypr@...> wrote:
?
Routing is not linking. =)
?
Colby
?
?
?
I also noticed that when logged into the smartgroups that is does not show you linked into anything so it kind of throws you a curve
--
___________________________
73
n7tae (at) tearly (dot) net
|
When you are using Smart Groups like DSTAR1.. your "TO" field should show DSTAR1.. you do not go back to "Use Reflector" because you are NOT using a reflector. Thus till you decide to "Terminate" your chat with DSTAR1 (by sending DSTAR1 T) your radio should show DSTAR1... No need for Qnet to duplicate that.. Just remember to T-erminate when you are done.
"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 Wednesday, April 15, 2020, 04:35:18 PM EDT, David Murray [DATACOM] <davidmu@...> wrote:
Great stuff! ? Love your work Tom. ? ? Cheers ? David ZL2YZ ? ?
From: [email protected] <[email protected]>On Behalf Of Tom Early
Sent: Thursday, 16 April 2020 06:44 a.m.
To: [email protected]
Subject: Re: [QnetGateway] DSTAR2 and DSTAR1 ? By default, the acknowledgement that you see on each key up is from qnlink. It's just reminding you that you are not linked. Just as a quick reminder, when you are linked, there is a state maintained by both the server and client. This state is effected by a constant ping-ponging going on between the client and server. If either server or client drops, the other will find out fairly quickly. Routing is different. There is no state maintained by either the client or server. The QuadNet Routing Group web pages logs subscription and unsubscription events for Smart Groups, but not for legacy STARnet groups. Once logged into Smart Group, the server will maintain a keep alive ping to the clients (no pong from the client is returned) but that pinging is strictly for keeping a client's fire wall open. (This is how Colby and I figured out how to make group routing work with mobile clients.) It has nothing to do with maintaining a connection state. A routing group has no idea if a client is still listening. That's why routing groups (both Smart Groups and STARnet Groups) have client timeouts. Because there is no state maintained, there has to be some "drop dead" time when the server assumes the client is no longer there. It would be extremely difficult to teach QnetGateway to maintain a software state for each subscribed routing group. For one thing, a client doesn't have access to the timeout parameter of that group, so it could only guess when a server might drop it due to timeout. It could tell by the pinging from a Smart Group, but what about legacy STARnet Groups? In any event, how could the QnetGateway software communicate the subscription status to a radio when the user is subscribed to multiple routing groups? That problem is not easy to solve! Tom N7TAE On 4/15/20 10:57 AM, Elmer Delgado wrote: Ahhh but it would help to include something to let you know your logged into the smart groups ?just saying?
no
On Apr 15, 2020, at 12:47 PM, Colby Ross W1BSB<colbypr@...> wrote:
? Routing is not linking. =) ? Colby ? ? ? I also noticed that when logged into the smartgroups that is does not show you linked into anything so it kind of throws you a curve
-- ___________________________ 73 n7tae (at) tearly (dot) net
|
Great stuff!
?
Love your work Tom.
?
?
Cheers
?
David ZL2YZ
?
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Tom Early
Sent: Thursday, 16 April 2020 06:44 a.m.
To: [email protected]
Subject: Re: [QnetGateway] DSTAR2 and DSTAR1
?
By default, the acknowledgement that you see on each key up is from qnlink. It's just reminding you that you are not linked.
Just as a quick reminder, when you are linked, there is a state maintained by both the server and client. This state is effected by a constant ping-ponging going on between the client and server. If either server or client drops, the other will find out
fairly quickly.
Routing is different. There is no state maintained by either the client or server. The QuadNet Routing Group web pages logs subscription and unsubscription events for Smart Groups, but not for legacy STARnet groups.
Once logged into Smart Group, the server will maintain a keep alive ping to the clients (no pong from the client is returned) but that pinging is strictly for keeping a client's fire wall open. (This is how Colby and I figured out how to make group routing
work with mobile clients.) It has nothing to do with maintaining a connection state. A routing group has no idea if a client is still listening. That's why routing groups (both Smart Groups and STARnet Groups) have client timeouts. Because there is no state
maintained, there has to be some "drop dead" time when the server assumes the client is no longer there.
It would be extremely difficult to teach QnetGateway to maintain a software state for each subscribed routing group. For one thing, a client doesn't have access to the timeout parameter of that group, so it could only guess when a server might drop it due
to timeout. It could tell by the pinging from a Smart Group, but what about legacy STARnet Groups? In any event, how could the QnetGateway software communicate the subscription status to a radio when the user is subscribed to multiple routing groups? That
problem is not easy to solve!
Tom N7TAE
On 4/15/20 10:57 AM, Elmer Delgado wrote:
Ahhh but it would help to include something to let you know your logged into the smart groups ?just saying?
no
On Apr 15, 2020, at 12:47 PM, Colby Ross W1BSB
<colbypr@...> wrote:
?
Routing is not linking. =)
?
Colby
?
?
?
I also noticed that when logged into the smartgroups that is does not show you linked into anything so it kind of throws you a curve
--
___________________________
73
n7tae (at) tearly (dot) net
|
If you subscribe to the Quadnet D-Star users Facebooks groups I post most of information there .
But here is the link I used to build the dependencies
?
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]>
On Behalf Of scottplough via groups.io
Sent: Wednesday, April 15, 2020 1:30 PM
To: [email protected]
Subject: Re: [QnetGateway] DSTAR2 and DSTAR1
?
Hi Elmer,
?
If you haven’t already, could you share the process for getting your OLED working?? Not only am I sure that I will be wanting to do that someday, but I am sure that others will too.
?
Many thanks and…
?
?
73 de,
?
Scott
W9ITU
Fairbanks, Alaska
?
Sent from for Windows 10
?
?
OK I got it now, Thanks Big and I finally got the 1.3 OLED working on the zumspot?
|
I have the D-74a and I used to see it on Pi-star but not seen the login message just the tone acknowledgment
?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]>
On Behalf Of Tom Early
Sent: Wednesday, April 15, 2020 1:44 PM
To: [email protected]
Subject: Re: [QnetGateway] DSTAR2 and DSTAR1
?
By default, the acknowledgement that you see on each key up is from qnlink. It's just reminding you that you are not linked.
Just as a quick reminder, when you are linked, there is a state maintained by both the server and client. This state is effected by a constant ping-ponging going on between the client and server. If either server or client drops, the other will find out
fairly quickly.
Routing is different. There is no state maintained by either the client or server. The QuadNet Routing Group web pages logs subscription and unsubscription events for Smart Groups, but not for legacy STARnet groups.
Once logged into Smart Group, the server will maintain a keep alive ping to the clients (no pong from the client is returned) but that pinging is strictly for keeping a client's fire wall open. (This is how Colby and I figured out how to make group routing
work with mobile clients.) It has nothing to do with maintaining a connection state. A routing group has no idea if a client is still listening. That's why routing groups (both Smart Groups and STARnet Groups) have client timeouts. Because there is no state
maintained, there has to be some "drop dead" time when the server assumes the client is no longer there.
It would be extremely difficult to teach QnetGateway to maintain a software state for each subscribed routing group. For one thing, a client doesn't have access to the timeout parameter of that group, so it could only guess when a server might drop it due
to timeout. It could tell by the pinging from a Smart Group, but what about legacy STARnet Groups? In any event, how could the QnetGateway software communicate the subscription status to a radio when the user is subscribed to multiple routing groups? That
problem is not easy to solve!
Tom N7TAE
On 4/15/20 10:57 AM, Elmer Delgado wrote:
Ahhh but it would help to include something to let you know your logged into the smart groups ?just saying?
no
On Apr 15, 2020, at 12:47 PM, Colby Ross W1BSB
<colbypr@...> wrote:
?
Routing is not linking. =)
?
Colby
?
?
?
I also noticed that when logged into the smartgroups that is does not show you linked into anything so it kind of throws you a curve
--
___________________________
73
n7tae (at) tearly (dot) net
|
Hi Elmer, ? If you haven’t already, could you share the process for getting your OLED working?? Not only am I sure that I will be wanting to do that someday, but I am sure that others will too. ? Many thanks and… ? ? 73 de, ? Scott W9ITU Fairbanks, Alaska ? Sent from for Windows 10 ?
toggle quoted message
Show quoted text
From: Elmer DelgadoSent: Wednesday, April 15, 2020 9:45 AM To: [email protected]Subject: Re: [QnetGateway] DSTAR2 and DSTAR1 ? OK I got it now, Thanks Big and I finally got the 1.3 OLED working on the zumspot?
|
By default, the acknowledgement that you see on each key up is
from qnlink. It's just reminding you that you are not linked.
Just as a quick reminder, when you are linked, there is a state
maintained by both the server and client. This state is effected
by a constant ping-ponging going on between the client and server.
If either server or client drops, the other will find out fairly
quickly.
Routing is different. There is no state maintained by either the
client or server. The QuadNet Routing Group web pages logs
subscription and unsubscription events for Smart Groups, but not
for legacy STARnet groups.
Once logged into Smart Group, the server will maintain a keep
alive ping to the clients (no pong from the client is returned)
but that pinging is strictly for keeping a client's fire wall
open. (This is how Colby and I figured out how to make group
routing work with mobile clients.) It has nothing to do with
maintaining a connection state. A routing group has no idea if a
client is still listening. That's why routing groups (both Smart
Groups and STARnet Groups) have client timeouts. Because there is
no state maintained, there has to be some "drop dead" time when
the server assumes the client is no longer there.
It would be extremely difficult to teach QnetGateway to maintain
a software state for each subscribed routing group. For one thing,
a client doesn't have access to the timeout parameter of that
group, so it could only guess when a server might drop it due to
timeout. It could tell by the pinging from a Smart Group, but what
about legacy STARnet Groups? In any event, how could the
QnetGateway software communicate the subscription status to a
radio when the user is subscribed to multiple routing groups? That
problem is not easy to solve!
Tom N7TAE
On 4/15/20 10:57 AM, Elmer Delgado
wrote:
Ahhh but it would help to include something to let you know your
logged into the smart groups ?just saying?
no
On Apr 15, 2020, at 12:47 PM, Colby Ross
W1BSB <colbypr@...> wrote:
?
Routing is not linking. =)
?
Colby
?
?
?
I also noticed that when logged into
the smartgroups that is does not show you linked into
anything so it kind of throws you a curve
--
___________________________
73
n7tae (at) tearly (dot) net
|
Ahhh but it would help to include something to let you know your logged into the smart groups ?just saying?
toggle quoted message
Show quoted text
On Apr 15, 2020, at 12:47 PM, Colby Ross W1BSB <colbypr@...> wrote:
?
Routing is not linking. =)
?
Colby
?
?
?
I also noticed that when logged into the smartgroups that is does not show you linked into anything so it kind of throws you a curve
|
|
|
I also noticed that when logged into the smartgroups that is does not show you linked into anything so it kind of throws you a curve
|
OK I got it now, Thanks Big and I finally got the 1.3 OLED working on the zumspot?
|
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 ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Elmer Delgado Sent: Wednesday, April 15, 2020 13:25 To: [email protected]Subject: [QnetGateway] DSTAR2 and DSTAR1 ? 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
|
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
|
Re: IC-9700, Terminal Mode, QnetGateway
Sorry Dan, we're on completely different tracks...
You should be able to use a digital-to-USB cable which essentially turns your 9700 into either the equivalent of a DVDongle (Terminal Mode) or a high-powered hot-spot (Access Point Mode) without having to deal with the issues of handling G3 routing on you LAN that is hard-wired to UDP port 40000.
It's because of this hard-wiring that I really have no interest in reverse engineering G3 comms, even with the example now in the current XLX software. The digital cable is a much better way to go. It talks raw DStar voice stream packets, much like a DVAP or an MMDVM-compatible modem.
|
Re: IC-9700, Terminal Mode, QnetGateway
Thanks for your thoughts Tom.
So if there was a translator that could take the G3 routing calls that go over the LAN connection and turn them into something that looks like it came from mmdvmhost (or a dvap if that is easier/better), it could then talk to either ircddbgateway or QnetGateway.? That works for me.
|
Tom Early
John Hays - K7VE / WRJT-215
Ken Jamrogowicz
