GNU bug report logs -
#45798
28.0.50; nsm-check-local-subnet-ipv4 fails with nsm-trust-local-network
Previous Next
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
"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.