bug#74907: 31.0.50; nsm-check-local-subnet-ipv4 test fails on macOS with VPN enabled

bug#74907: 31.0.50; nsm-check-local-subnet-ipv4 test fails on macOS with VPN enabled

[Stefan Kangas]

I see the below test failure when running with a VPN enabled on macOS.
It fails predictably every time, but when I disable the VPN, the test
passes.

Looking into it, it seems like it's this call that leads to the
backtrace:

    (nsm-should-check "localhost")

However, when edebugging `nsm-should-check` and step through the code, I
do not get a backtrace, and it correctly returns t.

Any ideas for how to continue debugging this?


Running 2 tests (2024-12-16 02:41:49+0100, selector ‘(not (or (tag
:expensive-test) (tag :unstable) (tag :nativecomp)))’)
Test nsm-check-local-subnet-ipv4 backtrace:
  signal(wrong-type-argument (arrayp (0 . [0 0 255 0 0 0 16 2 0 0 10 1
  signal(wrong-type-argument (arrayp (0 . [0 0 255 0 0 0 16 2 0 0 10 1
  apply(signal (wrong-type-argument (arrayp (0 . [0 0 255 0 0 0 16 2 0
  #f(compiled-function () #<bytecode 0xb0a4a42ef70c609>)()
  #f(compiled-function () #<bytecode 0x14ecd754278a5065>)()
  handler-bind-1(#f(compiled-function () #<bytecode 0x14ecd754278a5065
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name nsm-check-local-subnet-ipv4 :document
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :expensi
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "--eval" "(setq treesit-extra-l
  command-line()
  normal-top-level()
Test nsm-check-local-subnet-ipv4 condition:
    (wrong-type-argument arrayp (0 . [0 0 255 0 0 0 16 2 0 0 ...]))
   FAILED  1/2  nsm-check-local-subnet-ipv4 (0.021312 sec) at
lisp/net/nsm-tests.el:30
  skipped  2/2  nsm-check-local-subnet-ipv6 (0.000127 sec)

Ran 2 tests, 0 results as expected, 1 unexpected, 1 skipped
(2024-12-16 02:41:49+0100, 0.108002 sec)

1 unexpected results:
   FAILED  nsm-check-local-subnet-ipv4

1 skipped results:
  SKIPPED  nsm-check-local-subnet-ipv6


In GNU Emacs 31.0.50 (build 17, aarch64-apple-darwin24.1.0, NS
 appkit-2575.20 Version 15.1.1 (Build 24B91)) of 2024-12-16 built on
 foo.local
Repository revision: 29058579e9f27872d47e9d5146dfd9ce79697a0d
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.1.1

Configured using:
 'configure --without-dbus'

bug#74907: 31.0.50; nsm-check-local-subnet-ipv4 test fails on macOS with VPN enabled

[Robert Pluim]

>>>>> On Mon, 16 Dec 2024 02:03:53 +0000, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> I see the below test failure when running with a VPN enabled on macOS.
    Stefan> It fails predictably every time, but when I disable the VPN, the test
    Stefan> passes.

    Stefan> Looking into it, it seems like it's this call that leads to the
    Stefan> backtrace:

    Stefan>     (nsm-should-check "localhost")

    Stefan> However, when edebugging `nsm-should-check` and step through the code, I
    Stefan> do not get a backtrace, and it correctly returns t.

    Stefan> Any ideas for how to continue debugging this?

`printf' (or in this case `message') is your friend :-)

I suspect `network-interface-list' is returning unexpected values
because of the VPN, but Iʼd check `network-lookup-address-info' as well

Robert
-- 

bug#74907: 31.0.50; nsm-check-local-subnet-ipv4 test fails on macOS with VPN enabled

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

With the VPN running and without, check the value
of (network-lookup-address-info "localhost") and see if the VPN-regime
value looks sensible. It is possible that your VPN set up is absconding
with host resolution. I'd bet that (nsm-should-check "127.0.0.1") works
fine under both scenarios. You could at the command line also ping
localhost and see what that reveals or try macOS network "reachability"
diagnostic utility scutil -W -r localhost.

On Mon, Dec 16, 2024 at 5:58 AM Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Mon, 16 Dec 2024 02:03:53 +0000, Stefan Kangas <
> stefankangas@gmail.com> said:
>
>     Stefan> I see the below test failure when running with a VPN enabled
> on macOS.
>     Stefan> It fails predictably every time, but when I disable the VPN,
> the test
>     Stefan> passes.
>
>     Stefan> Looking into it, it seems like it's this call that leads to the
>     Stefan> backtrace:
>
>     Stefan>     (nsm-should-check "localhost")
>
>     Stefan> However, when edebugging `nsm-should-check` and step through
> the code, I
>     Stefan> do not get a backtrace, and it correctly returns t.
>
>     Stefan> Any ideas for how to continue debugging this?
>
> `printf' (or in this case `message') is your friend :-)
>
> I suspect `network-interface-list' is returning unexpected values
> because of the VPN, but Iʼd check `network-lookup-address-info' as well
>
> Robert
> --
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2049 bytes --]

bug#74907: 31.0.50; nsm-check-local-subnet-ipv4 test fails on macOS with VPN enabled

[Robert Pluim]

>>>>> On Mon, 16 Dec 2024 06:23:12 -0500, Ship Mints <shipmints@gmail.com> said:

    Ship> With the VPN running and without, check the value
    Ship> of (network-lookup-address-info "localhost") and see if the VPN-regime
    Ship> value looks sensible. It is possible that your VPN set up is absconding
    Ship> with host resolution. I'd bet that (nsm-should-check "127.0.0.1") works
    Ship> fine under both scenarios. You could at the command line also ping
    Ship> localhost and see what that reveals or try macOS network "reachability"
    Ship> diagnostic utility scutil -W -r localhost.

Looking at the code, itʼs possible that `network-lookup-address-info'
needs a small adjustment. Letʼs see what Stefan says.

Robert
--