#338 Incorrect port 0 for IPv6 socket on Windows

[Stefan Becker]

Triggered by discussion [c759af31]: first SIP message using IPv6 address is rejected with error 504 by the server. The log shows an error message when SIPE tries to determine the local socket address:

(10:37:20) sipe: transport_connect - hostname: sipfed0B.online.lync.com port: 443
(10:37:20) sipe: using SSL
(10:37:20) dnsquery: Performing DNS lookup for sipfed0B.online.lync.com
(10:37:20) dnsquery: IP resolved for sipfed0B.online.lync.com
(10:37:20) proxy: Attempting connection to 2603:1037:0:2::b
...
(10:37:20) proxy: Connected to sipfed0B.online.lync.com:443.
...
(10:37:20) network: getsockname: Windows socket error #10014
(10:37:20) sipe: sip_transport_connected: sipfed0B.online.lync.com:443
...
(10:37:20) sipe: sipe_backend_transport_ip_address: 2601:602:ca80:3574:d109:5d9e:f239:c98e

This looks like a valid IPv6 address to me, but because of the error message I think it might be the wrong one. Looking at the code of sipe_backend_transport_ip_address() in src/purple/purple.c that would mean that despite the error message in the log getsockname() does return 0, i.e. no error.

Related links:

• Pidgin debug log provided by user
• Windows Sockets Error Codes - WSAEFAULT 10014 Bad address
• Pidgin ticket #17123 - probably unrelated to SIPE, but same root cause?
• Pidgin ticket #17156 - looks like the exact same issue reported by another SIPE user.
• Stackoverflow question about error #10014 - most likely the root cause and proposal how to change sipe_backend_transport_ip_address()
• Feature Request #99 - IPv6 support in SIP messages, included in SIPE 1.23.0

[Stefan Becker]

I've now been able to reproduce this on a Window 10 VM which I configured to use my IPv6 tunnel:

(12:20:39) sipe: transport_connect - hostname: sipfed2a.online.lync.com port: 443
(12:20:39) sipe: using SSL
(12:20:39) dnsquery: Performing DNS lookup for sipfed2a.online.lync.com
...
(12:20:39) dnsquery: IP resolved for sipfed2a.online.lync.com
(12:20:39) proxy: Attempting connection to 2603:1037:0:c::f
(12:20:39) proxy: Connecting to sipfed2a.online.lync.com:443 with no proxy
(12:20:39) proxy: Connection in progress
...
(12:20:39) proxy: Connecting to sipfed2a.online.lync.com:443.
(12:20:39) proxy: Connected to sipfed2a.online.lync.com:443.
...
(12:20:40) network: getsockname: Windows socket error #10014
(12:20:40) sipe: sip_transport_connected: sipfed2a.online.lync.com:443
...
(12:20:40) sipe: 
MESSAGE START >>>>>>>>>> SIP - 2018-02-10T10:20:40.167910Z
REGISTER sip:DOMAIN.COM SIP/2.0
Via: SIP/2.0/tls [2001:470:1f0a:298::2]:0;branch=z9hG4bK342830B2490023E2306F
...
User-Agent: UCCAPI/16.0.6001.1073 OC/16.0.6001.1073 (Skype for Business)
Call-ID: 78D6g2684a0D46i41A5m2E12t75DDb72A8x578Cx
Contact: <sip:[2001:470:1f0a:298::2]:0;transport=tls;ms-opaque=d3470f2e1d>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:3f90a5ed-1b93-5477-aed9-c17b4589037c>"
...
MESSAGE END >>>>>>>>>> SIP - 2018-02-10T10:20:40.167910Z
(12:20:40) sipe: transport_input_common: new buffer length 4096
(12:20:40) sipe: 
MESSAGE START <<<<<<<<<< SIP - 2018-02-10T10:20:40.480807Z
SIP/2.0 504 Server time-out
...
Via: SIP/2.0/tls [2001:470:1f0a:298::2]:0;branch=z9hG4bK342830B2490023E2306F

The IPv6 local address is correct, but the port number is 0 which is definitely incorrect. I should be able to debug this now.

[Stefan Becker]

I have been able to root cause the issue to a bug in Windows Pidgin. On Windows calling purple_network_get_port_from_fd() on an IPv6 socket always generates the error message network: getsockname: Windows socket error #10014 and then returns the default port 0. This incorrect port then leads to a 504 error from the SIP server.

As a workaround I have replaced the broken function with our own implementation, using the guidance from the above mentioned StackOverflow question, in git commit f49fd3d4.

I've provided an updated Windows DLL in the development area.

Closing as FIXED.

[Stefan Becker]

Forgot to use ntohs() when reading the port number from the data structure. It seems the SIP server doesn't really check the port number, but let's be correct on all systems and return the correct port number (git commit 1a15a1af).

Updated the Windows DLL too.

[Stefan Becker]

Now all places in purple backend that call getsockname() are updated (git commit d5915e68)

Updated the Windows DLL again.