bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45821: Emacs UDP support on Windows


From: Robert Pluim
Subject: bug#45821: Emacs UDP support on Windows
Date: Mon, 02 Jan 2023 11:22:03 +0100

>>>>> On Mon, 2 Jan 2023 00:47:12 +0000, Alex Matei <matei.alexandru@live.com> 
>>>>> said:

    Alex> Updates on the UDP patch behavior:
    Alex>   *   I got confused during my validation by 2 things:
    Alex>      *   ‘dns-query’ works even without your patch changes
    Alex>   => it is not a good test ❌

`dns-query' by default uses TCP on MS-Windows when thereʼs no UDP
support. You can use it, but youʼd have to either instrument it or
check your network traffic using wireshark or similar.

    Alex>         *   One test that worked for me was using 
‘(make-network-process :name "udp-socket1" :remote '[127 0 0 1 1500] :type 
'datagram)’
    Alex>            *   If returns ‘(error "Unsupported connection type")’ if 
UDP is disabled ❌ , or the process if UDP is allowed✅

(featurep 'make-network-process '(:type datagram)) is the canonical
way to check that. And it only proves you can create UDP sockets, not
that they work 😉

    Alex>      *   The original patch doesn’t include the #define for 
‘WORKING_SELECT_EMULATION’, and I had to manually add this define to my emacs 
build (via 'CFLAGS= -O0 -g3 -DWORKING_SELECT_EMULATION' )
    Alex>         *   That’s why I got confused about the patch working 
initially , since my assumption was that if ‘dns-query’ works => UDP works as 
expected😉and I didn’t even consider that I was required to set up some more 
flags..

    Alex> ❌ Indeed, TLS is broken -> Eww to 
https://www.gnu.org<https://www.gnu.org/> fails to load the page ( see attached 
image – Emacs instance on the left, compiled with UDP patch, didn’t load 
gnu.org while on the right side- default Emacs build for 28.1 opens it without 
any issues)

Yep. Last time I looked at this, the TLS handshaking fails to complete
(see src/process.c around line 5329 and the checking against
GNUTLS_EMACS_HANDSHAKES_LIMIT) which means weʼre continually retrying
the handshake without giving the remote end a chance to send us
anything. Which I think means that our state machine for TLS
negotiation is subtly incorrect, but only on MS-Windows.

Robert
-- 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]