HAP AC Lite keeps unadvertising services despite them being up

[edkraus]

Hello ... this is being discussed on arednmesh.org forum

https://www.arednmesh.org/content/hap-ac-lite-keeps-unadvertising-services-despite-them-being#comment-23407

For me, a HAP continues to advertise services on a Linux Mint machine running Filegator, Citadel, and a web server for some still photos ... stable.

I Added another computer running Windows 10 so I can add Winlink to my local node. It runs for a while then the node un advertises the service. If I go back to the admin advertised services page and re save ... it's back. The services never went away, just the link. The computer is pingable (by me on my LAN).

I don't know what files you might need so let me know.

Ed

[aanon4]

As a starting point, can you post the node name so I can take a look? Thanks.

[edkraus]

Hi Tim!

K7EOK-HAP-ACCESS let me know if there is any download you need.  the node currently is NOT advertising.  I can download a file then toggle it and do it again so you can compare the state The Winlink Post Office resides at 10.176.146.68 which has host name EOKW10

Thanks,Ed

On Monday, May 27, 2024 at 02:17:30 PM PDT, Tim Wilkinson ***@***.***> wrote:  

As a starting point, can you post the node name so I can take a look? Thanks.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[aanon4]

Could you attached the support tool data? thanks.

[edkraus]

here on email or back at the github?  I haven't looked at the github since posting

On Monday, May 27, 2024 at 03:13:57 PM PDT, Tim Wilkinson ***@***.***> wrote:  

Could you attached the support tool data? thanks.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[aanon4]

I can ping K7EOK-HAP-ACCESS but I cannot ping 10.176.146.68.

[aanon4]

Attach it on github if you could.

[edkraus]

both the ip and the hostname ping from my machine (on same lan)

On Monday, May 27, 2024 at 03:17:49 PM PDT, Tim Wilkinson ***@***.***> wrote:  

I can ping K7EOK-HAP-ACCESS but I cannot ping 10.176.146.68.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[edkraus]

supportdata-K7EOK-HAP-ACCESS-202405272216.tar.gz

Weird, I though I was attaching a file. Am I missing how to attach the file or did it go through?

[edkraus]

I can restore the advertising by clicking "Save Changes" even though no changes are made, and regenerate the support data. Yes?

[aanon4]

That does is remove the advertising block for a few hours. Another test - can someone not on your local LAN ping the address successfully?

[aanon4]

I can telnet to your winlink server, but I cannot ping the address. The node needs to be able to ping the address to verify the device is available. As this is a windows box you might need to adjust its firewall settings.

[edkraus]

already did that but perhaps not correctly

On Monday, May 27, 2024 at 03:57:52 PM PDT, Tim Wilkinson ***@***.***> wrote:  

I can telnet to your winlink server, but I cannot ping the address. The node needs to be able to ping the address to verify the device is available. As this is a windows box you might need to adjust its firewall settings.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[edkraus]

I changed Inbound Rules for File and Printer Sharing (Echo Request) for IPv4 to Yes for Public and Private

On Monday, May 27, 2024 at 04:01:04 PM PDT, Ed Kraus ***@***.***> wrote:  

already did that but perhaps not correctly

On Monday, May 27, 2024 at 03:57:52 PM PDT, Tim Wilkinson ***@***.***> wrote:  

I can telnet to your winlink server, but I cannot ping the address. The node needs to be able to ping the address to verify the device is available. As this is a windows box you might need to adjust its firewall settings.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[aanon4]

I think the problem is that you set the winlink server's protocol to http and it's very much not that. Setting it to winlink is the way to go.

[edkraus]

please explain

On Monday, May 27, 2024 at 04:11:10 PM PDT, Tim Wilkinson ***@***.***> wrote:  

I think the problem is that you set the winlink server's protocol to http and it's very much not that. Setting it to 'winlink' is the way to go.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[aanon4]

If you setup a service with the protocol http (or https) then we check that the service actually response correctly to http requests (which is a very specific protocol). Winlink is not an http protocol (technically it's telnet, but that's pretty raw) and so will not response to the nodes validation request correctly. If the protocol is not http(s) then we just verify a simple connection is supported.

Why this sort of checking? Because we want people clicking on links marked as http to work correctly in their web browser so they have a good user experience. Winlink marked as http will not do that.

[edkraus]

OK ... that's why.  I'm asking how. Do you mean to replace the http in the link with winlink?

On Monday, May 27, 2024 at 04:21:04 PM PDT, Tim Wilkinson ***@***.***> wrote:  

If you setup a service with the protocol http (or https) then we check that the service actually response correctly to http requests (which is a very specific protocol). Winlink is not an http protocol (technically it's telnet, but that a pretty raw protocol) and so will not response to the nodes validation request correctly. If the protocol is not http(s) then we just verify a simple connection is supported.

Why this sort of checking? Because we want people clicking on links marked as http to work correctly in their web browser so they have a good user experience. Winlink marked as http will not do that.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[aanon4]

Oh. Yes - when setting up the service, in the box you had typed "http" in, instead type "winlink".

[edkraus]

OK.  I'll try that and then see what happens ... and report back.  Thanks!

On Monday, May 27, 2024 at 04:37:39 PM PDT, Tim Wilkinson ***@***.***> wrote:  

Oh. Yes - when setting up the service, in the box you had typed "http" in, instead type "winlink".

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[edkraus]

change made ... will look in a few hours (only 5pm here) Several questions 1  Does the de-advertising of services that will not answer a ping only apply to http?  Winlink worked fine with the previous firewall rules, the only thing was it wouldn't show up in the AREDN Mesh Node list so users would not be able to find it.  Does this mean I could have left the firewall alone? 2    If I were to offer other services like file server, web server on the windows computer, do I still have to change the firewall rules or AREDN will unlink them if they won't ping? 3    We still haven't solved if my firewall was ok to folks on the local mesh rather than you on the supernode.  I'll get that info later.  Actually, I'll get it myself tomorrow from work as I'll connect with a travel node from there.

Ed

On Monday, May 27, 2024 at 04:55:12 PM PDT, Ed Kraus @.***> wrote:

OK.  I'll try that and then see what happens ... and report back.  Thanks!

On Monday, May 27, 2024 at 04:37:39 PM PDT, Tim Wilkinson ***@***.***> wrote:  

Oh. Yes - when setting up the service, in the box you had typed "http" in, instead type "winlink".

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ab7pa]

