Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

2023-07-25 Thread Samuel Henrique
After some investigation I found out the commit that introduces the
regression[0].

I have added a comment to the GitHub issue with the details:
https://github.com/nmap/nmap/issues/2685#issuecomment-1650519127

There's also an interesting finding that reproduction can only be
achieved through scripts, I wasn't able to reproduce it manually on an
interactive bash session.

[0] https://github.com/nmap/nmap/commit/4e6c8feb153c0c9ff8a68cd841669d650319ab45

Thank you, everyone!

-- 
Samuel Henrique 



Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

2023-07-23 Thread Gordon Fyodor Lyon
Thanks Paul.  We did make some changes in Nmap 7.94 which could have caused
regressions.  I've opened an issue for this on our upstream tracker (
https://github.com/nmap/nmap/issues/2685).  Please let us know if you
figure anything else out.

-Gordon


Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

2023-07-23 Thread Paul Wise
On Tue, 27 Jun 2023 21:40:14 +0200 Paul Gevers wrote:

> Source: nmap, udptunnel
> Control: found -1 nmap/7.94+dfsg1-1
> Control: found -1 udptunnel/1.1-9
...
> With a recent upload of nmap the autopkgtest of udptunnel fails in 
> testing when that autopkgtest is run with the binary packages of nmap 
> from unstable. It passes when run with only packages from testing.

I think this is likely to be a bug in nmap ncat, when I remove
udptunnel from the script by connecting ncat directly to ncat,
then the failure still happens with the autopkgtest.

I was able to reproduce this issue outside a chroot. I have attached a
pair of scripts; bad fails and good succeeds. In the good case, I use
`sleep` to hold stdin of `ncat -l` open for 2s, in the bad case I let
it use the stdin provided by the shell (a GNOME terminal pty here).

Looking at the diff between the verbose logs is interesting.
In the good case one select fd is ready and one becomes ready later,
the latter one gets used, but in the bad case both fds appear to be
ready immediately but neither of them get used.

-NCAT DEBUG: select returned 1 fds ready
-NCAT DEBUG: fd 3 is ready
-NCAT DEBUG: selecting, fdmax 3
-NCAT DEBUG: select returned 1 fds ready
+NCAT DEBUG: select returned 2 fds ready

So the issue can be worked around in the udptunnel script by piping
sleep to the ncat listener instead of launching ncat and then sleeping,
or the ncat change that caused this can get bisected and fixed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


bad
Description: application/shellscript
+ rm rx tx
+ echo foo
+ sleep 2s
+ ncat - -u -l 127.0.0.1 1234
Ncat: Version 7.94 ( https://nmap.org/ncat )
NCAT DEBUG: Initialized fdlist with 102 maxfds
Ncat: Listening on 127.0.0.1:1234
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: Added fd 0 to list, nfds 2, maxfd 3
NCAT DEBUG: Initialized fdlist with 100 maxfds
NCAT DEBUG: selecting, fdmax 3
+ ncat -u 127.0.0.1 1234
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 3 is ready
NCAT DEBUG: Swapping fd[0] (3) with fd[1] (0)
NCAT DEBUG: Removed fd 3 from list, nfds 1, maxfd 0
Ncat: Connection from 127.0.0.1:57558.
NCAT DEBUG: Added fd 3 to list, nfds 2, maxfd 3
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: selecting, fdmax 3
NCAT DEBUG: select returned 2 fds ready
NCAT DEBUG: fd 0 is ready
NCAT DEBUG: EOF on stdin
+ sleep 2s
+ head -vn-0 tx rx
==> tx <==
foo

==> rx <==
+ echo tx
tx
+ hd tx
  66 6f 6f 0a   |foo.|
0004
+ echo rx
rx
+ hd rx
+ echo diff
diff
+ diff -u tx rx
--- tx	2023-07-23 16:49:32.411502343 +0800
+++ rx	2023-07-23 16:49:32.411502343 +0800
@@ -1 +0,0 @@
-foo


good
Description: application/shellscript
+ rm rx tx
+ echo foo
+ + sleep 2sncat
 -u 127.0.0.1 1234
+ ncat - -u -l 127.0.0.1 1234
Ncat: Version 7.94 ( https://nmap.org/ncat )
NCAT DEBUG: Initialized fdlist with 102 maxfds
Ncat: Listening on 127.0.0.1:1234
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: Added fd 0 to list, nfds 2, maxfd 3
NCAT DEBUG: Initialized fdlist with 100 maxfds
NCAT DEBUG: selecting, fdmax 3
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 3 is ready
NCAT DEBUG: Swapping fd[0] (3) with fd[1] (0)
NCAT DEBUG: Removed fd 3 from list, nfds 1, maxfd 0
Ncat: Connection from 127.0.0.1:36688.
NCAT DEBUG: Added fd 3 to list, nfds 2, maxfd 3
NCAT DEBUG: Added fd 3 to list, nfds 1, maxfd 3
NCAT DEBUG: selecting, fdmax 3
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 3 is ready
NCAT DEBUG: selecting, fdmax 3
+ sleep 2s
NCAT DEBUG: select returned 1 fds ready
NCAT DEBUG: fd 0 is ready
NCAT DEBUG: EOF on stdin
+ head -vn-0 tx rx
==> tx <==
foo

==> rx <==
foo
+ echo tx
tx
+ hd tx
  66 6f 6f 0a   |foo.|
0004
+ echo rx
rx
+ hd rx
  66 6f 6f 0a   |foo.|
0004
+ echo diff
diff
+ diff -u tx rx


signature.asc
Description: This is a digitally signed message part


Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed

2023-06-27 Thread Paul Gevers

Source: nmap, udptunnel
Control: found -1 nmap/7.94+dfsg1-1
Control: found -1 udptunnel/1.1-9
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of nmap the autopkgtest of udptunnel fails in 
testing when that autopkgtest is run with the binary packages of nmap 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
nmap   from testing7.94+dfsg1-1
udptunnel  from testing1.1-9
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of nmap to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=nmap

https://ci.debian.net/data/autopkgtest/testing/amd64/u/udptunnel/34896613/log.gz

33s udp0  0 127.0.0.1:5500  0.0.0.0:*
36s tcp0  0 0.0.0.0:64910.0.0.0:* 
LISTEN
39s udp0  0 0.0.0.0:66610.0.0.0:* 
   39s 1,7d0

39s < THIS
39s <  IS
39s <   THE
39s