bug#45798: 28.0.50; nsm-check-local-subnet-ipv4 fails with nsm-trust-local-network

[Robert Pluim]

"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