I've been consistently seeing the following error when running 'make check' for a while. It corresponds to the line in nsm-tests.el where nsm-trust-local-network is bound to t. --8<---------------cut here---------------start------------->8--- Running 2 tests (2021-01-11 18:36:03+0000, selector ‘(not (or (tag :expensive-test) (tag :unstable)))’) Test nsm-check-local-subnet-ipv4 backtrace: signal(ert-test-failed (((should (eq t (nsm-should-check "google.com ert-fail(((should (eq t (nsm-should-check "google.com"))) :form (eq #f(compiled-function () #<bytecode -0x1350ea665394e069>)() ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name nsm-check-local-subnet-ipv4 :document ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :expensi ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable))) ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) ( command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/nsm-tests" "--ev command-line() normal-top-level() Test nsm-check-local-subnet-ipv4 condition: (ert-test-failed ((should (eq t (nsm-should-check "google.com"))) :form (eq t nil) :value nil)) FAILED 1/2 nsm-check-local-subnet-ipv4 (0.056046 sec) passed 2/2 nsm-check-local-subnet-ipv6 (0.000694 sec) Ran 2 tests, 1 results as expected, 1 unexpected (2021-01-11 18:36:03+0000, 0.196751 sec) 1 unexpected results: FAILED nsm-check-local-subnet-ipv4 --8<---------------cut here---------------end--------------->8--- I stepped through nsm-should-check a bit, but I don't understand what is or should be happening. The test fails when local var off-net is set to nil, which happens when nsm-network-same-subnet returns non-nil. This happens with the following local var values: ip: [0 0 0 0 0 0 0 1 0] info: (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] [65535 65535 65535 65535 65535 65535 65535 65535 0]) addresses: ([0 0 0 0 0 0 0 1 0]) network-interface-list: ((wlp3s0 [65152 0 0 0 38609 2370 19874 38730 0] [65152 0 0 0 65535 65535 65535 65535 0] [65535 65535 65535 65535 0 0 0 0 0]) (wlp3s0 [10754 32900 8418 50048 62480 33512 14881 61151 0] [10754 32900 8418 50048 65535 65535 65535 65535 0] [65535 65535 65535 65535 0 0 0 0 0]) (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] [65535 65535 65535 65535 65535 65535 65535 65535 0]) (wlp3s0 [192 168 0 144 0] [192 168 0 255 0] [255 255 255 0 0]) (lo [127 0 0 1 0] [127 255 255 255 0] [255 0 0 0 0])) I've observed that the test fails only on my home network. I've heard that my ISP and the modem they provide use a weird dual IPv6 stack that has caused people problems in the past, but I know next to nothing about these things and can't say if it's related to the issue at hand. Another observation is that the test succeeds if I replace "google.com" with "gnu.org". Should I just change the test to use "gnu.org", and forget about this? Or is there some interesting issue here? Any suggestions or guidance are very welcome. Here's my /etc/resolv.conf, in case it matters: # Generated by NetworkManager nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 2001:4860:4860::8888 # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 2001:4860:4860::8844 [ I've been pointing my DNS settings to Google ever since I spent some months in a country with very poor network services. ] Thanks, -- Basil In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2021-01-11 built on tia Repository revision: fcf8ad610d43ba9b96d9ad1cc67185144c819006 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12010000 System Description: Debian GNU/Linux bullseye/sid Configured using: 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache --prefix=/home/blc/.local --enable-checking=structs --with-x-toolkit=lucid --with-file-notification=yes --with-x' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XPM LUCID ZLIB Important settings: value of $LANG: en_IE.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv 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 iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo x-toolkit x multi-tty make-network-process emacs)
"Basil L. Contovounesios" <contovob@tcd.ie> writes: > I've been consistently seeing the following error when running 'make > check' for a while. It corresponds to the line in nsm-tests.el where > nsm-trust-local-network is bound to t. > > I stepped through nsm-should-check a bit, but I don't understand what is > or should be happening. The test fails when local var off-net is set to > nil, which happens when nsm-network-same-subnet returns non-nil. This > happens with the following local var values: > > ip: [0 0 0 0 0 0 0 1 0] > > info: (lo [0 0 0 0 0 0 0 1 0] > [0 0 0 0 0 0 0 1 0] > [65535 65535 65535 65535 65535 65535 65535 65535 0]) > > addresses: ([0 0 0 0 0 0 0 1 0]) > There is no way that 'network-lookup-address-info' on google.com should return ::1. You donʼt have a spare entry lying around in /etc/hosts for google.com by any chance? What do you get for (network-lookup-address-info "google.com") (network-lookup-address-info "google.com" 'ipv4) (network-lookup-address-info "google.com" 'ipv6) How about: (require 'dns) (dns-query "google.com" 'A) (dns-query "google.com" 'AAAA) > network-interface-list: > ((wlp3s0 [65152 0 0 0 38609 2370 19874 38730 0] > [65152 0 0 0 65535 65535 65535 65535 0] > [65535 65535 65535 65535 0 0 0 0 0]) > (wlp3s0 [10754 32900 8418 50048 62480 33512 14881 61151 0] > [10754 32900 8418 50048 65535 65535 65535 65535 0] > [65535 65535 65535 65535 0 0 0 0 0]) > (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] > [65535 65535 65535 65535 65535 65535 65535 65535 0]) > (wlp3s0 [192 168 0 144 0] [192 168 0 255 0] [255 255 255 0 0]) > (lo [127 0 0 1 0] [127 255 255 255 0] [255 0 0 0 0])) > > I've observed that the test fails only on my home network. I've heard > that my ISP and the modem they provide use a weird dual IPv6 stack that > has caused people problems in the past, but I know next to nothing about > these things and can't say if it's related to the issue at hand. > Most IPv6 stacks are dual stack IPv4/IPv6. Do they mean they're doing IPv4 in IPv6 in some way? Which ISP is this? > Another observation is that the test succeeds if I replace "google.com" > with "gnu.org". Should I just change the test to use "gnu.org", and > forget about this? Or is there some interesting issue here? Any > suggestions or guidance are very welcome. > > Here's my /etc/resolv.conf, in case it matters: > > # Generated by NetworkManager > nameserver 8.8.8.8 > nameserver 8.8.4.4 > nameserver 2001:4860:4860::8888 > # NOTE: the libc resolver may not support more than 3 nameservers. > # The nameservers listed below may not be recognized. > nameserver 2001:4860:4860::8844 And what do you get for dig -t A google.com dig -t AAAA google.com This might be interesting as well: ping -6 google.com
Robert Pluim <rpluim@gmail.com> writes: > "Basil L. Contovounesios" <contovob@tcd.ie> writes: > >> I stepped through nsm-should-check a bit, but I don't understand what is >> or should be happening. The test fails when local var off-net is set to >> nil, which happens when nsm-network-same-subnet returns non-nil. This >> happens with the following local var values: >> >> ip: [0 0 0 0 0 0 0 1 0] >> >> info: (lo [0 0 0 0 0 0 0 1 0] >> [0 0 0 0 0 0 0 1 0] >> [65535 65535 65535 65535 65535 65535 65535 65535 0]) >> >> addresses: ([0 0 0 0 0 0 0 1 0]) > > There is no way that 'network-lookup-address-info' on google.com > should return ::1. Oops, sorry! I must have been looking at the wrong value. There are two cases where nsm-network-same-subnet returns non-nil, and in both cases: addresses: ([10752 5200 16395 3073 0 0 0 139 0] [10752 5200 16395 3073 0 0 0 113 0] [10752 5200 16395 3073 0 0 0 138 0] [10752 5200 16395 3073 0 0 0 100 0] [74 125 193 139 0] [74 125 193 101 0] [74 125 193 102 0] [74 125 193 138 0] [74 125 193 100 0] [74 125 193 113 0]) network-interface-list: ((wlp3s0 [65152 0 0 0 38609 2370 19874 38730 0] [65152 0 0 0 65535 65535 65535 65535 0] [65535 65535 65535 65535 0 0 0 0 0]) (wlp3s0 [10754 32900 8418 50048 62480 33512 14881 61151 0] [10754 32900 8418 50048 65535 65535 65535 65535 0] [65535 65535 65535 65535 0 0 0 0 0]) (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] [65535 65535 65535 65535 65535 65535 65535 65535 0]) (wlp3s0 [192 168 0 144 0] [192 168 0 255 0] [255 255 255 0 0]) (lo [127 0 0 1 0] [127 255 255 255 0] [255 0 0 0 0])) info: (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] [65535 65535 65535 65535 65535 65535 65535 65535 0]) The only difference is in 'ip': 1. [10752 5200 16395 3073 0 0 0 139 0] 2. [10752 5200 16395 3073 0 0 0 113 0] > You donʼt have a spare entry lying around in > /etc/hosts for google.com by any chance? C-x i /etc/hosts RET: 127.0.0.1 localhost 127.0.1.1 tia # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters > What do you get for > > (network-lookup-address-info "google.com") ([10752 5200 16395 3073 0 0 0 139 0] [10752 5200 16395 3073 0 0 0 138 0] [10752 5200 16395 3073 0 0 0 102 0] [10752 5200 16395 3073 0 0 0 100 0] [74 125 193 100 0] [74 125 193 102 0] [74 125 193 138 0] [74 125 193 101 0] [74 125 193 113 0] [74 125 193 139 0]) > (network-lookup-address-info "google.com" 'ipv4) ([74 125 193 100 0] [74 125 193 138 0] [74 125 193 139 0] [74 125 193 113 0] [74 125 193 101 0] [74 125 193 102 0]) > (network-lookup-address-info "google.com" 'ipv6) ([10752 5200 16395 3073 0 0 0 102 0] [10752 5200 16395 3073 0 0 0 113 0] [10752 5200 16395 3073 0 0 0 139 0] [10752 5200 16395 3073 0 0 0 101 0]) > How about: > > (require 'dns) > (dns-query "google.com" 'A) "74.125.193.139" > (dns-query "google.com" 'AAAA) "2a00:1450:400b:c01:0:0:0:65" >> network-interface-list: >> ((wlp3s0 [65152 0 0 0 38609 2370 19874 38730 0] >> [65152 0 0 0 65535 65535 65535 65535 0] >> [65535 65535 65535 65535 0 0 0 0 0]) >> (wlp3s0 [10754 32900 8418 50048 62480 33512 14881 61151 0] >> [10754 32900 8418 50048 65535 65535 65535 65535 0] >> [65535 65535 65535 65535 0 0 0 0 0]) >> (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] >> [65535 65535 65535 65535 65535 65535 65535 65535 0]) >> (wlp3s0 [192 168 0 144 0] [192 168 0 255 0] [255 255 255 0 0]) >> (lo [127 0 0 1 0] [127 255 255 255 0] [255 0 0 0 0])) >> >> I've observed that the test fails only on my home network. I've heard >> that my ISP and the modem they provide use a weird dual IPv6 stack that >> has caused people problems in the past, but I know next to nothing about >> these things and can't say if it's related to the issue at hand. > > Most IPv6 stacks are dual stack IPv4/IPv6. Do they mean they're doing > IPv4 in IPv6 in some way? Sorry, I don't know. Is there a way to find out that doesn't involve contacting them (which I never look forward to :)? > Which ISP is this? Virgin Media in Ireland. >> Another observation is that the test succeeds if I replace "google.com" >> with "gnu.org". Should I just change the test to use "gnu.org", and >> forget about this? Or is there some interesting issue here? Any >> suggestions or guidance are very welcome. >> >> Here's my /etc/resolv.conf, in case it matters: >> >> # Generated by NetworkManager >> nameserver 8.8.8.8 >> nameserver 8.8.4.4 >> nameserver 2001:4860:4860::8888 >> # NOTE: the libc resolver may not support more than 3 nameservers. >> # The nameservers listed below may not be recognized. >> nameserver 2001:4860:4860::8844 > > And what do you get for > > dig -t A google.com ; <<>> DiG 9.16.8-Debian <<>> -t A google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32726 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 61 IN A 74.125.193.113 google.com. 61 IN A 74.125.193.100 google.com. 61 IN A 74.125.193.139 google.com. 61 IN A 74.125.193.102 google.com. 61 IN A 74.125.193.101 google.com. 61 IN A 74.125.193.138 ;; Query time: 24 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Jan 11 21:10:49 GMT 2021 ;; MSG SIZE rcvd: 135 > dig -t AAAA google.com ; <<>> DiG 9.16.8-Debian <<>> -t AAAA google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6510 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com. IN AAAA ;; ANSWER SECTION: google.com. 41 IN AAAA 2a00:1450:400b:c01::8b google.com. 41 IN AAAA 2a00:1450:400b:c01::71 google.com. 41 IN AAAA 2a00:1450:400b:c01::64 google.com. 41 IN AAAA 2a00:1450:400b:c01::8a ;; Query time: 32 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Jan 11 21:11:03 GMT 2021 ;; MSG SIZE rcvd: 151 > This might be interesting as well: > > ping -6 google.com ping -6 google.com PING google.com(2a00:1450:400b:c01::66 (2a00:1450:400b:c01::66)) 56 data bytes 64 bytes from 2a00:1450:400b:c01::66 (2a00:1450:400b:c01::66): icmp_seq=1 ttl=107 time=12.7 ms 64 bytes from 2a00:1450:400b:c01::66 (2a00:1450:400b:c01::66): icmp_seq=2 ttl=107 time=18.6 ms [...] FWIW, this also happened on my older laptop, not just this new one I'm writing from. Both run the same suite of Debian, Systemd, NetworkManager, etc. Let me know what else I can do, and thanks for your help, -- Basil
"Basil L. Contovounesios" <contovob@tcd.ie> writes: > Oops, sorry! I must have been looking at the wrong value. There are > two cases where nsm-network-same-subnet returns non-nil, and in both > cases: > > addresses: > ([10752 5200 16395 3073 0 0 0 139 0] > [10752 5200 16395 3073 0 0 0 113 0] > [10752 5200 16395 3073 0 0 0 138 0] > [10752 5200 16395 3073 0 0 0 100 0] > [74 125 193 139 0] [74 125 193 101 0] > [74 125 193 102 0] [74 125 193 138 0] > [74 125 193 100 0] [74 125 193 113 0]) > > network-interface-list: > ((wlp3s0 [65152 0 0 0 38609 2370 19874 38730 0] > [65152 0 0 0 65535 65535 65535 65535 0] > [65535 65535 65535 65535 0 0 0 0 0]) > (wlp3s0 [10754 32900 8418 50048 62480 33512 14881 61151 0] > [10754 32900 8418 50048 65535 65535 65535 65535 0] > [65535 65535 65535 65535 0 0 0 0 0]) > (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] > [65535 65535 65535 65535 65535 65535 65535 65535 0]) > (wlp3s0 [192 168 0 144 0] [192 168 0 255 0] [255 255 255 0 0]) > (lo [127 0 0 1 0] [127 255 255 255 0] [255 0 0 0 0])) > > info: > (lo [0 0 0 0 0 0 0 1 0] [0 0 0 0 0 0 0 1 0] > [65535 65535 65535 65535 65535 65535 65535 65535 0]) > > The only difference is in 'ip': > > 1. [10752 5200 16395 3073 0 0 0 139 0] > 2. [10752 5200 16395 3073 0 0 0 113 0] What idiot wrote this code? Try this patch: diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el index 3f3e713371..0ce65a35ea 100644 --- a/lisp/net/nsm.el +++ b/lisp/net/nsm.el @@ -239,7 +239,7 @@ nsm-should-check (mapc (lambda (info) (let ((local-ip (nth 1 info)) - (mask (nth 2 info))) + (mask (nth 3 info))) (when (nsm-network-same-subnet (substring local-ip 0 -1) (substring mask 0 -1)
Robert Pluim <rpluim@gmail.com> writes: > What idiot wrote this code? Impossible to know, I guess we'll never find out. > Try this patch: That does the trick, thanks! -- Basil
tags 45798 fixed close 45798 28.1 quit "Basil L. Contovounesios" <contovob@tcd.ie> writes: > Robert Pluim <rpluim@gmail.com> writes: > >> What idiot wrote this code? > > Impossible to know, I guess we'll never find out. > Let's hope nobody looks at the git history. >> Try this patch: > > That does the trick, thanks! Pushed as 6dc4fc7d62 Closing
Hi!
We're seeing this failure as well in Debian on 32-bit PowerPC [1]:
Test nsm-check-local-subnet-ipv4 condition:
(ert-test-failed
((should
(eq t
(nsm-should-check "google.com")))
:form
(eq t nil)
:value nil))
FAILED 1/2 nsm-check-local-subnet-ipv4 (0.002883 sec)
passed 2/2 nsm-check-local-subnet-ipv6 (0.000447 sec)
Ran 2 tests, 1 results as expected, 1 unexpected (2021-03-30 13:14:28+0000, 0.164994 sec)
1 unexpected results:
FAILED nsm-check-local-subnet-ipv4
Any chance that this is the same bug?
Thanks,
Adrian
> [1] https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=powerpc&ver=1%3A27.1%2B1-3.1&stamp=1617110198&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>>>>> On Tue, 30 Mar 2021 16:27:18 +0200, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> said:
John> Hi!
John> We're seeing this failure as well in Debian on 32-bit PowerPC [1]:
John> Test nsm-check-local-subnet-ipv4 condition:
John> (ert-test-failed
John> ((should
John> (eq t
John> (nsm-should-check "google.com")))
John> :form
John> (eq t nil)
John> :value nil))
John> FAILED 1/2 nsm-check-local-subnet-ipv4 (0.002883 sec)
John> passed 2/2 nsm-check-local-subnet-ipv6 (0.000447 sec)
John> Ran 2 tests, 1 results as expected, 1 unexpected (2021-03-30 13:14:28+0000, 0.164994 sec)
John> 1 unexpected results:
John> FAILED nsm-check-local-subnet-ipv4
John> Any chance that this is the same bug?
Yes, itʼs the same bug.
commit 6dc4fc7d62 from the emacs repository will fix it, and should
apply without issues to emacs-27 if you want to carry a local patch.
Robert
--
Hello Robert!
On 3/30/21 5:16 PM, Robert Pluim wrote:
> John> Any chance that this is the same bug?
>
> Yes, itʼs the same bug.
>
> commit 6dc4fc7d62 from the emacs repository will fix it, and should
> apply without issues to emacs-27 if you want to carry a local patch.
Thank you very much. That was the information I was looking for :-).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>>>>> On Tue, 30 Mar 2021 17:18:15 +0200, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> said:
John> Hello Robert!
John> On 3/30/21 5:16 PM, Robert Pluim wrote:
John> Any chance that this is the same bug?
>>
>> Yes, itʼs the same bug.
>>
>> commit 6dc4fc7d62 from the emacs repository will fix it, and should
>> apply without issues to emacs-27 if you want to carry a local patch.
John> Thank you very much. That was the information I was looking for :-).
$ git log --grep Bug#45798
commit 6dc4fc7d621008086388dae48f6794f7d69edff9
Author: Robert Pluim <rpluim@gmail.com>
Date: Tue Jan 12 18:36:01 2021 +0100
:-)
Robert
--