From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Vasilij Schneidermann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Apr 2023 10:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 62990@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.168207343618579 (code B ref -1); Fri, 21 Apr 2023 10:38:01 +0000 Received: (at submit) by debbugs.gnu.org; 21 Apr 2023 10:37:16 +0000 Received: from localhost ([127.0.0.1]:39434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppo8h-0004pb-J6 for submit@debbugs.gnu.org; Fri, 21 Apr 2023 06:37:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:34604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppo8g-0004pT-48 for submit@debbugs.gnu.org; Fri, 21 Apr 2023 06:37:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppo8f-0006kO-RK for bug-gnu-emacs@gnu.org; Fri, 21 Apr 2023 06:37:13 -0400 Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1ppo8a-00064h-Te for bug-gnu-emacs@gnu.org; Fri, 21 Apr 2023 06:37:13 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Q2rYf21Gpz9sTH for ; Fri, 21 Apr 2023 12:36:54 +0200 (CEST) Date: Fri, 21 Apr 2023 12:36:52 +0200 From: Vasilij Schneidermann Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/3sKrgmUpC55A0Fr" Content-Disposition: inline Received-SPF: pass client-ip=2001:67c:2050:0:465::101; envelope-from=mail@vasilij.de; helo=mout-p-101.mailbox.org X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --/3sKrgmUpC55A0Fr Content-Type: multipart/mixed; boundary="u2JkDqnouQE3X9SG" Content-Disposition: inline --u2JkDqnouQE3X9SG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm doing network programming with Emacs Lisp and one of the tasks was implementing a UDP server reading individual packets. I've found that when a client sends an empty packet, the server hangs up with a connection error and no longer accepts subsequent packets. This seems to be reasonable behavior for TCP (from what I understand, empty TCP messages are a sign of the connection being closed), but not for UDP. I've attached test programs written in Emacs Lisp and Guile to reproduce both correctly and incorrectly functioning servers and clients respectively. One minor nitpick is that sending an empty UDP packet from Emacs Lisp doesn't work either, but I'm unsure whether this is a bug (socat behaves similarly). In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.17.8) of 2023-04-15 built on odonien Repository revision: c60b59e04c3776a90adaa8c8fe53af3075a833b8 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101007 System Description: Arch Linux Configured using: 'configure 'CFLAGS=3D-g -ggdb -O0'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_MESSAGES:=20 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 36403 15371) (symbols 48 5177 0) (strings 32 13201 2082) (string-bytes 1 377158) (vectors 16 9346) (vector-slots 8 149422 15364) (floats 8 21 24) (intervals 56 212 0) (buffers 984 10)) --u2JkDqnouQE3X9SG Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="bug-client.el" ;; -*- lexical-binding: t; -*- (defun make-client () (make-network-process :name "bug-client" :type 'datagram :host "127.0.0.1" :service 10000 :family 'ipv4 :coding 'binary)) (defvar client (make-client)) (process-send-string client "hello") (process-send-string client "") (process-send-string client "world") (while t (accept-process-output nil 0.01)) --u2JkDqnouQE3X9SG Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="bug-server.el" ;; -*- lexical-binding: t; -*- (defun server-filter (process string) (message "Received string (%s): %S" (length string) string)) (defun server-sentinel (process event) (message "Received event: %S" event) (when (eq (process-status process) 'closed) (delete-process process) (kill-buffer (process-buffer process)))) (defun make-server () (make-network-process :name "bug-server" :type 'datagram :server t :host "127.0.0.1" :service 10000 :family 'ipv4 :coding 'binary :filter #'server-filter :sentinel #'server-sentinel)) (defvar server (make-server)) (while t (accept-process-output nil 0.01)) --u2JkDqnouQE3X9SG Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="fixed-client.scm" (import (rnrs bytevectors)) (define client (socket PF_INET SOCK_DGRAM 0)) (connect client AF_INET (inet-pton AF_INET "127.0.0.1") 10000) (send client (string->utf8 "hello")) (send client (string->utf8 "")) (send client (string->utf8 "world")) (close client) --u2JkDqnouQE3X9SG Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="fixed-server.scm" (use-modules (ice-9 format)) (import (rnrs bytevectors)) (import (rnrs bytevectors gnu)) (import (srfi 18)) (define server (socket PF_INET SOCK_DGRAM 0)) (bind server AF_INET (inet-pton AF_INET "127.0.0.1") 10000) (define buffer (make-u8vector 1024)) (let loop () (let* ((len (car (recvfrom! server buffer))) (message (utf8->string (bytevector-slice buffer 0 len)))) (format #t "Received string (~a): ~s~%" len message) (loop))) --u2JkDqnouQE3X9SG-- --/3sKrgmUpC55A0Fr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAmRCZ0EACgkQFmfJg6zC ifq0jwf/a+d4HHiISU09dTbZjcq9LOH2MG2UHnuwvaJoHo++pVOtrcl0AH2QhlBk HBypkckV+/Lg53bnKHNDI5/UpWI7aw9/teIewMBt5X0gVG4y36kghsaPaYrAOyk2 udYHL/xY+KBzX1vuotaItC+TY5cXt+sbVqxpanbi4HK5wZZEdKukTa/MOYNmHw2T t2rS1Co2LBGNlR9XXmZpv5qwPNgkDEXlGCl2WO1lBT/SOpfKZObE0+0egNwGmLJB rzPu6rGyTvFyDgeg3sZJKe+BvZ2pDmvZxH9BdXPT3j0nVrn5aSae0xz2Ei1If+tf D/S1xkZgREztiGuPWjUPuHvDBGfMxQ== =YQoQ -----END PGP SIGNATURE----- --/3sKrgmUpC55A0Fr-- From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Apr 2023 08:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vasilij Schneidermann Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168232627719363 (code B ref 62990); Mon, 24 Apr 2023 08:52:01 +0000 Received: (at 62990) by debbugs.gnu.org; 24 Apr 2023 08:51:17 +0000 Received: from localhost ([127.0.0.1]:47463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqrum-00052D-By for submit@debbugs.gnu.org; Mon, 24 Apr 2023 04:51:16 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:57733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqruk-00051N-47 for 62990@debbugs.gnu.org; Mon, 24 Apr 2023 04:51:14 -0400 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-2fa0ce30ac2so3774725f8f.3 for <62990@debbugs.gnu.org>; Mon, 24 Apr 2023 01:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682326268; x=1684918268; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=r4j7iKSK+9RNdJP6dJ4k4DUprwohLaazuaNUHD4mO3A=; b=mvwrAgg8hjchtda4k5D/qMYqfCQK/iinsSDkgtb4nZArT++MUUQce8M3fEmjelSl1E s0tU6WMXECVYf7EzoJpZPXyvcGz+2DSWiP0FE0p9KfqBVdtxMjKfRJWRIhe1NAAe2Gc4 gicQgxRZb7gtJWJzmssH61N8i2uqxDPGOCIYxNfi4Z81B2GPcaD292K/ilKu+Q6j4m22 UBi76XcHXXTIlOEDc+s1EghHOXbHZp/rxCw0S9ZfnPVEznQkFoLqt+Ki31D3aqiqWduQ 1ez4ZyNq4QKF/2gVepfSmkLMy7jt6hyaZmOW/jiX6CJxS3oUZYTfpqI/GXjvpCtl9JRg n53g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682326268; x=1684918268; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r4j7iKSK+9RNdJP6dJ4k4DUprwohLaazuaNUHD4mO3A=; b=BXf55ihcZiC6/DV61ksa2vvwFq5hYr48WNBmQLdKmYbSF/pB+uQYM+mAChF1p5ACyp PQYjuNdlnEjaMb9AM61tVdLoq2oR1sYsHEZ+hRuM4DPTa2tAuYRK/h5XerE/DB1uqG3a VH1u6SfhaXl55eyevpJE3/JmTEWxG/3k2maLzQ3tDF2xqo4zRsCNFXR7Z2TGDAct0TkU xxdcw/+gCVDbg2YSLNqRg+alDDBpeJrd3MnySZdRkz/hirF+ccSZXJP3c4sRruGwyyJq wBKNfobj3ya53GHLOg7VubTcPCZM0xiBWNWEavXM0Dbqo7/O5cRGiuJIQNkax1tmdAOO YQzg== X-Gm-Message-State: AAQBX9eIVmslnKzQZpyzC2Qywgcj+KRE2c1texZtQwLGi/0ThikYNgcs d92KOn596YuNjfAwnBauUq1XHul/ehM= X-Google-Smtp-Source: AKy350YoToM7ZTKz8yIByuXtXyw5J0L9FmWhmnYHB2VWSqEtNcY1B4sjhhpOjtWv+CNvyXH1DJNAJg== X-Received: by 2002:adf:cf0d:0:b0:2f1:e162:d48 with SMTP id o13-20020adfcf0d000000b002f1e1620d48mr8995491wrj.47.1682326267766; Mon, 24 Apr 2023 01:51:07 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id m10-20020a5d56ca000000b002c54c9bd71fsm10291434wrw.93.2023.04.24.01.51.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 01:51:07 -0700 (PDT) From: Robert Pluim In-Reply-To: (Vasilij Schneidermann's message of "Fri, 21 Apr 2023 12:36:52 +0200") References: Date: Mon, 24 Apr 2023 10:51:06 +0200 Message-ID: <87wn21br45.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Fri, 21 Apr 2023 12:36:52 +0200, Vasilij Schneidermann said: Vasilij> I'm doing network programming with Emacs Lisp and one of the t= asks was Vasilij> implementing a UDP server reading individual packets. I've fou= nd that Vasilij> when a client sends an empty packet, the server hangs up with a Vasilij> connection error and no longer accepts subsequent packets. Thi= s seems to Vasilij> be reasonable behavior for TCP (from what I understand, empty = TCP Vasilij> messages are a sign of the connection being closed), but Vasilij> not for UDP. Empty TCP messages are perfectly valid, but they should be hidden from you. recvfrom returning 0 means the connection has been closed, but that=CA=BCs a separate thing. Empty UDP messages are also valid, and are indicated by recvfrom returning 0. Could you show how you=CA=BCre generating the empty packets? Vasilij> I've attached test programs written in Emacs Lisp and Guile to Vasilij> reproduce both correctly and incorrectly functioning servers a= nd clients Vasilij> respectively. One minor nitpick is that sending an empty UDP p= acket from Vasilij> Emacs Lisp doesn't work either, but I'm unsure whether this is= a bug Vasilij> (socat behaves similarly). It=CA=BCs allowed by the protocol. I guess it could be useful for people wanting to implement their own keep-alive protocol over UDP. Robert --=20 From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Vasilij Schneidermann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Apr 2023 21:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.16823702864961 (code B ref 62990); Mon, 24 Apr 2023 21:05:01 +0000 Received: (at 62990) by debbugs.gnu.org; 24 Apr 2023 21:04:46 +0000 Received: from localhost ([127.0.0.1]:50471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pr3Mc-0001Hx-7z for submit@debbugs.gnu.org; Mon, 24 Apr 2023 17:04:46 -0400 Received: from mout-p-202.mailbox.org ([80.241.56.172]:58848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pr3Ma-0001Hj-GT for 62990@debbugs.gnu.org; Mon, 24 Apr 2023 17:04:44 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4Q4yLX2SsWz9slv; Mon, 24 Apr 2023 23:04:36 +0200 (CEST) Date: Mon, 24 Apr 2023 23:04:34 +0200 From: Vasilij Schneidermann Message-ID: References: <87wn21br45.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VFv7F+9MWpb8rsY+" Content-Disposition: inline In-Reply-To: <87wn21br45.fsf@gmail.com> X-Rspamd-Queue-Id: 4Q4yLX2SsWz9slv X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --VFv7F+9MWpb8rsY+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Empty TCP messages are perfectly valid, but they should be hidden from > you. recvfrom returning 0 means the connection has been closed, but > that=CA=BCs a separate thing. I suspect there's a missing ifdef in the code which ends up terminating the process on such a condition, for both TCP and UDP. > Could you show how you=CA=BCre generating the empty packets? Download the attachments from my previous email, launch the server with `emacs --batch -l bug-server.el`, then the client with `guile fixed-client.scm`. Swap out the server with `guile fixed-server.scm`. > It=CA=BCs allowed by the protocol. I guess it could be useful for people > wanting to implement their own keep-alive protocol over UDP. I think so as well. --VFv7F+9MWpb8rsY+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAmRG7t4ACgkQFmfJg6zC ifrHEgf9Evm8Kvhyd5r1LvRu5t1U+lM/Ahvht4m2dvDLPA1wZx5e0I5d7OzNk5uZ ZPlFN5R6BXbmq0LUyVO7rB6433bDCZ+q5DVRUmBUSS/WXXviTa9qk+ui6U9V63n2 ObitSSAv3TDsyoH12UTil0bOj4GCKS1GDD1IJnmaP/gg4CXU9Qtb6feQJ3VeMjh4 uTXjB+3O2GjfbBirJvx2pqaIvNrxCgJTOTL1CqtOOlOOZjcZ/yqHvpzvFWAyrdfZ 9DAdm94GRfBrAwczLsWNxvhaHjYEw8UcKVadyWHTXM/Xo7Gt+Xx+uH62bb1YbqoA RJ3Qf97G+RQ6pSrRTNqrdMKMJn2kEQ== =Fzvh -----END PGP SIGNATURE----- --VFv7F+9MWpb8rsY+-- From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Apr 2023 08:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vasilij Schneidermann Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168241009013996 (code B ref 62990); Tue, 25 Apr 2023 08:09:02 +0000 Received: (at 62990) by debbugs.gnu.org; 25 Apr 2023 08:08:10 +0000 Received: from localhost ([127.0.0.1]:51194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prDic-0003df-4a for submit@debbugs.gnu.org; Tue, 25 Apr 2023 04:08:10 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:48396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prDia-0003dS-7H for 62990@debbugs.gnu.org; Tue, 25 Apr 2023 04:08:08 -0400 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-3f1738d0d4cso34697195e9.1 for <62990@debbugs.gnu.org>; Tue, 25 Apr 2023 01:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682410081; x=1685002081; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=WXNf2IpJNdLvCXQ0oCFVjb0hOaIzVWNzE/FfSwj+/fU=; b=nSCF6eP1HyUKlmczZXnr10lBLJULZfe9/cePVTEu8rgjelR1GrK0Z+7eAxeKh6KhsA oxQBqT83Zhn24tkWfN7K+XWbHCnBSonBKzuZP4xdnySDaqLUiuKcz6411n+xSXyxMcaU 7/IG5n4+cQ3IEUzcA6gYolm+W0peWD65eiKOc7S6BOcvEuCKlNDLyUYKMNQENnPYQ6VF ln9PnBCCREcBZVgvza0pyP3CSdhGHQi3K0ct8iRwd+FjpvpMXHM+CTg1hRg9l/Aah6Ci YU53yEeti/1gXrNAtjQuPdEqWBlATynJ7RYcsOwmnbdoVa3kyWWPI2Fijb1IJze3ZGcb BlUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682410081; x=1685002081; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WXNf2IpJNdLvCXQ0oCFVjb0hOaIzVWNzE/FfSwj+/fU=; b=FpXDE425bXqdp7M+YHOO0cmbA6kXeexdUKPKCu1JocbasnzhB0UszBbNDOCH4TfVdy jPqGPkKHAHmr654E/5kDYI9q77l4cHhH2r6F+4T1kPkDXNyePhKgZr+ki/xpKdPbAgCy nqM7m3FRTBdkMW9ZIKrBfa8N+OdZFPS+uqoCxyTN6hjeysi8WwwJFqCD2WidyWyNeBUM lcsravM82UdLcKEjsO+ndE0RPzUTuodlxAmign0Sv8f67MggGBhVTQZfsUNFADPLuUG4 y8JULZZSPE7FiKsErMHTgKm52myay/xaDFnFrWNe53R/R3V/jhPooVdTAs5c/qA3dPiA Aszw== X-Gm-Message-State: AAQBX9f5L0QgXv0NH6SMzn7Ig7QF83JPbdfUvVoUQe2p/bgCw+eizZps MQ1TIN0M6cGmM0G8khjr4/mvtS4uPK0= X-Google-Smtp-Source: AKy350bBxd/1UHCrqcvQr2jkoGEJDwTKRxT6a9X7x6cWLD2eose+PYLjxpUeI94Zq9dVHXIAnew+lw== X-Received: by 2002:a05:600c:22d4:b0:3f1:82c6:2d80 with SMTP id 20-20020a05600c22d400b003f182c62d80mr10009617wmg.5.1682410081380; Tue, 25 Apr 2023 01:08:01 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id g9-20020a05600c000900b003f0aa490336sm17491197wmc.26.2023.04.25.01.08.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Apr 2023 01:08:00 -0700 (PDT) From: Robert Pluim In-Reply-To: (Vasilij Schneidermann's message of "Mon, 24 Apr 2023 23:04:34 +0200") References: <87wn21br45.fsf@gmail.com> Date: Tue, 25 Apr 2023 10:07:59 +0200 Message-ID: <87ttx49yg0.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Mon, 24 Apr 2023 23:04:34 +0200, Vasilij Schneidermann said: >> Empty TCP messages are perfectly valid, but they should be hidden fr= om >> you. recvfrom returning 0 means the connection has been closed, but >> that=CA=BCs a separate thing. Vasilij> I suspect there's a missing ifdef in the code which ends up te= rminating Vasilij> the process on such a condition, for both TCP and UDP. Yes, although in a different place than I expected. Patch below. The end result is to ignore the zero length message, getting it delivered to the process would involve considerably bigger changes. >> Could you show how you=CA=BCre generating the empty packets? Vasilij> Download the attachments from my previous email, launch the se= rver with Vasilij> `emacs --batch -l bug-server.el`, then the client with `guile Vasilij> fixed-client.scm`. Swap out the server with `guile fixed-serve= r.scm`. I was hoping to avoid installing guile :-) The client works, but the server gets me this, which means I=CA=BCm missing some bits somewhere: Backtrace: 6 (primitive-load "/home/rpluim/repos/fixed-server.scm") In ice-9/eval.scm: 721:20 5 (primitive-eval (import (rnrs bytevectors gnu))) In ice-9/psyntax.scm: 1241:36 4 (expand-top-sequence ((import (rnrs bytevectors gnu))) _ = =E2=80=A6) 1233:19 3 (parse _ (("placeholder" placeholder)) ((top) #(# # =E2=80= =A6)) =E2=80=A6) 285:10 2 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) = =E2=80=A6) In ice-9/eval.scm: 293:34 1 (_ #) In ice-9/boot-9.scm: 3300:6 0 (resolve-interface (rnrs bytevectors gnu) #:select _ # _ = =E2=80=A6) ice-9/boot-9.scm:3300:6: In procedure resolve-interface: no code for module (rnrs bytevectors gnu) Does guile deliver the empty message? >> It=CA=BCs allowed by the protocol. I guess it could be useful for pe= ople >> wanting to implement their own keep-alive protocol over UDP. Vasilij> I think so as well. I=CA=BCll look into it. I suspect it won=CA=BCt be a small change. Robert --=20 diff --git a/src/process.c b/src/process.c index 8e467ff7511..babe926ca5b 100644 --- a/src/process.c +++ b/src/process.c @@ -5947,6 +5947,11 @@ wait_reading_process_output (intmax_t time_limit, in= t nsecs, int read_kbd, #endif /* HAVE_PTYS */ /* If we can detect process termination, don't consider the process gone just because its pipe is closed. */ +#ifdef DATAGRAM_SOCKETS + /* A zero byte read on a UDP socket is not an error. */ + else if (nread =3D=3D 0 && DATAGRAM_CHAN_P (channel)) + ; +#endif else if (nread =3D=3D 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc) && !PIPECONN_P (proc)) ; From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 09:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vasilij Schneidermann Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168250049229848 (code B ref 62990); Wed, 26 Apr 2023 09:15:01 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 09:14:52 +0000 Received: from localhost ([127.0.0.1]:54260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prbEh-0007lL-Nx for submit@debbugs.gnu.org; Wed, 26 Apr 2023 05:14:52 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:51239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prbEg-0007l4-9k for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 05:14:51 -0400 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3f19a80a330so29087975e9.2 for <62990@debbugs.gnu.org>; Wed, 26 Apr 2023 02:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682500484; x=1685092484; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=PLtNr8NYo6ETpgMsLibrtqykpTcZybHRGShB0xWXEmE=; b=NT4uV/VSl8W3fh/KKDuoYNhsGuxA89FqqMGNRzZv+H9bPdci++m9oP0f78QkU62eCs geQtT2REMKcuM9w8APYeQ34II6uukiuvjGUR4Q0MNg6TQanyGOlFO5m6gUqfQi46rhyG 8nhNFknou/WKWitRUqV/lVBvseqaoeBlRX84vJwx7FlGc8eZSPGKIV/eUzxvynBjRyDK BbR7KTr4/rn0bQB5vgOKqE5Y/bdsN7dofxBAKcnAze6pvB7ruKBtBedAAfF2p1sQby5V Pi9qDz76hZ3bLvFUpGa/XFJIMG4umhjFG40ubXO6kQeS/wRuwDlipI2AmeUrEkXvw+8e a2vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682500484; x=1685092484; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PLtNr8NYo6ETpgMsLibrtqykpTcZybHRGShB0xWXEmE=; b=fXpX3ZceTRE7wJLPiRfrw6VsbxTqMIvJO0MN9ZXXzFE2F5obsxofR675Qs1/V/tCcj qZALyfX765hXzhFvm2bA1z+N38eZFXhvdvO7cFUPpBVfoqjOsrv9ains/NJhTcHxNuR1 nznE65H2ZyW3+ThwbVjh2dWLMuvTOPhy42UzWvU0J9XhLrMXVSqdzPlU7vk1Clihh8BK IjPpH0kR6sVuCM4Sg8+AvdFxOSZCEkf4yqkooL/yyQouP3VHXVifpOzKCVV/VvDGUlnT UYGlqrQwRhSsXSYyEoOI+570R2uk4JT02bbaegFxcjuvTARdwZs33rJA5gfqWNtCwjcf mVRQ== X-Gm-Message-State: AAQBX9fBLScsShbtjlnjs6QjCo+fD9kMY+YQySrg4I38y0onrf4ORt+y oqVxS8YQKqOODUIZs5hxdSB+AcWx0n8= X-Google-Smtp-Source: AKy350YFpZ5MPJB8d0rzXntgs4QCE8CKVO5zKTJcAA4By6uXv4sjZ6IDAq5oKLuaF0devCyhZgoTyA== X-Received: by 2002:a05:600c:2212:b0:3f1:6fea:790a with SMTP id z18-20020a05600c221200b003f16fea790amr11991835wml.30.1682500483691; Wed, 26 Apr 2023 02:14:43 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id iz14-20020a05600c554e00b003f175954e71sm20786301wmb.32.2023.04.26.02.14.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 02:14:42 -0700 (PDT) From: Robert Pluim In-Reply-To: <87ttx49yg0.fsf@gmail.com> (Robert Pluim's message of "Tue, 25 Apr 2023 10:07:59 +0200") References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> Date: Wed, 26 Apr 2023 11:14:42 +0200 Message-ID: <87354nt37h.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain So allowing emacs to send 0-length UDP packets turned out to be not too hard. Patch for both below. Eli, is this OK for master? It does change 2 behaviours: 1. Receiving a 0-length UDP packet will no longer cause an error 2. Calling (process-send-string proc "") now actually sends out a packet for a UDP process (an empty one). Robert -- --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Allow-zero-length-UDP-send-receive.patch >From 4bb6dec25ad3c3b548e18e82b2129b53c1ee1b69 Mon Sep 17 00:00:00 2001 From: Robert Pluim Date: Tue, 25 Apr 2023 12:48:26 +0200 Subject: [PATCH] Allow zero-length UDP send/receive To: emacs-devel@gnu.org * src/process.c (wait_reading_process_output) [DATAGRAM_SOCKETS]: Don't close the network connection if we receive a zero-length UDP packet. (send_process) [DATAGRAM_SOCKETS]: Allow sending a zero-length UDP packet. * etc/NEWS: Announce the change. --- etc/NEWS | 8 ++++++++ src/process.c | 16 ++++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index ea233865f5a..4cc02d76b8f 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -82,6 +82,14 @@ The ':keepalive-idle', ':keepalive-interval', and ':keepalive-count' options can now be used to set the various timers and counters used when TCP keepalive is enabled for a connection. +** Emacs can now send zero-length UDP packets. +Previously 'process-send-string' of an empty string to a UDP process +did nothing, now it sends out a zero-length UDP packet. + +** Emacs can now receive zero-length UDP packets. +Previously, receiving a zero-length UDP packet closed the receiving +network process. They are now silently ignored. + * Editing Changes in Emacs 30.1 diff --git a/src/process.c b/src/process.c index 8e467ff7511..e3233f5ad89 100644 --- a/src/process.c +++ b/src/process.c @@ -5947,6 +5947,11 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, #endif /* HAVE_PTYS */ /* If we can detect process termination, don't consider the process gone just because its pipe is closed. */ +#ifdef DATAGRAM_SOCKETS + /* A zero byte read on a UDP socket is not an error. */ + else if (nread == 0 && DATAGRAM_CHAN_P (channel)) + got_some_output = 1; +#endif else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc) && !PIPECONN_P (proc)) ; @@ -6616,9 +6621,16 @@ send_process (Lisp_Object proc, const char *buf, ptrdiff_t len, cur_buf = buf; cur_object = object; } - - while (cur_len > 0) + /* UDP allows zero-length writes. */ + bool zero_length = false; +#ifdef DATAGRAM_SOCKETS + if (cur_len == 0 && NETCONN_P (proc) && 0 <= p->outfd + && DATAGRAM_CHAN_P (p->outfd)) + zero_length = true; +#endif + while (cur_len > 0 || zero_length) { + zero_length = false; /* Send this batch, using one or more write calls. */ ptrdiff_t written = 0; int outfd = p->outfd; -- 2.38.1.420.g319605f8f0 --=-=-=-- From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 10:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org, mail@vasilij.de Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168250501615433 (code B ref 62990); Wed, 26 Apr 2023 10:31:01 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 10:30:16 +0000 Received: from localhost ([127.0.0.1]:54358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcPg-00040r-5C for submit@debbugs.gnu.org; Wed, 26 Apr 2023 06:30:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcPb-0003zX-9y for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 06:30:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prcPU-0001PG-Bf; Wed, 26 Apr 2023 06:30:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=J3D8fngqBdGIEeGujCx86zNJ3sHUtOV7GGIbVhxlOiM=; b=NtMCFMtfhMau ng5qCcGoEDFg3dcLwbRwC9jC5vQnf0U3TyKZuOfiMVFnk1CDzUAR+5hmg70UCIy29DXDClqvwofwA cVd14NDJpoByZh1OfjcAP2IpfKOa3mupkAkmvlUojKdcSezgafwmgbG94r6At8zXlR68fId4pw/p+ TbR81v0/ylRBuXeqffsJOegbqNsqSv/UFPmC6dqV1ymOKG0fq3jnkxqev0ZuTG4Qd4UEUaC1KQBVk 7xmHYnDRxADBCGbvm7m3l4NC5tXk4usZfvLQOHandrin//Qdvivrard8h1dXnybtEkqOcJsY75Vwx LJsSHFnGm14ChP0dPiTM+g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prcPT-0006eg-Al; Wed, 26 Apr 2023 06:30:04 -0400 Date: Wed, 26 Apr 2023 13:30:32 +0300 Message-Id: <83v8hjszp3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87354nt37h.fsf@gmail.com> (message from Robert Pluim on Wed, 26 Apr 2023 11:14:42 +0200) References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 62990@debbugs.gnu.org > From: Robert Pluim > Date: Wed, 26 Apr 2023 11:14:42 +0200 > > So allowing emacs to send 0-length UDP packets turned out to be not > too hard. Patch for both below. Eli, is this OK for master? It does > change 2 behaviours: > > 1. Receiving a 0-length UDP packet will no longer cause an error > 2. Calling (process-send-string proc "") now actually sends out a > packet for a UDP process (an empty one). Do we want some variable to get back the old behavior, in case some application out there depends on that? Otherwise, fine by me, thanks. From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 10:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62990@debbugs.gnu.org, mail@vasilij.de Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168250533015909 (code B ref 62990); Wed, 26 Apr 2023 10:36:01 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 10:35:30 +0000 Received: from localhost ([127.0.0.1]:54367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcUk-00048X-7D for submit@debbugs.gnu.org; Wed, 26 Apr 2023 06:35:30 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:46108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcUi-00048G-Fp for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 06:35:29 -0400 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-2f917585b26so6336397f8f.0 for <62990@debbugs.gnu.org>; Wed, 26 Apr 2023 03:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682505322; x=1685097322; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=E6l06H4P3j/OMi4ZpKduwstLvArmvUx3ILg2uG+9At4=; b=h57Qn5AuLdUlhKpcsSur6D+fPCoI27hOrOfNliGtyHamhWDbLf8pkNJOX1mXh6F5wg fe9Av96O101tiR6noBOJMc2VH2BvtFagsRiwmob1xFVyYG29nNUt20KMW7sS6e+sKGhZ 4K71hQi7qVLuSQ2olwQjregAsDuSjrJlrvYwX46sSr6xxkRUSuo6oTQ8T74Ul0bsN3He EdIU+vw4os8+Is9JlGVaq3uurcuwg8LkjwLAIKXs4DXvIEah5XG4KKZP4HCaTZboIDKs sFERfsqMN+OIPjDU1ByjsT9rQb3veQexIdhTrSk4ioBIrKDSFOWVMLyYlqGmZuLKesGj uIjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682505322; x=1685097322; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E6l06H4P3j/OMi4ZpKduwstLvArmvUx3ILg2uG+9At4=; b=BYiMwIHflSF5vkVF7TTesr9Tymvp9bE76guJLhYHY6UYcZ00AQ54tcEe6OKaW8bhx6 zvYrP5tdk0LxRuHaBqnWVv68EiVXl5QF1bGpuP7sbNKZusa79G8RX45hImO+JL+f2Z2R XTPH/JL/yrEcUJEIzye30a4ASX6lGg6c7KGw0bp4S0KsZwanMH9Lsc3jT5dQadXLd0B8 VBnpRT+LItcIykcZg9G44+IP4cr0Vh2Bh9GVL4z7z1p1rTOvjJjnx11RW2sXSwKf2y4e qvYqYb/IRV35gSjqhXS10DaM3DjHIwDmuugya8HQtzXc1Y0Ech1AuR1Hn5xqsf9SsKI3 dNJg== X-Gm-Message-State: AAQBX9fiwLMmzS6KW2rDT2y5+pua9r0pia+FnI6+TAgns9cPDiCWAVSo dooBPS43xopjTZnu8HrfPhi1IMdRXnk= X-Google-Smtp-Source: AKy350ZlnRJx4g6pQqynicFCw6+CQ9Xilj+78vwOArqiWvO4fAFcs2+CW9beeu6X+f+P5t+/Aak9HA== X-Received: by 2002:adf:edcc:0:b0:2f4:fcd:98dd with SMTP id v12-20020adfedcc000000b002f40fcd98ddmr14575955wro.4.1682505322436; Wed, 26 Apr 2023 03:35:22 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id z14-20020a5d4d0e000000b002efb4f2d240sm15420429wrt.87.2023.04.26.03.35.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 03:35:22 -0700 (PDT) From: Robert Pluim In-Reply-To: <83v8hjszp3.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Apr 2023 13:30:32 +0300") References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> <83v8hjszp3.fsf@gnu.org> Date: Wed, 26 Apr 2023 12:35:21 +0200 Message-ID: <87ttx3rkwm.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Wed, 26 Apr 2023 13:30:32 +0300, Eli Zaretskii said: >> Cc: 62990@debbugs.gnu.org >> From: Robert Pluim >> Date: Wed, 26 Apr 2023 11:14:42 +0200 >>=20 >> So allowing emacs to send 0-length UDP packets turned out to be not >> too hard. Patch for both below. Eli, is this OK for master? It does >> change 2 behaviours: >>=20 >> 1. Receiving a 0-length UDP packet will no longer cause an error >> 2. Calling (process-send-string proc "") now actually sends out a >> packet for a UDP process (an empty one). Eli> Do we want some variable to get back the old behavior, in case some Eli> application out there depends on that? For which one? Does it help if I say that [1] is a security fix? =F0=9F=98= =9C I can=CA=BCt think of anything that would be negatively affected, but we=CA= =BCve all been wrong before. Eli> Otherwise, fine by me, thanks. Vasilij, does the patch work for you? Robert --=20 From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 10:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org, mail@vasilij.de Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168250550816193 (code B ref 62990); Wed, 26 Apr 2023 10:39:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 10:38:28 +0000 Received: from localhost ([127.0.0.1]:54377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcXc-0004D6-55 for submit@debbugs.gnu.org; Wed, 26 Apr 2023 06:38:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcXZ-0004Cs-AQ for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 06:38:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prcXS-00034J-SO; Wed, 26 Apr 2023 06:38:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=5TPdi565CpJ+vfACKgzvL/mBVJ+ilnsVY30U8GBlHv8=; b=iKfM+AsVZ6o2ylrHr9zR 3t1r1x7XweEiEls//PYaGATYfh/JQA+dwG2nkeKGpkm05micGfpkxJQzrVw1Uvfiumm9aKxBoL0KV pNjYtlknihYWWXc3JGpYDextdlventaDYVWzWkZdF91xtRs0jTs5QEZCyPSYJJQjm8inBww50H43+ wt8ksjiYUi8gVveOqXcIl1RwlrIZKARqJv0usv0xEUy4kA9imtRzimB9cTP5MGaphcjm1foqEOQCC syPDwrelZgqQaXTBvb38G7Ju81pkGfyKr77qIxkUzutSbAW52bDIyi7snGxqHs6BtO/QjQs4Z+Slb ww0OCphB7VEpUA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1prcXS-0005ty-7p; Wed, 26 Apr 2023 06:38:18 -0400 Date: Wed, 26 Apr 2023 13:38:47 +0300 Message-Id: <83pm7rszbc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ttx3rkwm.fsf@gmail.com> (message from Robert Pluim on Wed, 26 Apr 2023 12:35:21 +0200) References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> <83v8hjszp3.fsf@gnu.org> <87ttx3rkwm.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Robert Pluim > Cc: 62990@debbugs.gnu.org, mail@vasilij.de > Date: Wed, 26 Apr 2023 12:35:21 +0200 > > >>>>> On Wed, 26 Apr 2023 13:30:32 +0300, Eli Zaretskii said: > > Eli> Do we want some variable to get back the old behavior, in case some > Eli> application out there depends on that? > > For which one? The 2nd one. > Does it help if I say that [1] is a security fix? 😜 No. But it will help if you convince me that it's a bug-fix. From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Vasilij Schneidermann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 10:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168250661318750 (code B ref 62990); Wed, 26 Apr 2023 10:57:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 10:56:53 +0000 Received: from localhost ([127.0.0.1]:54389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcpQ-0004sM-J7 for submit@debbugs.gnu.org; Wed, 26 Apr 2023 06:56:52 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:49402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcpM-0004s5-Hy for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 06:56:51 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Q5wm85hcHz9sTv; Wed, 26 Apr 2023 12:56:40 +0200 (CEST) Date: Wed, 26 Apr 2023 12:56:39 +0200 From: Vasilij Schneidermann Message-ID: References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UjXoEwESkdF/PNa9" Content-Disposition: inline In-Reply-To: <87ttx49yg0.fsf@gmail.com> X-Rspamd-Queue-Id: 4Q5wm85hcHz9sTv X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --UjXoEwESkdF/PNa9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Yes, although in a different place than I expected. Patch below. The > end result is to ignore the zero length message, getting it delivered > to the process would involve considerably bigger changes. Thank you. Yes, that is the case, the network process is no longer shut down, but the 0-length message isn't picked up. It prints the following: Received string (5): "hello" Received string (5): "world" Rather than the expected: Received string (5): "hello" Received string (0): "" Received string (5): "world" > I was hoping to avoid installing guile :-) I figured Guile would be the safest option for the developers of GNU software, rather than requiring Python, Ruby, ... > The client works, but the server gets me this, which means I=CA=BCm missi= ng > some bits somewhere: > [...] > ice-9/boot-9.scm:3300:6: In procedure resolve-interface: > no code for module (rnrs bytevectors gnu) Hm, could be an addition specific to Guile 3. It can be worked around probably by doing some less efficient string copying. > Does guile deliver the empty message? Yes it does. --UjXoEwESkdF/PNa9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAmRJA2QACgkQFmfJg6zC ifqHvggAnjOW8PFNzjcji2C9JGkszRZs4mhg9gikcfbh3uWzLtFnpPkNLSGtZdvc ohLK1s7yrbp6ovpE95k4CyT1x9QFPuhCz5SiTk9lTjn3GJnNCcC6uqBZg5yN+3yo +gtY9I3DK93lZ+/Esjs0zPWpiv6WVcRjXqZjQn0Wm6/Zuol/hTM8QPgNBcm8yIey 5G+JFXc2oMdWYNl39npep+to/1cfSsrrCf2D0gyYprnTYjhGRzKoMux0Hg0C7NSG tXrdZhxFddxKsKF9JAQ5R7XYV/Q8tTtxDd/SWAPnJacp7+6NRvULZSkMHKrirvSM r6s3HMQ9ZWqTqb2W2u47h4m8jL/FAw== =jMPV -----END PGP SIGNATURE----- --UjXoEwESkdF/PNa9-- From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Vasilij Schneidermann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 10:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org, Eli Zaretskii Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168250671518932 (code B ref 62990); Wed, 26 Apr 2023 10:59:01 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 10:58:35 +0000 Received: from localhost ([127.0.0.1]:54395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcr5-0004vI-1X for submit@debbugs.gnu.org; Wed, 26 Apr 2023 06:58:35 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:43628) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prcr2-0004v3-SD for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 06:58:33 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Q5wp955vsz9sV4; Wed, 26 Apr 2023 12:58:25 +0200 (CEST) Date: Wed, 26 Apr 2023 12:58:24 +0200 From: Vasilij Schneidermann Message-ID: References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> <83v8hjszp3.fsf@gnu.org> <87ttx3rkwm.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P9e2eWPqkgpuS7S/" Content-Disposition: inline In-Reply-To: <87ttx3rkwm.fsf@gmail.com> X-Rspamd-Queue-Id: 4Q5wp955vsz9sV4 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --P9e2eWPqkgpuS7S/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline > Vasilij, does the patch work for you? It does solve half of the problem: The network process is no longer shut down, but the packet is ignored rather than resulting in an additional process filter call with an empty string. --P9e2eWPqkgpuS7S/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAmRJA9AACgkQFmfJg6zC ifp+VAgAi/afdGF0gDs2YAdVvNUnc7DXB3d42t/BTXhDxc7uT3m+BKqyQyOyla7T JqXS8pSChgUuBN04tu6sXiHPaWRfa1c6+YsAykk3FCCIUbMghT7as386lEQludGF RChSnx+wvDDUWjThYqLmnwiJRhYe2PypG8hmLOlImneM2rT3YJ4NaziMxiFdpjXn FwprNDi617DleJhhaJWFyACS1cs498C6/R2V9UMtcxuxUgbpouh/SJGNWeTh9yrY heQ5/1gQBRISJwFfuzfpdQmeXOXhdFz57C7QJxtkik4TdT48Auj+Ie3dyPo7Ljhn VWgBCoXNrxzdGEdcK7gNT01GUOMs6A== =sZ0S -----END PGP SIGNATURE----- --P9e2eWPqkgpuS7S/-- From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62990@debbugs.gnu.org, mail@vasilij.de Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.1682509681747 (code B ref 62990); Wed, 26 Apr 2023 11:48:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 11:48:01 +0000 Received: from localhost ([127.0.0.1]:54433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prdcv-0000Bv-7j for submit@debbugs.gnu.org; Wed, 26 Apr 2023 07:48:01 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:55760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prdcr-0000Al-6z for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 07:47:59 -0400 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-2f46348728eso4270653f8f.3 for <62990@debbugs.gnu.org>; Wed, 26 Apr 2023 04:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682509671; x=1685101671; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=2CQMDmLioYSG6ijR+wamkY80pDrTPsHbiFOHKaiBZ8I=; b=RlLnRSV/8EcH8ns8hL0DxbwPr0qt1p2GQTzTuTk002WyQ5QicoWZl5QvcjTG0ZBqP0 5Ai5dYtYntUJmGFZAKgfb4Xm7TL+seser779nsWPjYhsqW3FYJP83Fmn6vUoAg9OPuom Znk5kxBJVQ45N1Um162zHuizF3vbEw5ej/hpEsfj2UmwHVFYnpM1ZkH013fx+dFKFA9B gS2EctSw9HJwPqpHDZU0jUWpkpXZmzdb4tXuWKurN0b56ouQ++MNbve8zqgMNwVXakQN DoCq+CH9yo5Z+jDG76HEyi+1zvLGycFnKCLKKRPAzXtEys65rIwT4AIld4/P6umrizfo mk0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682509671; x=1685101671; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2CQMDmLioYSG6ijR+wamkY80pDrTPsHbiFOHKaiBZ8I=; b=ZQpzUD2lPu+dYgGLvHdRM0R8zJATBUlI44e+T7AaeLVkGPlm4+5pztZyklSG6sdqJh fCJTfijM2DjD7vUiN6ioVXkSCBs1shf+cnM7NVtsMc6PgUxgoCbTyjZx0kthMofrWh8C iZV8rNz5LFKj5obWpAO80pT76VkPNQmlWpP1FXeh01BVxuILBSIiWp9YlL90JUZRmhFk NIZblOsDgNMkqEMDSpnfbfGIDLIfBX4jVVSjrRteSLuJ5I8skfHfNwshOB6oxM1k2qbC 2H/YOZLD5PcqEVUogQJhlJNfKRozJ17pRncAs6Zzoj8FMPxUtLVHBsTyAAxoQ92qBwAv 7+IA== X-Gm-Message-State: AAQBX9dzD99hUsuV8i062GdluspkH3Sn7XXdwZsYsjjE7Pk/8bSRiLVf 3VF99bIuyYxBMXfUH9GkUtg= X-Google-Smtp-Source: AKy350b6N7RcVntQVX4ZKL4qSQ2xqxlA4nOCqMoIH6jm0dSYcnixydOVXfEk6JNPhFxvF5XF/SvR9A== X-Received: by 2002:adf:dccc:0:b0:2ff:a6c5:2809 with SMTP id x12-20020adfdccc000000b002ffa6c52809mr14831521wrm.28.1682509671159; Wed, 26 Apr 2023 04:47:51 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id s12-20020a7bc38c000000b003f1739a0116sm17713035wmj.33.2023.04.26.04.47.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 04:47:50 -0700 (PDT) From: Robert Pluim In-Reply-To: <83pm7rszbc.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Apr 2023 13:38:47 +0300") References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> <83v8hjszp3.fsf@gnu.org> <87ttx3rkwm.fsf@gmail.com> <83pm7rszbc.fsf@gnu.org> Date: Wed, 26 Apr 2023 13:47:49 +0200 Message-ID: <87o7nasw4a.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Wed, 26 Apr 2023 13:38:47 +0300, Eli Zaretskii said: >> From: Robert Pluim >> Cc: 62990@debbugs.gnu.org, mail@vasilij.de >> Date: Wed, 26 Apr 2023 12:35:21 +0200 >>=20 >> >>>>> On Wed, 26 Apr 2023 13:30:32 +0300, Eli Zaretskii said: >>=20 Eli> Do we want some variable to get back the old behavior, in case some Eli> application out there depends on that? >>=20 >> For which one? Eli> The 2nd one. I guess we could, but if the application asks us to send an empty packet we should do it. >> Does it help if I say that [1] is a security fix? =F0=9F=98=9C Eli> No. But it will help if you convince me that it's a bug-fix. It transforms this: recvfrom(5, "hello", 4096, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(56= 845), sin_addr=3Dinet_addr("127.0.0.1")}, [16]) =3D 5 Received string (5): "hello" recvfrom(5, "", 4096, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(56845),= sin_addr=3Dinet_addr("127.0.0.1")}, [16]) =3D 0 Received event: "connection broken by remote peer into this: recvfrom(5, "hello", 4096, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(55= 486), sin_addr=3Dinet_addr("127.0.0.1")}, [16]) =3D 5 Received string (5): "hello" recvfrom(5, "", 4096, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(55486),= sin_addr=3Dinet_addr("127.0.0.1")}, [16]) =3D 0 recvfrom(5, "world", 4096, 0, {sa_family=3DAF_INET, sin_port=3Dhtons(55= 486), sin_addr=3Dinet_addr("127.0.0.1")}, [16]) =3D 5 Received string (5): "world" ie the UDP process is still running and can still receive messages Robert --=20 From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 11:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vasilij Schneidermann Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.16825098281153 (code B ref 62990); Wed, 26 Apr 2023 11:51:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 11:50:28 +0000 Received: from localhost ([127.0.0.1]:54441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prdfH-0000IX-I3 for submit@debbugs.gnu.org; Wed, 26 Apr 2023 07:50:27 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:62961) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prdfE-0000IF-P9 for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 07:50:25 -0400 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3f1957e80a2so148840965e9.1 for <62990@debbugs.gnu.org>; Wed, 26 Apr 2023 04:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682509818; x=1685101818; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=QamC3r2IEc4+R95h86w+8/nvnqYoSkVgoCtAdV1g0gc=; b=VG8K7zjnDMoklzzjC+jyvWiWAxkyIv2Qsxk6Y1zuQ8NhEat9pNhAA3EXJzhfOMHOxD b0SHKXcsrbtxNFqNJ6f/C3sYj0yheUzjoGSGg21p9XEllwWkJHyEUpALKb5drtWsrxSy 8VKtjdMZL+OpGce5rwK6af0ujyb0DTAu4FdJLARSbi+cg1kSCcN8gOpySur4jtUwGqI2 oM6Wxw9nq2QqWiNEUDqkf9HEpc4P4j54PVS8Xjdf+iI6Ab3SZss1XIL0IPXIiInnK0Xh CdiW4vJ0WEdUKOLOfR8PeiGUFM9YCJqryEakqrFRDP+FAyGeW60qxye+cZz0hE3+uz+e Bh6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682509818; x=1685101818; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QamC3r2IEc4+R95h86w+8/nvnqYoSkVgoCtAdV1g0gc=; b=c8EfoV0l4MBicpIgVQF10ABUvIgDuNoCcqxaPwJONExtmLYRrrM1IGnvXRoQ3hL1x2 x1nBPjh3ne+qchCf5SwI2kwEJYmLaSm4iz50+zRDa1FyI24yL0KaqcVMEgWxP1K9t4gM ejVnaC6awqE3Adfy3MnVEwQ/vWjSHKQTqSiIRVARVv+rkuL4h5OjWBKdaLZetwRDiF4f fEtDyFoC1qdcdlB2ZHAcvEZ2VSowM0yS6HcvH8oCt5ZfHV5hncMuAambC1Fq2lwM+CGS hkQpuhN552yxk6ygmTUVzpZ9dk0jRDLtg5HVhoxR37coAO3wuT7z1MRvZuCleWAN6xUm Quig== X-Gm-Message-State: AC+VfDyOja+9f40jSIzYgQK1xjQthEBeJwGtUMEURybzafZdVYuDD0dm mVtJXF7jis+QiW/PgVDNyB33G9pf+UI= X-Google-Smtp-Source: ACHHUZ5OI25dPB6oufsfSBGP1fgIJnUwGKG5wVwr8fpDE2HrClzsODH7nEMZkd1nmOM/CFm8DWBFxw== X-Received: by 2002:a1c:7301:0:b0:3f1:6f57:6fd1 with SMTP id d1-20020a1c7301000000b003f16f576fd1mr1754773wmb.9.1682509818481; Wed, 26 Apr 2023 04:50:18 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id q9-20020a05600000c900b002c8476dde7asm15566104wrx.114.2023.04.26.04.50.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 04:50:18 -0700 (PDT) From: Robert Pluim In-Reply-To: (Vasilij Schneidermann's message of "Wed, 26 Apr 2023 12:56:39 +0200") References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> Date: Wed, 26 Apr 2023 13:50:17 +0200 Message-ID: <87jzxysw06.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Wed, 26 Apr 2023 12:56:39 +0200, Vasilij Schneidermann said: Vasilij> Thank you. Yes, that is the case, the network process is no lo= nger shut Vasilij> down, but the 0-length message isn't picked up. It prints the = following: Vasilij> Received string (5): "hello" Vasilij> Received string (5): "world" Vasilij> Rather than the expected: Vasilij> Received string (5): "hello" Vasilij> Received string (0): "" Vasilij> Received string (5): "world" Right. Getting emacs to deliver a zero length string to the UDP process would be quite a change, one I can=CA=BCt get to any time soon. >> Does guile deliver the empty message? Vasilij> Yes it does. OK. Robert --=20 From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 12:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org, mail@vasilij.de Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.16825118524516 (code B ref 62990); Wed, 26 Apr 2023 12:25:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 12:24:12 +0000 Received: from localhost ([127.0.0.1]:54453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1preBw-0001Am-0c for submit@debbugs.gnu.org; Wed, 26 Apr 2023 08:24:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1preBs-0001AV-Dh for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 08:24:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1preBl-0007NP-Pe; Wed, 26 Apr 2023 08:24:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ZzDxWwmlVWrIBqHK+v/y8qjGFvZ6ivsR56CRtOg/xNs=; b=WO+39USgEOFy4P290IeH foIhKG9KgrkRDiUcLzmLwg8CkQwwgmtETKuwaDAjQ0JBEuQFdeR94PYKSRZqOHb9VOYUaB97Fxmbt HCyqcKilRmhz0o6I2pmo0ldPK8CN7d5cOh0a1QpUIOldUc1rWbUvbSss3z1NKRJBIlXBstzhbSCx3 3jqp6zCwCOEzzLpDYN2jA6+gXyNpXe2yDmA1f4rGxff0QvDWsjKMtYlvxwsiFsK3qmAi56yD0xOPM 1fSeoT30ilGd0Fv3GL7IUqmpNCCcfqefAKWRHg0aMFYUHlAKhh6IRcv2sc4L4mx06JB+usiSYHSIF qJUfHOuBEOrKMQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1preBJ-0006Fx-Q5; Wed, 26 Apr 2023 08:23:48 -0400 Date: Wed, 26 Apr 2023 15:24:03 +0300 Message-Id: <83jzxyu90c.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87o7nasw4a.fsf@gmail.com> (message from Robert Pluim on Wed, 26 Apr 2023 13:47:49 +0200) References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> <83v8hjszp3.fsf@gnu.org> <87ttx3rkwm.fsf@gmail.com> <83pm7rszbc.fsf@gnu.org> <87o7nasw4a.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Robert Pluim > Cc: 62990@debbugs.gnu.org, mail@vasilij.de > Date: Wed, 26 Apr 2023 13:47:49 +0200 > > >>>>> On Wed, 26 Apr 2023 13:38:47 +0300, Eli Zaretskii said: > > >> From: Robert Pluim > >> Cc: 62990@debbugs.gnu.org, mail@vasilij.de > >> Date: Wed, 26 Apr 2023 12:35:21 +0200 > >> > >> >>>>> On Wed, 26 Apr 2023 13:30:32 +0300, Eli Zaretskii said: > >> > Eli> Do we want some variable to get back the old behavior, in case some > Eli> application out there depends on that? > >> > >> For which one? > > Eli> The 2nd one. > > I guess we could, but if the application asks us to send an empty > packet we should do it. I didn't say that the default behavior should be that, I just asked whether it is conceivable that someone, somewhere could actually rely on the semi-buggy behavior, whereby empty packets aren't sent? > >> Does it help if I say that [1] is a security fix? 😜 > > Eli> No. But it will help if you convince me that it's a bug-fix. > > It transforms this: > > recvfrom(5, "hello", 4096, 0, {sa_family=AF_INET, sin_port=htons(56845), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 > Received string (5): "hello" > recvfrom(5, "", 4096, 0, {sa_family=AF_INET, sin_port=htons(56845), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 > Received event: "connection broken by remote peer > > into this: > > recvfrom(5, "hello", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 > Received string (5): "hello" > recvfrom(5, "", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 > recvfrom(5, "world", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5 > Received string (5): "world" > > ie the UDP process is still running and can still receive messages And no one could ever expect that? IOW, is this behavior obviously wrong? From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 14:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62990@debbugs.gnu.org, mail@vasilij.de Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168251927720620 (code B ref 62990); Wed, 26 Apr 2023 14:28:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 14:27:57 +0000 Received: from localhost ([127.0.0.1]:56753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prg7h-0005MW-91 for submit@debbugs.gnu.org; Wed, 26 Apr 2023 10:27:57 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:50274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prg7f-0005MI-RW for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 10:27:56 -0400 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-3f18dacd392so44474755e9.0 for <62990@debbugs.gnu.org>; Wed, 26 Apr 2023 07:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682519270; x=1685111270; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=GwuhaNkQKeSLGeyv0OqWO4el3G+NG/N4dUh4FZBisfQ=; b=AfKF5vrXUiejnKlabDB0CRz5KiLckq0aGvi3aJI2CerTq0R444LeTEA/grEQXh+hJM O5Kldsiv3Lbu8YgpCOcLfxLuC8mMZ3N5zwI60BoFUSfahqjyioMlG9TD3iIvds8SHzi+ 3tfDohUuU8ybrYn3Amr5jgb5zU2IxqvhghbWApIzlWxnzhCs5rx2Zvuw8odvQcY0Juc7 VxmQkKh0piXNaT3RQIrkD3m05Dw5npuQupJTbGnWYo0rKupyWIh2yxTcmiPFvW66jRL7 sQcVl9m8LKnTU2hbp90FUvOsHiFL6IGN2f04VNTM31B2Xe8xjzju1vs87zl9zsHlhKj+ L6Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682519270; x=1685111270; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GwuhaNkQKeSLGeyv0OqWO4el3G+NG/N4dUh4FZBisfQ=; b=gKYvGG/8C8/mcJbmmgs8E14yV2huXiY/jPJ3hSARL3dbIc1kIsTaY+p/YJMX+ulq/A 6HYh7xCnQj4AXOgCVDaJKZvsRmiCrdgVzsSerfqQGBV/3foqZNfTo8bThUVCH6HP6w8E AdnQN8SNL8uRrOnNI0QuB9ZjC1CoWIHUM45tfl36HjbGs2VSpLwpYIxf1WSOO6mBJn2c oFXt08HufhPYRzCklFABX3ElgDNkjPZT8d93N9T69ugodCliA9joKQD627ZXQU1s6moI Q7WUnYwlXqcInDAXBx+K9TR8aFCldYcRUZA4cy9Wp/7sc1Xi9GvqOSD44PjaOPtam5xU eHYQ== X-Gm-Message-State: AAQBX9cUvnOahOoFV3A5HV+fvKMZrMvQgu0mgUAGYd9DZs3fxQV2PsbV vdzNC3lw2m5slIoW2SfUIRs= X-Google-Smtp-Source: AKy350YQCQMeApW3RKhbaMCfNiiPYZ6mxB+5VCajWTGReC6n9oULoNPBgY1/z61IwwkdQo7T1INxfA== X-Received: by 2002:a1c:f703:0:b0:3ef:6b97:f0c3 with SMTP id v3-20020a1cf703000000b003ef6b97f0c3mr13946557wmh.15.1682519269838; Wed, 26 Apr 2023 07:27:49 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id n17-20020a05600c3b9100b003ee9c8cc631sm21780149wms.23.2023.04.26.07.27.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 07:27:49 -0700 (PDT) From: Robert Pluim In-Reply-To: <83jzxyu90c.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Apr 2023 15:24:03 +0300") References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87354nt37h.fsf@gmail.com> <83v8hjszp3.fsf@gnu.org> <87ttx3rkwm.fsf@gmail.com> <83pm7rszbc.fsf@gnu.org> <87o7nasw4a.fsf@gmail.com> <83jzxyu90c.fsf@gnu.org> Date: Wed, 26 Apr 2023 16:27:48 +0200 Message-ID: <87bkjasopn.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Wed, 26 Apr 2023 15:24:03 +0300, Eli Zaretskii said: >>=20 >> I guess we could, but if the application asks us to send an empty >> packet we should do it. Eli> I didn't say that the default behavior should be that, I just asked Eli> whether it is conceivable that someone, somewhere could actually r= ely Eli> on the semi-buggy behavior, whereby empty packets aren't sent? I can=CA=BCt conceive of it. If it ever does happen the fix is easy: check the length of the message before sending it. >>=20 >> ie the UDP process is still running and can still receive messages Eli> And no one could ever expect that? IOW, is this behavior obviously Eli> wrong? Yes. The other end has sent a valid UDP packet, and we react by closing the connection. Robert --=20 From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 14:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Vasilij Schneidermann Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.168251952421127 (code B ref 62990); Wed, 26 Apr 2023 14:33:02 +0000 Received: (at 62990) by debbugs.gnu.org; 26 Apr 2023 14:32:04 +0000 Received: from localhost ([127.0.0.1]:56757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prgBf-0005Uh-Sl for submit@debbugs.gnu.org; Wed, 26 Apr 2023 10:32:04 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:61455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prgBd-0005UD-S4 for 62990@debbugs.gnu.org; Wed, 26 Apr 2023 10:32:02 -0400 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-3f19ab994ccso49881655e9.2 for <62990@debbugs.gnu.org>; Wed, 26 Apr 2023 07:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682519516; x=1685111516; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=vnK/SQhANKndFlUcYbR0hF8iVMTmuDEOvt9GxJcZpxE=; b=Q3LzCi0oAnLisvu0SWXaNHMrkXdQ6f14RDrU6W8KJ1q5C2APOEwgT/xvYWBNRE3Kfs H84jIyk8MKOu56r1koOyI1zKP4+W1MsKFpkheAGcBV/8jxEJZZmRIa1zMDBi8xbjLTGK sY6tLQy7dNaC2QIcFs7TrJ12xtifWURaLIJ1uAuWB8bGhDAmBVSCHr84tKDdSNz9pYlk f7WCsd0WHi0tcJBwwIff+5GccvX4G6dbze/uw9v7GnKavkEMB2FBGUCuTmyParhyh940 8Zfvk/5k1wSHMHIQROHvCSIGjY5vNfXl2v//if6ml/0z9k0OCYLUTPoECXdz3KnA6cVc eA2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682519516; x=1685111516; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vnK/SQhANKndFlUcYbR0hF8iVMTmuDEOvt9GxJcZpxE=; b=DrbOTDSCLZznTM9xORY11ka3Zlgt8EfMsmp6EXl9yTuepgLbfDAs470ElKs59g4/Lk eOXvhv0cv0CX0ubaMN9SfNAGx0F8go2XqFU8fYVhAbiN3bTOxO0hQVRdLt3WcG1b13Ik 6NIgs2Eg6uZVYKjlFk7fHuDOj+s8okx5NFgFBMwavKwB+4oTqrKLsr3yr1FdAceYKgXq LEbimAlLDxjlhbvf8c+nltYLdnS99jaMGxitTqRFV6SIyEaimQPeJSLt1O4E/MNDHPMT xxx983llVQc6anO4G1kvv2Q9hSOMgLQZ0wwv4oLKnYklMTcZAztSvCEo+SwLPTRNWzWJ 9GaQ== X-Gm-Message-State: AAQBX9eyzMR4QAc/8ce8542Uu23s64UaVYqNC2KgtIhspAUuby2AfxQg DlptZMsZq1g46dv3IC7GhoY/PnnRGys= X-Google-Smtp-Source: AKy350YUFWRuRfpb0gEpPuU6JH2KrWwADBweiOgbOipifOm3zHMtpoWRgsxs0ZbA1Pvu5yHWYo6d5g== X-Received: by 2002:a1c:f703:0:b0:3f1:71b2:9445 with SMTP id v3-20020a1cf703000000b003f171b29445mr14633487wmh.15.1682519515832; Wed, 26 Apr 2023 07:31:55 -0700 (PDT) Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id h3-20020a5d5043000000b002c70ce264bfsm15938704wrt.76.2023.04.26.07.31.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 07:31:55 -0700 (PDT) From: Robert Pluim In-Reply-To: <87jzxysw06.fsf@gmail.com> (Robert Pluim's message of "Wed, 26 Apr 2023 13:50:17 +0200") References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87jzxysw06.fsf@gmail.com> Date: Wed, 26 Apr 2023 16:31:54 +0200 Message-ID: <877ctysoit.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Wed, 26 Apr 2023 13:50:17 +0200, Robert Pluim s= aid: >>>>> On Wed, 26 Apr 2023 12:56:39 +0200, Vasilij Schneidermann said: Vasilij> Thank you. Yes, that is the case, the network process is no lo= nger shut Vasilij> down, but the 0-length message isn't picked up. It prints the = following: Vasilij> Received string (5): "hello" Vasilij> Received string (5): "world" Vasilij> Rather than the expected: Vasilij> Received string (5): "hello" Vasilij> Received string (0): "" Vasilij> Received string (5): "world" Robert> Right. Getting emacs to deliver a zero length string to the UDP Robert> process would be quite a change, one I can=CA=BCt get to any ti= me soon. Actually, it turned out to be a small change (on top of my previous patch) diff --git a/src/process.c b/src/process.c index e3233f5ad89..eca1441062d 100644 --- a/src/process.c +++ b/src/process.c @@ -6305,7 +6305,13 @@ read_and_dispose_of_process_output (struct Lisp_Proc= ess *p, char *chars, coding->carryover_bytes); p->decoding_carryover =3D coding->carryover_bytes; } - if (SBYTES (text) > 0) + if (SBYTES (text) > 0 +#ifdef DATAGRAM_SOCKETS + || (SBYTES (text) =3D=3D 0 + && 0 <=3D p->outfd + && DATAGRAM_CHAN_P (p->outfd)) +#endif + ) /* FIXME: It's wrong to wrap or not based on debug-on-error, and sometimes it's simply wrong to wrap (e.g. when called from accept-process-output). */ Robert --=20 From unknown Thu Aug 14 22:18:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet Resent-From: Vasilij Schneidermann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Mar 2024 13:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Robert Pluim Cc: 62990@debbugs.gnu.org Received: via spool by 62990-submit@debbugs.gnu.org id=B62990.170999170624725 (code B ref 62990); Sat, 09 Mar 2024 13:42:02 +0000 Received: (at 62990) by debbugs.gnu.org; 9 Mar 2024 13:41:46 +0000 Received: from localhost ([127.0.0.1]:60937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riwxO-0006Qj-6P for submit@debbugs.gnu.org; Sat, 09 Mar 2024 08:41:46 -0500 Received: from mout-p-101.mailbox.org ([80.241.56.151]:59866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riwxI-0006QL-O5 for 62990@debbugs.gnu.org; Sat, 09 Mar 2024 08:41:44 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4TsPLP54qRz9snG; Sat, 9 Mar 2024 14:40:29 +0100 (CET) Date: Sat, 9 Mar 2024 14:40:28 +0100 From: Vasilij Schneidermann Message-ID: References: <87wn21br45.fsf@gmail.com> <87ttx49yg0.fsf@gmail.com> <87jzxysw06.fsf@gmail.com> <877ctysoit.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kQ24buBBC3bcmINb" Content-Disposition: inline In-Reply-To: <877ctysoit.fsf@gmail.com> X-Rspamd-Queue-Id: 4TsPLP54qRz9snG X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --kQ24buBBC3bcmINb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello again, > Actually, it turned out to be a small change (on top of my previous > patch) >=20 > diff --git a/src/process.c b/src/process.c > index e3233f5ad89..eca1441062d 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -6305,7 +6305,13 @@ read_and_dispose_of_process_output (struct Lisp_Pr= ocess *p, char *chars, > coding->carryover_bytes); > p->decoding_carryover =3D coding->carryover_bytes; > } > - if (SBYTES (text) > 0) > + if (SBYTES (text) > 0 > +#ifdef DATAGRAM_SOCKETS > + || (SBYTES (text) =3D=3D 0 > + && 0 <=3D p->outfd > + && DATAGRAM_CHAN_P (p->outfd)) > +#endif > + ) > /* FIXME: It's wrong to wrap or not based on debug-on-error, and > sometimes it's simply wrong to wrap (e.g. when called from > accept-process-output). */ I somehow completely overlooked this second patch and can confirm that with it, both the Emacs Lisp and Guile version of the server/client behave identically. In other words, the UDP bug is completely fixed now. I've done a cursory search on the web and did not find anything that would send empty packets via UDP, so I do doubt it would break existing code or need a opt-out setting. --kQ24buBBC3bcmINb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAmXsZskACgkQFmfJg6zC ifpgCQgAk7O293XsjhBsSmuN64BOUP7UCtJjJYgvW427nRWHwNQjsr/fBwDCwqRe wMDXDvD/sk0uD8wVlwGcynE5hIMf3Ayg837fJr8jE9DU8h+zqpwLuwDhyPykPFAA W+vePoWx4I6NZTyISh2mYxlCHwnuqMfsfR7TmNAgGCnnIf9bOdUq2j/zaZIo5aXf 7DpmTBXdyyZRSULi/mqBFmvToaCtiuCZsVstJLAczAeXimE1IRawxoWDSh+gy7qN JzZ73x+l6uCg2RP8iL49Z347totVHcSSeNr+0Fps6Z7M31A98T0VXGBUIPKKAVW1 9vcx7yjgN/lM0dPHUyygY9ge/Wc5Vg== =//17 -----END PGP SIGNATURE----- --kQ24buBBC3bcmINb--