svxlink
svxlink copied to clipboard
sm0svx
svxlink-echolink won't connect to certain windows-stations
A few people asked me to reply the bug I've described in April 2012 https://sourceforge.net/p/svxlink/mailman/message/29137356/:
I am using svxlink ... and have some strange experiences when connecting some windows EL-stations (for instance 466564). It doesn't work for me with any of installations running Ubuntu, Debian, ... and does not work either with other svxlink-stations, for instance via DB0BLO-R [svx]. All windows-stations are able to accept connections by any other EL-Windows station. Maybe a problem with the echolink protocol?
What is the IP of the affected station? Maybe it is on HAMNET? There are issues with connecting German HAMNET Echolink stations due to the way their HAMNET is linked to Internet.
It is definitely not hamnet , it does not exist in Namibia : V51RS-R | NARL, Windhoek, Namibia | ON | 09:29 | 466564 This is one of several examples. I stopped collecting stations which doesn't work any more, but as far as I remember, I got one in Hong Kong, one in Trinidad Tobago .... all working with Echolink for Windows.
I use Hamnet by myself and know very well the problems by incoming stations beginning with 44.137.xxx IPs. Meanwhile, I have a workaround for these in my router.
Maybe it is behind CGNAT or some other firewall. In that case it would be able to make outgoing connects but not accept incoming connects. Firewall- and other networking issues are very common with Echolink. Are you sure you can connect if from Windows?
I am definitely sure. I made a lot of tests some years ago when that problem rises up. I switched between Linux and Windows hardware, Windows worked well and all connections could established between Windows-machines.
Hi All,
I still notice this when certain stations dial-in or out to F5ZGM-R. I suspect that this may be local security issues rather than anything to do with the standard protocols. Individual sysops set their individual protocols according to their own individual reasons. For example during my stays in the UK, I attempt to connect to my local repeater F5ZGM-R via the link provided by GB3IW, which simply fails to connect. I know that GB3IW is windows based, and F5ZGM-R is svxlink/Raspberry Pi/Raspbian Stretch based, but I can still connect from my own laptop directly which is windows based. When in France I can connect to GB3IW via F5ZGM-R.
All of no help whatsoever I know.
Regards
Chris F5VMR G4NAB
On 07/04/2018 20:03, DL 7 ATA wrote:
A few people asked me to reply the bug I've described in April 2012 https://sourceforge.net/p/svxlink/mailman/message/29137356/
: I am using svxlink ... and have some strange experiences when connecting some windows EL-stations (for instance 466564). It doesn't work for me with any of installations running Ubuntu, Debian, ... and does not work either with other svxlink-stations, for instance via DB0BLO-R [svx]. All windows-stations are able to accept connections by any other EL-Windows station. Maybe a problem with the echolink protocol?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/386, or mute the thread https://github.com/notifications/unsubscribe-auth/AICgdPW2uIwIOlImcwpjTW2hp89_47asks5tmP97gaJpZM4TLL5u.
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
The only way to know for sure is probably to log network traffic on both ends, and investigate. Access to one svxlink node and one windows echolink node needed. The compare the logs with a working connection, to see where it fails.
Sorry for reviving a not-so-old thread, but I'm experiencing the same problem.
In my region there are some local Echolink nodes, all running Windows XP on old PC (perhaps some on Windows 7), together connected with one or two of them that act as master nodes.
Using SvxLink (same problems using QTel) I can't connect to one of the master nodes, it simply tries to connect for a minute, than it goes DISCONNECTED, like a timeout has occurred.
No problems using official EchoLink client on Windows 7 (both on Win10 host or Win 7 VirtualBox VM).
I did some tests on different ISP, different modem/router and firewall, different OSs, both Win and Linux, and of course using a RaspberryPi, and no connection can be made to those two master nodes.
On Linux, I checked internet traffic with tcpdump on my client machine, and it seems that outgoing packets are generated correctly (I didn't inspected packet contents).
It's weird that if I ask them to connect to my nodes, since that moment I can connect and disconnect to their nodes without problems, at least until both of us keep the same public IP address (no modem shutdown or loosing connection). It make me thinking about NAT problems, or something network-related, but why official client works?
Except trying to analyze network traffic on both ends, can the problem be in some difference in EchoLink protocol implementation?
I have a faint memory that the Windows Echolink implementation use some kind of trick to poke a hole in the firewall automatically which SvxLink don't. That would explain why it works to connect from SvxLink after establishing a connection from Windows.
As @sm3sgp say, the only way to know is to study the network traffic at both ends to see what the Windows client do that SvxLink does not do.
Did anyone get to the bottom of this? I don't have access to the network traffic of the EL nodes that accept windows connections and reject Pi-based (In my case, Hamvoip) connections.
I think it is the configuration of each individual station, its IP address, and permissions given by the router. After struggling initially with installing SVXlink-EchoLink on GB3EV, it was by chance we determined the accessibility of the node to connect completely with the outside world, not withstanding the correct UDP ports. However despite inbound connections from all devices like the Windows App, Android App and EchoHam, it seems that subsequent connections after the first current connection seem unable to connect, despite permission granted for up to 10 QSO’s at a time. I’m at a loss as to why for the moment, as I am now working on the SvxReflector project of multiple connected node without the use of EchoLink. Best of luck - I cannot give you any definite answer.
Chris
On 30 Nov 2021, at 11:32, jbd3dmd @.***> wrote:
Did anyone get to the bottom of this? I don't have access to the network traffic of the EL nodes that accept windows connections and reject Pi-based (In my case, Hamvoip) connections.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Since then, I also tried different modem/routers (the official on provided by the ISP, different custom ones, even an old Linux PC with pppd and iptables rules), always the same problem. It looked like a problem not strictly related to SvxLink, but based on modems and Operating Systems.
@jbd3dmd Since then, a lot as changed. The owner of our link changed ISP, with a new VDSL modem provided by ISP, new audio interface, new radio and new RPi. Unfortunately (and luckily for us :smile:) the maintainers have moved to an official Conference, implemented with a dedicated server. We have no more connection problems.
Thanks so much for your observations. I have a windows machine and a Hamvoip Pi on the same network using the same call (mine) and I even swapped IP addresses so I know it isn't a port forwarding issue. My goofy workaround for now is to configure with proxy and then connect the Windows version of EL to the problematic nodes, put it in conference mode, and then connect my 2 nodes together. Given that I have tried all permutations of the same internal and external IP adresses and ports, I am really stumped. Someone earlier suggested that Windows EL somehow manages firewalls differently so maybe some illumination of that might be helpful? I appreciate your responses to my rekindling of this old thread.
At least make sure you have the most recent Windows software, after a long time of silence the Echolink author "recently" has released new versions with protocol fixes. When you have firewall issues, simply use a proxy. There are many proxies available nowadays (thanks to the proxy farm software I wrote, which allows to run hundreds of proxies on a small machine).
The windows version works fine. The Linux (Pi) is what fails on some but not even most nodes.