From a documentation standpoint, these are the cases when services will be unadvertised:

@aanon4 Tim, let me know if this needs to be expanded to include other details.

[edkraus]

so it could have been case 3 only all along?

On Monday, May 27, 2024 at 05:09:53 PM PDT, Steve ***@***.***> wrote:  

From a documentation standpoint, these are the cases when services will be unadvertised: Screenshot.2024-05-27.at.5.07.12.PM.png (view on web) @aanon4 Tim, let me know if this needs to be expanded to include other details.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[AJ6GZ]

The Winlink program needs a full URL to be able to find, and correctly, populate its server list.

Mine is: winlink://AJ6GZ-1-winlink.local.mesh:8772/

So the values are: Name: Winlink Post Office (The program searches for winlink and/or post office) Link: [X] Checked URL: winlink host AJ6GZ-1-winlink Port 8772 Nothing after the trailing ' / '

Yes 'winlink' is a bogus uri, but like Tim said we don't want people clicking on http, telnet, ftp, etc or any of the other things that back in the day would launch external programs in browsers. But you must have some sort of "link" for Winlink to populate hostname and port# correctly. Otherwise, you'll see it in the list, can add server, but it will fail to work right.

I also allow pings to this host.

You can test by telnet/ssh'ing to your node or better someone else's node further away, then 1) ping the host, preferably by hostname. 2) 'telnet hostname 8772' and see if you get "callsign:" in return. Or whatever your port # is.

If these are true, the service checker and users should be happy.

Re:

" Winlink worked fine with the previous firewall rules, the only thing was it wouldn't show up in the AREDN Mesh Node list so users would not be able to find it. "

[edkraus]

Well, the change from http to winlink seems to have worked.  I'll test the ping stuff tomorrow. Thanks everyone, perhaps a comprehensive checklist for everything you have to do to combine AREDN and Winlink gateways would be good.  We have some instructions for RMS Express, but not as much for RMS Relay. Ed

On Monday, May 27, 2024 at 06:07:56 PM PDT, AJ6GZ ***@***.***> wrote:  

The Winlink program needs a full URL to be able to find, and correctly, populate its server list.

Mine is: winlink://AJ6GZ-1-winlink.local.mesh:8772/

So the values are: Name: Winlink Post Office (The program searches for winlink and/or post office) Link: [X] Checked URL: winlink host AJ6GZ-1-winlink Port 8772 Nothing after the trailing ' / '

Yes 'winlink' is a bogus uri, but like Tim said we don't want people clicking on http, telnet, ftp, etc or any of the other things that back in the day would launch external programs in browsers. But you must have some sort of "link" for Winlink to populate hostname and port# correctly. Otherwise, you'll see it in the list, can add server, but it will fail to work right.

I also allow pings to this host.

You can test by telnet/ssh'ing to your node or better someone else's node further away, then

• ping the host, preferably by hostname.
• 'telnet hostname 8772' and see if you get "callsign:" in return. Or whatever your port # is.

If these are true, the service checker and users should be happy.

Re:

" Winlink worked fine with the previous firewall rules, the only thing was it wouldn't show up in the AREDN Mesh Node list so users would not be able to find it. "

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[edkraus]

All working fine, but from another location I cannot ping the server.  Weird.

On Monday, May 27, 2024 at 10:18:53 PM PDT, Ed Kraus ***@***.***> wrote:  

Well, the change from http to winlink seems to have worked.  I'll test the ping stuff tomorrow. Thanks everyone, perhaps a comprehensive checklist for everything you have to do to combine AREDN and Winlink gateways would be good.  We have some instructions for RMS Express, but not as much for RMS Relay. Ed

On Monday, May 27, 2024 at 06:07:56 PM PDT, AJ6GZ ***@***.***> wrote:  

The Winlink program needs a full URL to be able to find, and correctly, populate its server list.

Mine is: winlink://AJ6GZ-1-winlink.local.mesh:8772/

So the values are: Name: Winlink Post Office (The program searches for winlink and/or post office) Link: [X] Checked URL: winlink host AJ6GZ-1-winlink Port 8772 Nothing after the trailing ' / '

Yes 'winlink' is a bogus uri, but like Tim said we don't want people clicking on http, telnet, ftp, etc or any of the other things that back in the day would launch external programs in browsers. But you must have some sort of "link" for Winlink to populate hostname and port# correctly. Otherwise, you'll see it in the list, can add server, but it will fail to work right.

I also allow pings to this host.

You can test by telnet/ssh'ing to your node or better someone else's node further away, then

• ping the host, preferably by hostname.
• 'telnet hostname 8772' and see if you get "callsign:" in return. Or whatever your port # is.

If these are true, the service checker and users should be happy.

Re:

" Winlink worked fine with the previous firewall rules, the only thing was it wouldn't show up in the AREDN Mesh Node list so users would not be able to find it. "

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>