Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

callsign routing does not work in dualstack environment #18

Open
shithubsucks opened this issue Oct 27, 2024 · 17 comments
Open

callsign routing does not work in dualstack environment #18

shithubsucks opened this issue Oct 27, 2024 · 17 comments

Comments

@shithubsucks
Copy link

callsign routing does not work when qnetgateway is configured for dualstack when the target cs is ipv4 only. For some reason

Oct 27 17:56:28 raspberrypi qngateway[60335]: starting CIRCDDB
Oct 27 17:56:28 raspberrypi qngateway[60335]: starting CIRCDDB
Oct 27 17:56:28 raspberrypi qngateway[60335]: Waiting for ircv6.openquad.net connection status of 2
Oct 27 17:56:28 raspberrypi qngateway[60335]: ircv6.openquad.net status=0
Oct 27 17:56:32 raspberrypi qngateway[60335]: Successfully connected to ircv4.openquad.net at [64:ff9b::a747:b6f5]:9007
Oct 27 17:56:32 raspberrypi qngateway[60335]: Successfully connected to ircv6.openquad.net at [2604:a880:800:c1::14e:c001]:9007
Oct 27 17:56:33 raspberrypi qngateway[60335]: ircv6.openquad.net status=0
[...]
Oct 27 17:56:41 raspberrypi qngateway[60335]: IRCDDBApp: state=2 choose new 's-'-user
Oct 27 17:56:41 raspberrypi qngateway[60335]: IRCDDBApp: state=2 choose new 's-'-user
Oct 27 17:56:42 raspberrypi qngateway[60335]: IRCDDBApp: state=3 tableID=1
Oct 27 17:56:42 raspberrypi qngateway[60335]: IRCDDBApp: state=3 tableID=1
Oct 27 17:56:43 raspberrypi qngateway[60335]: IRC server ircv6.openquad.net is using IPV6
Oct 27 17:56:43 raspberrypi qngateway[60335]: Waiting for ircv4.openquad.net connection status of 2
Oct 27 17:56:43 raspberrypi qngateway[60335]: IRC server ircv4.openquad.net is using IPV6
Oct 27 17:56:43 raspberrypi qngateway[60335]: QnetGateway...entering processing loop
Oct 27 17:56:43 raspberrypi qngateway[60335]: APRS beacon thread started
Oct 27 17:56:43 raspberrypi qngateway[60335]: get_irc_data thread[0] started
Oct 27 17:56:43 raspberrypi qngateway[60335]: get_irc_data thread[1] started
Oct 27 17:56:44 raspberrypi qngateway[60335]: IRCDDBApp: state=3 tableID=0
Oct 27 17:56:44 raspberrypi qngateway[60335]: IRCDDBApp: state=3 tableID=0
Oct 27 17:56:46 raspberrypi qngateway[60335]: Finding Routes for...
Oct 27 17:56:46 raspberrypi qngateway[60335]: Finding Routes for...
Oct 27 17:56:47 raspberrypi qngateway[60335]: Successfully connected to rotate.aprs2.net at [2607:f130:0:154::6d58:458e]:14580
[...]
Oct 27 18:00:50 raspberrypi qngateway[60335]: Update GATE: HS2XQB G --> 49.0.92.5
Oct 27 18:00:50 raspberrypi qngateway[60335]: Update GATE: E25DQY G --> 49.0.92.5
Oct 27 18:00:51 raspberrypi qngateway[60335]: Could not find last heard repeater for user 'KK7KSE '
Oct 27 18:00:51 raspberrypi qngateway[60335]: Could not find last heard repeater for user 'KK7KSE '
Oct 27 18:00:51 raspberrypi qngateway[60335]: User [KK7KSE ] not in local cache, try again
Oct 27 18:00:51 raspberrypi qngateway[60335]: User [KK7KSE ] not in local cache, try again
Oct 27 18:00:52 raspberrypi qngateway[60335]: Update USER: KK7KSE --> KR4CHS C at 2024-09-28 18:19:27
Oct 27 18:00:53 raspberrypi qngateway[60335]: Update GATE: KB3FSN G --> 141.158.43.216
Oct 27 18:01:03 raspberrypi qngateway[60335]: Update GATE: KA9VXS G --> 195.252.199.7
Oct 27 18:01:03 raspberrypi qngateway[60335]: Could not find last heard repeater for user 'KK7KSE '
Oct 27 18:01:03 raspberrypi qngateway[60335]: ERROR using IRC[1]: IP returned from cache, 166.159.13.254, is IPV4 but family is AF_INET6!
Oct 27 18:01:03 raspberrypi qngateway[60335]: Address Initialization Error: '166.159.13.254' is not a valid IPV6 address!
Oct 27 18:01:03 raspberrypi qngateway[60335]: Callsign route to [::]:9011 id=2f65 my=KK7DVF /HT ur=KK7KSE rpt1=KR4CHS C rpt2=KR4CHS G
Oct 27 18:01:04 raspberrypi qngateway[60335]: Update USER: KK7DVF --> KK7DVF B at 2024-10-27 23:01:04
@n7tae
Copy link
Owner

