test-dgram-udp6-link-local-address failing on AIX 7.2

[richardlau]

• Test: test-dgram-udp6-link-local-address
• Platform: AIX 7.2
• Console Output:

19:28:07 not ok 779 parallel/test-dgram-udp6-link-local-address
19:28:07   ---
19:28:07   duration_ms: 0.295
19:28:07   severity: fail
19:28:07   exitcode: 1
19:28:07   stack: |-
19:28:07     node:assert:124
19:28:07       throw new AssertionError(obj);
19:28:07       ^
19:28:07     
19:28:07     AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
19:28:07     + actual - expected
19:28:07     
19:28:07     + 'fe80::8034:d9ff:fead:df3f%lo0'
19:28:07     - 'fe80::8034:d9ff:fead:df3f%en1'
19:28:07                                  ^
19:28:07         at Socket.<anonymous> (/home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/parallel/test-dgram-udp6-link-local-address.js:45:10)
19:28:07         at Socket.<anonymous> (/home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/common/index.js:448:15)
19:28:07         at Socket.emit (node:events:510:28)
19:28:07         at UDP.onMessage [as onmessage] (node:dgram:933:8) {
19:28:07       generatedMessage: true,
19:28:07       code: 'ERR_ASSERTION',
19:28:07       actual: 'fe80::8034:d9ff:fead:df3f%lo0',
19:28:07       expected: 'fe80::8034:d9ff:fead:df3f%en1',
19:28:07       operator: 'strictEqual'
19:28:07     }
19:28:07     
19:28:07     Node.js v20.0.0-pre
19:28:07   ...

• Build Links: https://ci.nodejs.org/job/node-test-commit-aix/45070/nodes=aix72-ppc64/consoleFull

This is a follow on from #39143. I'm currently setting up some new AIX 7.2 VMs to attach to the Node.js CI and these have the "en1" and "sit0" network interfaces enabled that we had disabled on the existing VMs due to #39143 (comment). Now, instead of the test crashing (fixed by #41547) the test now errors as above -- looks like the test is expecting the address to be scoped to "en1" but it is scoped to "lo0" (the loopback interface).

cc @nodejs/platform-aix

[bnoordhuis]

Is it possible for you to run node -p 'os.networkInterfaces()' on that machine? The output of ifconfig (or whatever the AIX equivalent is) would be helpful too.

I'm going to guess there's an interface whose address starts with fe80: but isn't a loopback device. That shouldn't be fatal though.

[richardlau]

Yes, it will be possible -- I'll do so next week (I've got a day off work today and am not intending to turn on my work laptop).

[richardlau]

@bnoordhuis
node -p 'os.networkInterfaces()':

{
  en0: [
    {
      address: '192.168.166.14',
      netmask: '255.255.255.248',
      family: 'IPv4',
      mac: 'fa:1e:f8:31:df:20',
      internal: false,
      cidr: '192.168.166.14/29'
    }
  ],
  en1: [
    {
      address: 'fe80::8034:d9ff:fead:df3f',
      netmask: 'ffff:ffff:ffff:ffff::',
      family: 'IPv6',
      mac: '82:34:d9:ad:df:3f',
      internal: false,
      cidr: 'fe80::8034:d9ff:fead:df3f/64',
      scopeid: 3
    }
  ],
  sit0: [
    {
      address: '::192.168.166.14',
      netmask: 'ffff:ffff:ffff:ffff:ffff:ffff::',
      family: 'IPv6',
      mac: 'c0:a8:a6:0e:00:00',
      internal: false,
      cidr: '::192.168.166.14/96',
      scopeid: 0
    }
  ],
  lo0: [
    {
      address: '127.0.0.1',
      netmask: '255.0.0.0',
      family: 'IPv4',
      mac: '00:00:00:00:00:00',
      internal: true,
      cidr: '127.0.0.1/8'
    },
    {
      address: '::1',
      netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
      family: 'IPv6',
      mac: '00:00:00:00:00:00',
      internal: true,
      cidr: '::1/128',
      scopeid: 1
    }
  ]
}

and ifconfig -a:

en0: flags=1e084863,814c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
        inet 192.168.166.14 netmask 0xfffffff8 broadcast 192.168.166.15
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
en1: flags=1e084863,814c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
        inet6 fe80::8034:d9ff:fead:df3f%3/64
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
sit0: flags=8100041<UP,RUNNING,LINK0>
        inet6 ::192.168.166.14/96
lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>
        inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
        inet6 ::1%1/128
         tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

[bnoordhuis]

Right, pretty much what I expected: en1 has a link-local address (fe80::) but is not a loopback device.

The test expects the datagrams to arrive on fe80::...%en1 but instead they come in on fe80::...%lo0. I don't know why AIX works that way, it's kind of strange, but you can fix it by adding an AIX-specific check to the test.

[richardlau]

FWIW I looked into a few AIX IPv6 config options:

