Commented by: @hvlad

Should be fixed now

Commented by: Marcio Reis (mreis1)

Awesome. Thank you Vlad.
I'll need to wait for version 3.0.4 to try it, right?

Commented by: @hvlad

Unfortunately, we have no snapshot builds for MacOS, so you have to wait for the next official release of 3.0.4
for MacOS (it could be RC or final release), or to build it yourself, sorry

Commented by: @hvlad

Could you test with both client and server version 3.0.4 ?

Commented by: Marcio Reis (mreis1)

Server (Windows 10) has firebird 3.0.4 installed.
The same applies to my client (Mac OS 10.13.6) .

If there are any additional tests I can perform to help detecting the cause of this issue, please let me know.

Commented by: @hvlad

Any messages in firebird.log ? Check at both sides - client and server.

Commented by: Marcio Reis (mreis1)

Just checked both, server and clients logs and there's nothing on them.
But I get the error when the app runs:

"While isc_que_events - Unable to complete network request to host "192.168.0.195".
Failed to establish a secondary connection for event processing.
Can't assign requested address"

Commented by: Sean Leyne (seanleyne)

Marcio,

The error suggests that your latest problem could be MacOS internal firewall settings? (Event processing uses a different TCP port from the database connection)

Commented by: Marcio Reis (mreis1)

Both server and client are running with no firewalls on. Same for antivirus.
UAC and other restrictions are also disabled.

Commented by: Marcio Reis (mreis1)

Hello guys, is there any news on in issue?
Developing on mac is a pain since I can't attach db events. :(

Commented by: @hvlad

I'm afraid i can do nothing - i have no Mac to build and debug Firebird and you can't build Firebird (on Mac) by yourself to try some tracing...

Commented by: @asfernandes

Accordingly to https://gist.github.com/cyberroadie/3490843, MacOS definition for sockaddr is:
struct sockaddr {
__uint8_t sa_len; /* total length */
sa_family_t sa_family; /* [XSI] address family */
char sa_data[14]; /* [XSI] addr value (actually larger) */
};

And in Linux https://github.com/torvalds/linux/blob/master/include/linux/socket.h and probably the same in Windows as they work with each other:
struct sockaddr {
sa_family_t sa_family; /* address family, AF_xxx */
char sa_data[14]; /* 14 bytes of protocol address */
};

Of course this cause errors when MacOS client/server is different than server/client and we use sa_data struct to transfer the address from server to client.
union sa_data {
struct sockaddr sock;
struct sockaddr_in inet;
struct sockaddr_in6 inet6;
} data;

I believe the server should send to client only the port number and the client should use the same original address information (more the port) to reconnect to server. Opinions?

Commented by: @hvlad

Server send full address (family, port and IP address) to the client so the client behind the NAT could know real IP of server endpoint.

Probably, client should analyze length of server response to distinguish MacOS from Windows\Linux ?

Commented by: @asfernandes

> Server send full address (family, port and IP address) to the client so the client behind the NAT could know real IP of server endpoint.

IMO this causes more issues than benefits. If server is behind NAT, it probably can't listen directly to client.

To locate the server the client should use the same host/address originally used for the main connection, and of course the NAT should redirect to the same machine.

Commented by: @hvlad

Hmm, it seems it is even worse:

MacOS:

#⁠ifndef _SA_FAMILY_T
#⁠define _SA_FAMILY_T
typedef __uint8_t sa_family_t;
#⁠endif

...
struct sockaddr {
__uint8_t sa_len; /* total length */
sa_family_t sa_family; /* [XSI] address family */
char sa_data[14]; /* [XSI] addr value (actually larger) */
};

Windows:

typedef USHORT ADDRESS_FAMILY;

typedef struct sockaddr {

#⁠if (_WIN32_WINNT < 0x0600)
u_short sa_family;
#⁠else
ADDRESS_FAMILY sa_family; // Address family.
#⁠endif //(_WIN32_WINNT < 0x0600)

CHAR sa\_data\[14\];                   // Up to 14 bytes of direct address\.

} SOCKADDR, *PSOCKADDR, FAR *LPSOCKADDR;

I.e. sizeof(sockaddr) will be equal on MacOS and Windows, but MacOS keep family value at second byte, while Windows - at first one

Commented by: @hvlad

> If server is behind NAT, it probably can't listen directly to client.
Server alread accept database attachment from client, so - it can listen ;)

> To locate the server the client should use the same host/address originally used for the main connection, and of course the NAT should redirect to the same machine.
Probably it will work, I just try to remember why things works this way for a many years already.
Probably there is another reason.

If send port only - how do you offer to preserve compatibility of old (new) client with new (old) server ?

Commented by: @asfernandes

For compatibility, we should anyway decode sockaddr knowing it could be from a different OS.

> Server alread accept database attachment from client, so - it can listen ;)

No, in case of NAT, it will be redirected from the public IP to the private one. The private one could not listen directly.

It's the same as used in web. Client (browser) should only use the public host while in most cases there is a load balancer redirecting to internal IPs.

The difference for Firebird is that there is not a load balancer redirecting to multiple IPs, but possibily to a single one.

I don't see any reason to try to use the address sent by the server.

Commented by: @hvlad

You right, client uses only port from server response (see aux_connect()).
But i still not see how do you going to preserve compatibility.

Commented by: @asfernandes

> But i still not see how do you going to preserve compatibility.

I'm preparing a pull request for review.

Commented by: @asfernandes

Márcio, please test this using the next Windows snapshot in the server. No need to update MacOS client.

Commented by: Marcio Reis (mreis1)

Adriano, I can confirm... latest windows snapshot fixes this issue! I'm so happy for this. Thank you :)