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

Message #11 received at 45798 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 45798 <at> debbugs.gnu.org
Subject: Re: bug#45798: 28.0.50; nsm-check-local-subnet-ipv4 fails with
 nsm-trust-local-network
Date: Mon, 11 Jan 2021 23:03:21 +0000

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

> "Basil L. Contovounesios" <contovob <at> 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
This bug report was last modified 4 years and 51 days ago.

Previous Next

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