• https://www.ibm.com/docs/en/aix/7.2?topic=6-ipv6-multihomed-link-local-site-local-support
• https://www.ibm.com/docs/en/aix/7.2?topic=n-no-command

(specifically "multi_homed" and "main_if6") but they haven't made a difference to the test and the dgrams still arrive on lo0.

[Astrovicis]

I think this is related...
this works:

import dgram from 'node:dgram';
import readline from 'readline';

async function readSync() {
  const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
  });

  return new Promise((resolve, reject) => {
    rl.question('', (answer) => {
      rl.close();
      resolve(answer);
    });
  });
}

const socket = await dgram.createSocket('udp4');

socket.on('listening', () => {
  const address = socket.address();
  console.log(`server listening ${address.address}:${address.port}`);
});

// Bind the socket to the port 6000.
await socket.bind(6000, '127.0.0.1');

// Define a callback function for incoming messages.
async function onMessage(message, remoteAddress) {
  // Decode the message.
  const decodedMessage = message.toString();

  // Display the message.
  console.log(`Received message from ${remoteAddress}: ${decodedMessage}`);
}

// Set the socket to listen for incoming messages.
socket.on('message', onMessage);

// Start the chat loop.
async function chatLoop() {
  while (true) {
    // Get the user's input.
    const message = await readSync();

    // Send the message to the port 6000 on the loopback server.
    await socket.send(message, 6000, '127.0.0.1');
  }
}

// Start the chat loop.
await chatLoop();

// Close the socket when the user is finished.
await socket.close();

and this doesn't:

import dgram from 'node:dgram';
import readline from 'readline'

const socket = dgram.createSocket('udp6');

// Set the socket to listen for incoming messages.
socket.on('message', onMessage);

socket.on('listening', () => {
  const address = server.address();
  console.log(`server listening ${address.address}:${address.port}`);
});

function readSync() {
  const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
  });

  return new Promise((resolve, reject) => {
    rl.question('', (answer) => {
      rl.close();
      resolve(answer);
    });
  });
}

// Bind the socket to the port 6000.
socket.bind(1234, '::%en0', () => {
  socket.setMulticastInterface('::%en0');
  socket.setKeepAlive(false);
  socket.setRecvBufferSize(1024 * 1024);
});

// Define a callback function for incoming messages.
function onMessage(message, remoteAddress) {
  // Decode the message.
  const decodedMessage = message.toString();

  // Display the message.
  console.log(`Received message from ${remoteAddress}: ${decodedMessage}`);
}

// Set the socket to listen for incoming messages.
socket.on('message', onMessage);

// Start the chat loop.
async function chatLoop() {
  while (true) {
    // Get the user's input.
    const message = await readSync();

    // Wait for the Buffer object to resolve before sending it.
    const buffer = await new Buffer.allocUnsafe(message.length);

    // Send the message to the port 6000 on the IPv6 address of the other peer.
    socket.send(buffer, 1234, '::%en0');
  }
}

// Start the chat loop.
chatLoop();

// Close the socket when the user is finished.
socket.close();

I'm on Mac OS 12.6.7 Monterey. I've tried hardcoding the IPv6 address of en0, using '::' and '::1', and running node with sudo, but each of those has failed. Is it related? If not, I'm more than happy to open another ticket because it's driving me crazy lol

[bnoordhuis]

@Astrovicis I've hidden your comment. Can you open a discussion instead of an issue? I'm pretty sure you're not hitting a node bug.

[aduh95]

I'm seeing it again:

00:24:23.869 not ok 1213 parallel/test-dgram-udp6-link-local-address
00:24:23.869   ---
00:24:23.869   duration_ms: 1253.23900
00:24:23.869   severity: fail
00:24:23.869   exitcode: 1
00:24:23.869   stack: |-
00:24:23.869     node:internal/assert/utils:146
00:24:23.869       throw error;
00:24:23.869       ^
00:24:23.869     
00:24:23.869     AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
00:24:23.869     + actual - expected
00:24:23.869     
00:24:23.869     + 'fe80::8034:d9ff:fead:df3f%lo0'
00:24:23.869     - 'fe80::8034:d9ff:fead:df3f%en1'

https://ci.nodejs.org/job/node-test-commit-aix/62538/
https://ci.nodejs.org/job/node-test-commit-aix/62541/
https://ci.nodejs.org/job/node-test-commit-aix/62542/
https://ci.nodejs.org/job/node-test-commit-aix/62544/
https://ci.nodejs.org/job/node-test-commit-aix/62545/

[sxa]

Thanks @aduh95 - I wonder if that's showed up again after a reboot of the machine that all of those jobs ran on yesterday - test-ibm-aix72-ppc64-be-1. I've taken down the en1 interface for now and will do a stress run across the machines to see if (a) that fixes things and (b) if other machiens are affected but we'll still need to look at making it permanent.

[sxa]

I've got a solution for making this permanent so will get the instructions updated accordingly which should ensure this doesn't occur the next time the machines are restarted.

[github-actions]

This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.