n7tae commented Oct 28, 2024

The first log entry at 17:56:32 says it all: You are connecting to ircv4.openquad.net using it's IPv6 address. I think that means your QnetGateway system has no access to IPv4. Until you fix that, you should run IPv6 only, not dual stack, and you will be very limited in what you can route to. You can try to force IPv4 by using 167.71.182.245 instead of ircv4.openquad.net in your config file, but I suspect it won't work.

@n7tae n7tae mentioned this issue Oct 28, 2024
Closed
@shithubsucks
Copy link
Author

shithubsucks commented Oct 28, 2024 •
edited
Loading

ircv4.openquad.net has no IPv6 address. What's happening is the domain resolver is inferring a IPv6 address for it because QNetGateway asked it for a AAAA record, rather then an A record. The resolver implements a IPv6 transition technology called DNS64 (RFC 6147) https://datatracker.ietf.org/doc/html/rfc6147 which encapsulates IPv4 addresses inside a reserved IPv6 address to the NAT64 router (RFC 6156). https://datatracker.ietf.org/doc/html/rfc6146

as you can see here, this is indeed what is happening:
root@raspberrypi:~/QnetGateway# netstat -tn Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp6 0 0 2001:470:3833:1:ba27:22 2001:470:3833:1:d:38230 ESTABLISHED tcp6 0 0 fe80::ba27:ebff:feda:22 fe80::2c0:caff:fe:47814 ESTABLISHED tcp6 0 0 2600:3c00:e004:b0:50468 2604:a880:800:c1:::9007 ESTABLISHED tcp6 0 0 2001:470:3833:1:ba27:22 2001:470:3833:1:d:42970 ESTABLISHED tcp6 0 0 2600:3c00:e004:b0:54420 2607:f130:0:154:::14580 ESTABLISHED tcp6 0 0 2600:3c00:e004:b0:60776 64:ff9b::a747:b6f5:9007 ESTABLISHED root@raspberrypi:~/QnetGateway#

QNetgateway seems to get confused with nat64 addresses. This particular host does have dualstack connectivity, but if there is a way to use nat64/464 XLAT/ CLAT / SIIT-DC to provide ipv4 reach-ability or a reverse proxy on the router keeping the internal network completely ipv6 pure that would be preffered.

Is there any way to tell qnetgateway to only query an A record instead of a AAAA for ircv4.openquad.net? I could set a IP address there but any time openquad change's their IP it's going to require manual intervention, and it still doesn't account for if I were to put 64:ff9b::167.71.182.245 in there.

@shithubsucks
Copy link
Author

shithubsucks commented Oct 28, 2024 •
edited
Loading

after changing hb ircv4.openquad.net -> 167.71.182.245 the repeater is able to make outgoing callsign routes to IPv4-only repeaters, but activity heard on the repeater is still not showing up on https://www.openquad.net/last.php or https://www.openquad.net/lastv6.php and does not appear to be reported on the IRC server.

@shithubsucks
Copy link
Author

screenshot_140

@n7tae
Copy link
Owner

n7tae commented Oct 28, 2024

In the dev branch of the repo, the irc TCP open() now passes a proper family hint to getaddrinfo() instead of AF_UNSPEC. I don't know if this will help you or not.

@shithubsucks
Copy link
Author

I'll have to git fetch and recompile with the new changes. Please allow me some time to do that. I'm also in the process of switching internet service providers.

@shithubsucks
Copy link
Author

I reset the irc B server back to ircv4.openquad.net and tested:

Oct 28 18:48:14 raspberrypi qngateway[1635]: Could not find last heard repeater for user 'KK7KSE '
Oct 28 18:48:14 raspberrypi qngateway[1635]: Could not find last heard repeater for user 'KK7KSE '
Oct 28 18:48:14 raspberrypi qngateway[1635]: User [KK7KSE ] not in local cache, try again
Oct 28 18:48:14 raspberrypi qngateway[1635]: User [KK7KSE ] not in local cache, try again
Oct 28 18:48:15 raspberrypi qngateway[1635]: Update USER: KK7KSE --> KR4CHS C at 2024-09-28 18:19:27
Oct 28 18:48:19 raspberrypi qngateway[1635]: Update GATE: DS5YDY G --> 106.101.137.81
Oct 28 18:48:20 raspberrypi qngateway[1635]: Could not find last heard repeater for user 'KK7KSE '
Oct 28 18:48:20 raspberrypi qngateway[1635]: Callsign route to [166.159.13.254]:40000 id=b4dd my=KK7DVF /HT ur=KK7KSE rpt1=KR4CHS C rpt2=KR4CHS G
Oct 28 18:48:20 raspberrypi qngateway[1635]: Update GATE: IR2CT G --> 84.55.208.74
Oct 28 18:48:21 raspberrypi qngateway[1635]: Update USER: KK7DVF --> KK7DVF B at 2024-10-28 23:48:20
Oct 28 18:48:27 raspberrypi qngateway[1635]: Update GATE: WG3K G --> 69.143.212.192
Oct 28 18:48:29 raspberrypi qngateway[1635]: Update GATE: LA4YGA G --> 85.166.11.234
Oct 28 18:48:29 raspberrypi qngateway[1635]: Could not find last heard repeater for user 'KK7KSE '
Oct 28 18:48:29 raspberrypi qngateway[1635]: Callsign route to [166.159.13.254]:40000 id=80d2 my=KK7DVF /HT ur=KK7KSE rpt1=KR4CHS C rpt2=KR4CHS G
Oct 28 18:48:30 raspberrypi qngateway[1635]: Update USER: KK7DVF --> KK7DVF B at 2024-10-28 23:48:29

