GNU bug report logs -
#74907
31.0.50; nsm-check-local-subnet-ipv4 test fails on macOS with VPN enabled
Previous Next
Reported by: Stefan Kangas <stefankangas <at> gmail.com>
Date: Mon, 16 Dec 2024 02:05:02 UTC
Severity: normal
Tags: fixed
Found in version 31.0.50
Fixed in version 31.1
Done: Robert Pluim <rpluim <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #23 received at 74907 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Mon, 16 Dec 2024 21:55:33 +0000, Stefan Kangas <stefankangas <at> gmail.com> said:
>
> Stefan> I don't see a difference there.
>
> Stefan> ;; With VPN
> Stefan> (network-lookup-address-info "localhost")
> Stefan> => ([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])
>
> Stefan> (network-lookup-address-info "127.0.0.1")
> Stefan> => ([127 0 0 1 0])
>
> Stefan> ;; Without VPN
> Stefan> (network-lookup-address-info "localhost")
> Stefan> => ([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])
>
> Stefan> (network-lookup-address-info "127.0.0.1")
> Stefan> => ([127 0 0 1 0])
>
> In an interactive session or -batch?
In an interactive session. I tried now in batch too, using this:
./src/emacs -Q -batch -eval '(progn (princ (network-lookup-address-info
"localhost")) (terpri) (princ (network-lookup-address-info
"127.0.0.1")))'
;; With VPN
([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])
([127 0 0 1 0])
;; Without VPN
([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])
([127 0 0 1 0])
> Anyway, hereʼs a wild stab in the dark based on the only code path I
> could see that would give your original output. If that works Iʼd like
> to know which VPN client youʼre using so I can avoid it 😀
It didn't work, unfortunately.
However, I now see that I made a mistake in my original recipe to
reproduce this: I didn't bind 'nsm-trust-local-network'.
I can reproduce the backtrace consistently by evaluating this in an
interactive session:
(let ((nsm-trust-local-network t))
(should (eq t (nsm-should-check "example.org"))))
This allowed edebugging this, and I see that the backtrace comes from
nsm.el:238, where we do:
(substring (nth 3 info) 0 -1)
With a VPN, `info` is bound to this when I get the backtrace:
("utun0"
[10 0 0 1 0]
(0 . [0 0 10 255 255 255 16 2 0 0 10 0 0 1])
(0 . [0 0 255 0 0 0 16 2 0 0 10 0 0 1]))
Without a VPN, `info` is bound to this instead:
("utun6"
[65153 0 0 0 6123 19123 32345 45123 0]
[65153 0 0 0 65535 65535 65535 65535 0]
[65535 65535 65535 65535 0 0 0 0 0])
Clearly, this will not work:
(substring '(0 . [1 2 3 4]) 0 -1)
So the question is why `network-interface-list` would return such an
unusual value here.
This bug report was last modified 150 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.