[SOLVED] Synapse: How to communicate with *.local machine on *nix.

[tk]

I have a problem using the Synapse library on *nix systems (Linux, MAC).
The following code works on Windows but does not on *nix:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. var
3.   sock: TUDPBlockSocket;
4. begin
5.   sock := TUDPBlockSocket.Create;
6.   try
7.     sock.Connect('mypc.local', '1000');
8.     sock.SendByte(0);
9.     sock.CloseSocket;
10.   finally
11.     sock.Free;
12.   end;
13. end;

Synapse calls Winsock.GetAddrInfo on Windows which works and returns correct IP.
But it calls netdb's ResolveName on *nix, which directly implements DNS protocol and does not work (cannot work by design).

[rvk]

But it calls netdb's ResolveName on *nix, which directly implements DNS protocol and does not work (cannot work by design).

and netdb resolvename only checks the DNS servers listed in /etc/resolv.conf.

https://wiki.freepascal.org/Netdb

So you have a DNS server in resolv.conf which doesn't resolve mypc.local ???
Why does that server not resolve your mypc hostname?

[TRon]

Note that ports < 1024 are 'protected' so unless you are running as root (or have another provision in place that allows you).

[rvk]

Note that ports < 1024 are 'protected' so unless you are running as root (or have another provision in place that allows you).

+1 Haha. Good one for spotting that 

[tk]

So you have a DNS server in resolv.conf which doesn't resolve mypc.local ???
Why does that server not resolve your mypc hostname?

$ nslookup mypc.local reports error on all systems.
$ ping mypc.local works on all systems.

https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfo
The getaddrinfo function provides protocol-independent translation from an ANSI host name to an address.
The problem on *nix is that Synapse uses DNS protocol by default which is incorrect.

Note that ports < 1024 are 'protected' so unless you are running as root (or have another provision in place that allows you).

Sorry just mistyped in this sample. Not the cause of this problem (in my program I use dynamic ports in the range 49152–65535, eg. 50000).

[cdbc]

Hi
Sorry, but what's wrong with 'localhost'?!?
Regards Benny

[tk]

Sorry, but what's wrong with 'localhost'?!?

Does not solve this problem and also in my case 'mypc.local' <> 'localhost', is another device on LAN.

[rvk]

Synapse calls Winsock.GetAddrInfo on Windows which works and returns correct IP.
But it calls netdb's ResolveName on *nix, which directly implements DNS protocol and does not work (cannot work by design).

What version of Synapse are you using?
I think the *nix version in Synapse 40.1 also uses getaddrinfo (at least... if you haven't defined FORCEOLDAPI).

BTW. for me nslookup hostname_local_machine works fine on Linux for my internal systems.
So you are using a DNS which doesn't resolve internal systems correctly.
That does work most of the time but isn't ideal.

Edit: Using sock.Connect('local_machine_hostname', 'open_port'); also works on a Linux testmachine here.
Edit #2: Only works for clients which correctly registers itself to the local DNS server (and only if you use that local DNS server in resolv.conf).

BTW. Did you try without the .local after the name. Sometimes the resolver doesn't like the suffix in the query.

[tk]

What version of Synapse are you using?
I think the *nix version in Synapse 40.1 also uses getaddrinfo (at least... if you haven't defined FORCEOLDAPI).

I use Synapse 40 but there is no difference from Synapse 40.1 in this regard.
*nix version does not call getaddrinfo.
No such code can be found in ssfpc.inc which is used when compiling with FPC.
I can see it in sslinux.inc but this is not compiled with FPC (I assume this was originally a Kylix code?).

BTW. for me nslookup hostname_local_machine works fine on Linux for my internal systems.
So you are using a DNS which doesn't resolve internal systems correctly.
That does work most of the time but isn't ideal.

Edit: Using sock.Connect('local_machine_hostname', 'open_port'); also works on a Linux testmachine here.
Edit #2: Only works for clients which correctly registers itself to the local DNS server (and only if you use that local DNS server in resolv.conf).

BTW. Did you try without the .local after the name. Sometimes the resolver doesn't like the suffix in the query.

I must use 'devicename.local'. It is a recommended way to address the device I need to communicate with.
As said, ping works on all systems, web access as well (http://devicename.local put into browser works fine).
I'm not familiar with what protocols are (or can be) used to determine this IP but it is definitely not the DNS protocol.
In Wireshark on Windows I can see a Netbios Name Query and also a MDNS call.

[rvk]

I see in synsock.pas that Synpase uses a separate ssfpc.inc instead of the sslinux.inc it uses for Delphi.

In that ssfpc.inc there is no implementation for the newer resolve methods (as used in the Delphi version).

But this might be a matter for Synapse unless you use the build in FPC socket procedures.

Ha, yes. You already found the problem...

The ssfpc.inc doesn't implement this new method so you could ask for a feature request in the Synapse github for this.
Or resolve the address yourself before connecting.

[tk]

Feature request: https://github.com/geby/synapse/issues/14

[rvk]

$ nslookup mypc.local reports error on all systems.
$ ping mypc.local works on all systems.

BTW. I'm still puzzled by this.

If your mypc.local isn't in the (local) DNS server, I'm not sure how Linux gets its hostname.

I can understand if Windows does it differently but for me pinging an unknown hostname for my local DNS server doesn't work in Linux.

(It does on Windows. But not on Linux.)

[tk]

If your mypc.local isn't in the (local) DNS server, I'm not sure how Linux gets its hostname.
I can understand if Windows does it differently but for me pinging an unknown hostname for my local DNS server doesn't work in Linux.
(It does on Windows. But not on Linux.)

There is no local DNS server at all.
When it comes to the ping command, then it runs via those other naming protocols on Linux and MAC as well.
I'll check the behavior with Wireshark later when I'm back at those machines.

[Alexx2000]

I faced the same problem, my solution.

[tk]

I faced the same problem, my solution.

Yep, this your fix works like a charm! Thank you!