GNU bug report logs - #45798
28.0.50; nsm-check-local-subnet-ipv4 fails with nsm-trust-local-network

Previous Next

Package: emacs;

Reported by: "Basil L. Contovounesios" <contovob <at> tcd.ie>

Date: Mon, 11 Jan 2021 19:26:01 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: Robert Pluim <rpluim <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 45798 <at> debbugs.gnu.org
Subject: bug#45798: 28.0.50; nsm-check-local-subnet-ipv4 fails with nsm-trust-local-network
Date: Mon, 11 Jan 2021 21:33:53 +0100
"Basil L. Contovounesios" <contovob <at> 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




This bug report was last modified 4 years and 52 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.