it appears to be connecting without using nat64 now
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp ESTAB 0 0 192.168.55.20:59028 167.71.182.245:9007 users:(("qngateway",pid=1635,fd=7))
tcp ESTAB 0 0 [2600:3c00:e004:b001:ba27:ebff:feda:817d]:44796 [2604:a880:800:c1::14e:c001]:9007 users:(("qngateway",pid=1635,fd=8))
tcp ESTAB 0 0 [2600:3c00:e004:b001:ba27:ebff:feda:817d]:42344 [2607:f130:0:154::6d58:458e]:14580 users:(("qngateway",pid=1635,fd=11))

@shithubsucks
Copy link
Author

Unfortunately, QnetGateway still does not appear to be updating Openquad's livelog or livelogv6 pages.

@w1bsb
Copy link
Collaborator

w1bsb commented Oct 28, 2024 •
edited
Loading

Yes, it is:
024-10-28 23:49:17 1.60s: 0%: 0.0% DF6DX___/9700 XLX021GL DF6DX__B DF6DX__G Michael_/Bergach__ ________

2024-10-28 23:48:47 0.84s: 0%: 0.0% N9NMH___/MATT CQCQCQ__ N9QWR__B N9QWR__G REF019_B

2024-10-28 23:48:29 0.70s: 2%: 0.0% KK7DVF__/HT__ KK7KSE__ KK7DVF_B KK7DVF_G THOMAS______________ KR4CHS_C

2024-10-28 23:48:20 0.70s: 2%: 0.0% KK7DVF__/HT__ KK7KSE__ KK7DVF_B KK7DVF_G THOMAS______________ KR4CHS_C

v6 only gets updated if its a route to a system/user/repeater that is on IPv6 (in other words, QuadNet will prefer ipv6 if it is configured on the repeater/hotspot/user you're trying to route to, otherwise, it goes v4). v6 only logs stuff going through ipv6.

If you want to see ipv6 lastheard traffic, route to something using ipv6 like one of the smart groups.

@shithubsucks
Copy link
Author

I believe those lastheard updates are coming from KR4CHS_C, not KK7DVF_B from when I callsign routed to KK7KSE. When Not callsign routing to other repeaters, such as when UR is set to CQCQCQ I don't see updates in openquad's livelog.

@w1bsb
Copy link
Collaborator

w1bsb commented Oct 29, 2024

What is KR4CHS? You are somewhat correct in your last statement. Link your hotspot to a d-star reflector and key up with CQCQCQ and you should see it in the lastheard log. There is some logic in the lastheard reporting so that we don't have 2 systems reporting the same information and cluttering up the lastheard log.

@w1bsb
Copy link
Collaborator

w1bsb commented Oct 29, 2024

I do believe there is a fundamental difference between CQCQCQ types as well. In ICOM, I use the prebuilt/predefined Use Reflector (CQCQCQ), and it always shows up.

@shithubsucks
Copy link
Author

shithubsucks commented Oct 29, 2024 •
edited
Loading

What is KR4CHS?

KR4CHS is the remote repeater the remote USER KK7KSE was last heard on located in USA, South Carolina.

You are somewhat correct in your last statement. Link your hotspot to a d-star reflector and key up with CQCQCQ and you should see it in the lastheard log.

I did. KK7DVF_B is currently linked to REF035_A and I keyed up with UR=CQCQCQ but openquad's lastheard was not updated.

@w1bsb
Copy link
Collaborator

w1bsb commented Oct 29, 2024

The dashboard for REF035 doesn't show you connected, or on the lastheard. Are you sure its actually linked there?

@shithubsucks
Copy link
Author

shithubsucks commented Oct 29, 2024 •
edited
Loading

I'm sorry, I mean REF059A, and yes I just finished a QSO on there.

@w1bsb
Copy link
Collaborator

w1bsb commented Oct 29, 2024

I will have to defer to n7tae on the lastheard stuff. It should be in there. I see some transmissions from you, but nothing when you were linked to ref059. And its been forever since I played with d-star. All I can say with certainty is the log is being updated live so I'm not sure why it isn't popping up from your system.

@shithubsucks
Copy link
Author

shithubsucks commented Oct 29, 2024 •
edited
Loading

Yeah, I know the lastheard livelog was indeed working when I was using mmdvmhost as the repeater controller software instead of qnetgateway so it must be something different with qnetgateway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@n7tae @w1bsb @shithubsucks