Use PF_LINK on SunOS by gwr · Pull Request #124728 · dotnet/runtime

gwr · 2026-02-22T16:38:14Z

I've been working on updates to arcate/eng/common/cross/build-rootfs.sh
and discovered it doing some ill-advised header copying for illumos.
With this small configuration change, that's no longer needed.
As the comment in the change explains:

SunOS defines both AF_LINK and AF_PACKET but AF_LINK is preferred.
Using AF_PACKET on SunOS requires access to system-private headers.

Copilot

Pull request overview

This pull request modifies the native networking code to prefer AF_LINK over AF_PACKET on SunOS/illumos platforms. SunOS defines both AF_LINK and AF_PACKET constants, but using AF_PACKET requires access to system-private headers, which creates unnecessary build dependencies. The change ensures that the codebase uses AF_LINK (the preferred API) on SunOS by adding !defined(TARGET_SUNOS) conditions to the existing AF_PACKET preprocessor checks.

Changes:

Modified conditional compilation in pal_maphardwaretype.c to exclude SunOS from using AF_PACKET code paths
Modified conditional compilation in pal_interfaceaddresses.c to exclude SunOS from AF_PACKET header includes
Added explanatory comments documenting why SunOS should use AF_LINK instead of AF_PACKET

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/native/libs/System.Native/pal_maphardwaretype.c	Updated compile-time conditionals at lines 13 and 35 to exclude TARGET_SUNOS from AF_PACKET code paths, forcing the use of AF_LINK for hardware type mapping on SunOS
src/native/libs/System.Native/pal_interfaceaddresses.c	Updated compile-time conditional at line 52 to exclude TARGET_SUNOS from AF_PACKET header includes, ensuring AF_LINK headers are used instead

am11 · 2026-02-22T21:46:55Z

some ill-advised header copying for illumos.

It was discussed with illumos channel when I set it up. It is build-only quirk and shouldn't block the real work which is completion of port. Let’s look for a proper replacement that doesn’t come at the cost of a reduced or compromised implementation.

gwr · 2026-02-22T21:52:46Z

src/native/libs/System.Native/pal_maphardwaretype.c

 {
-#if defined(AF_PACKET)
+// Want to use AF_LINK on SunOS
+#if defined(AF_PACKET) && !defined(TARGET_SUNOS)


I'm not sure why I would do that when the #elif defined(AF_LINK) section that follows does what we want on SunOS. Did you see that?

gwr · 2026-02-22T21:53:48Z

some ill-advised header copying for illumos.

It was discussed with illumos channel when I set it up. It is build-only quirk and shouldn't block the real work which is completion of port. Let’s look for a proper replacement that doesn’t come at the cost of a reduced or compromised implementation.

I don't see any reduced functionality here. This is just making it use the AF_LINK code paths.

am11 · 2026-02-22T22:18:29Z

This is just making it use the AF_LINK code paths.

Have you validated it in a fresh docker? If so, I don't see how it would be behaving properly given the order at call-site:

runtime/src/native/libs/System.Native/pal_interfaceaddresses.c

Lines 228 to 254 in a48fa8e

    
           #if defined(AF_PACKET) 
        
                   else if (family == AF_PACKET) 
        
                   { 
        
                       if (onLinkLayerFound != NULL) 
        
                       { 
        
                           struct sockaddr_ll* sall = (struct sockaddr_ll*)current->ifa_addr; 
        
                           if (sall->sll_halen > sizeof(sall->sll_addr)) 
        
                           { 
        
                               // sockaddr_ll->sll_addr has a maximum capacity of 8 bytes (unsigned char sll_addr[8]) 
        
                               // so if we get a address length greater than that, we truncate it to 8 bytes. 
        
                               // This is following the kernel docs where they always treat physical addresses with a maximum of 8 bytes. 
        
                               // However in WSL we hit an issue where sll_halen was 16 bytes so the memcpy_s below would fail because it was greater. 
        
                               sall->sll_halen = sizeof(sall->sll_addr); 
        
                           } 
        
                           LinkLayerAddressInfo lla; 
        
                           memset(&lla, 0, sizeof(LinkLayerAddressInfo)); 
        
                           lla.InterfaceIndex = interfaceIndex; 
        
                           lla.NumAddressBytes = sall->sll_halen; 
        
                           lla.HardwareType = MapHardwareType(sall->sll_hatype); 
        
                           memcpy_s(&lla.AddressBytes, sizeof_member(LinkLayerAddressInfo, AddressBytes), &sall->sll_addr, sall->sll_halen); 
        
                           onLinkLayerFound(context, current->ifa_name, &lla); 
        
                       } 
        
                   } 
        
           #elif defined(AF_LINK)

gwr · 2026-02-22T22:21:28Z

This is just making it use the AF_LINK code paths.

Have you validated it in a fresh docker? If so, I don't see how it would be behaving properly given the order at call-site:

runtime/src/native/libs/System.Native/pal_interfaceaddresses.c

Lines 228 to 254 in a48fa8e

#if defined(AF_PACKET)

else if (family == AF_PACKET)

{

if (onLinkLayerFound != NULL)

{

struct sockaddr_ll* sall = (struct sockaddr_ll*)current->ifa_addr;

if (sall->sll_halen > sizeof(sall->sll_addr))

{

// sockaddr_ll->sll_addr has a maximum capacity of 8 bytes (unsigned char sll_addr[8])

// so if we get a address length greater than that, we truncate it to 8 bytes.

// This is following the kernel docs where they always treat physical addresses with a maximum of 8 bytes.

// However in WSL we hit an issue where sll_halen was 16 bytes so the memcpy_s below would fail because it was greater.

sall->sll_halen = sizeof(sall->sll_addr);

}

LinkLayerAddressInfo lla;

memset(&lla, 0, sizeof(LinkLayerAddressInfo));

lla.InterfaceIndex = interfaceIndex;

lla.NumAddressBytes = sall->sll_halen;

lla.HardwareType = MapHardwareType(sall->sll_hatype);

memcpy_s(&lla.AddressBytes, sizeof_member(LinkLayerAddressInfo, AddressBytes), &sall->sll_addr, sall->sll_halen);

onLinkLayerFound(context, current->ifa_name, &lla);

}

}

#elif defined(AF_LINK)

Thanks. I've only gone as far as building this.
What's a good test for this library?

am11 · 2026-02-22T22:35:23Z

I've been working on updates to arcate/eng/common/cross/build-rootfs.sh

illumos support in build-rootfs.sh was originally added for the dotnet prereq Docker image. Some time ago the illumos image build itself was removed due to staleness(although previously built images still exist). So changes in build-rootfs will need to be validated manually:

# fresh docker
$ cd runtime
$ git branch --show-current # make sure it's this branch
# remove the extra headers download block from build-rootfs.sh

# run docker interactively
$ docker run --rm -v$(pwd):/runtime -w /runtime -e ROOTFS_DIR=/crossrootfs/x64 -it ubuntu
$ eng/common/native/install-dependencies.sh
$ apt install -y libmpc-dev
$ eng/common/cross/build-rootfs.sh noble illumos x64
$ ./build.sh clr+libs --cross --os illumos --arch x64 --gcc

What's a good test for this library?

src/libraries/System.Net.NetworkInformation/tests/FunctionalTests

I was actually referring to validation of build test and also fixing the logic, I think it needs #if defined(AF_PACKET) && !defined(TARGET_SUNOS) on pal_interfaceaddresses.c's line 228 as well.

gwr · 2026-02-22T23:28:59Z

OK. This seems to work as well as the previous did.

System.Net.NetworkInformation.Functional.Tests Results
Overall: 210/239 tests passed (87.9% pass rate), 29 failures, 0 skipped
Failed Test Categories (All throw PlatformNotSupportedException):
(pre-existing failures)

gwr · 2026-02-26T14:59:37Z

Can anyone help me interpret the CI build analysis?
Is there anything there I need to fix?

am11 · 2026-02-26T15:11:45Z

Overall: 210/239 tests passed (87.9% pass rate), 29 failures, 0 skipped

You can skip those with the following attribute:

[SkipOnPlatform(TestPlatforms.illumos | TestPlatforms.Solaris, "Not supported on SunOS-based platforms.")]

on top of those methods. But double check if PlatformNotSupported is intended there or something is off (in which case add a tracking issue and put that issue URL in "Not supported on SunOS-based platforms." reason string to imply it needs to be fixed as opposed to it's a known limitation; won't-fix).

gwr · 2026-02-26T15:47:31Z

Overall: 210/239 tests passed (87.9% pass rate), 29 failures, 0 skipped

You can skip those with the following attribute:
[SkipOnPlatform(TestPlatforms.illumos | TestPlatforms.Solaris, "Not supported on SunOS-based platforms.")]
on top of those methods. But double check if PlatformNotSupported is intended there or something is off (in which case add a tracking issue and put that issue URL in "Not supported on SunOS-based platforms." reason string to imply it needs to be fixed as opposed to it's a known limitation; won't-fix).

Thanks. However, I don't yet see where I should be looking to add that.
Can you please direct me?

am11 · 2026-02-26T15:54:25Z

I don't yet see where I should be looking to add that.

In the test logs you can find the names of the 29 failing tests, and then add the attribute to each of those methods.

gwr · 2026-02-26T17:57:04Z

This test appears to be failing due to ENOSPACE
runtime (Build ios-arm64 Release AllSubsets_Mono_Smoke)
Failing after 46m — Build ios-arm64 Release AllSubsets_Mono_Smoke failed

I don't see any failures related to the changes in this PR.

gwr · 2026-02-27T19:54:10Z

I don't yet see where I should be looking to add that.

In the test logs you can find the names of the 29 failing tests, and then add the attribute to each of those methods.

Yes, the support for getting interface information needs work.
I'll update with that in a while. Doing like FreeBSD gets most of it...

am11 · 2026-02-27T19:59:47Z

Sounds good. Did you get a fresh build succeeding without private headers download block in build-rootfs.sh: #124728 (comment)?

gwr · 2026-02-27T20:41:01Z

Sounds good. Did you get a fresh build succeeding without private headers download block in build-rootfs.sh: #124728 (comment)?

Yes, but it will be easier to do the arcade update after this PR goes in, to avoid a "can't build latest in the repo" situation.

am11 · 2026-02-27T20:56:12Z

to avoid a "can't build latest in the repo" situation.

There is no CI leg blocked on illumos. The build-rootfs.sh script is a standalone utility used during docker image builds, and it no longer builds illumos images, as explained above.

gwr · 2026-03-02T14:15:22Z

There turned out to be a bunch more to do before
System.Net.NetworkInformation.Functional.Tests
all pass. I opened a new PR for that: #125054

gwr · 2026-03-03T02:09:21Z

I guess I'll reopen this since #125054 is blocked, and I need (at least) these PF_LINK changes to allow building with a less ancient crossrootfs.

am11 · 2026-03-03T08:27:29Z

less ancient crossrootfs

build-rootfs.sh illumox x64 is working just fine since 2020 regardless of the changes in this PR. Nothing is being blocked..

Copilot AI review requested due to automatic review settings February 22, 2026 16:38

github-actions bot added the area-System.IO.Compression label Feb 22, 2026

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Feb 22, 2026

Copilot started reviewing on behalf of gwr February 22, 2026 16:39 View session

Copilot AI reviewed Feb 22, 2026

View reviewed changes

jkotas added area-System.Net.Sockets os-SunOS SunOS, currently not officially supported and removed area-System.IO.Compression labels Feb 22, 2026

This was referenced Feb 22, 2026

Wasm build terminated with exit code 137 #108299

Open

[android][clr] No peer certificates when executing System.Net.Http.Functional.Tests on Android emulator #124526

Open

gwr commented Feb 22, 2026

View reviewed changes

gwr force-pushed the illumos-pf-link branch from 1a0e6d5 to cae3ce6 Compare February 22, 2026 23:27

Use PF_LINK on SunOS

5ebbc05

gwr force-pushed the illumos-pf-link branch from cae3ce6 to 5ebbc05 Compare February 26, 2026 16:36

This was referenced Mar 1, 2026

Fix memory overwrites in SystemNative_GetNetworkInterfaces #125022

Open

Fix getdomainname for SunOS #125053

Open

Port System.Net.NetworkInformation to SunOS #125054

Draft

gwr closed this Mar 2, 2026

gwr reopened this Mar 3, 2026

build-analysis bot mentioned this pull request Mar 3, 2026

Android WebSocket failure #121518

Open

Conversation

gwr commented Feb 22, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

am11 commented Feb 22, 2026

Uh oh!

gwr Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

gwr commented Feb 22, 2026

Uh oh!

am11 commented Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gwr commented Feb 22, 2026

Uh oh!

am11 commented Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gwr commented Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gwr commented Feb 26, 2026

Uh oh!

am11 commented Feb 26, 2026

Uh oh!

gwr commented Feb 26, 2026

Uh oh!

am11 commented Feb 26, 2026

Uh oh!

gwr commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gwr commented Feb 27, 2026

Uh oh!

am11 commented Feb 27, 2026

Uh oh!

gwr commented Feb 27, 2026

Uh oh!

am11 commented Feb 27, 2026

Uh oh!

gwr commented Mar 2, 2026

Uh oh!

gwr commented Mar 3, 2026

Uh oh!

am11 commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

am11 commented Feb 22, 2026 •

edited

Loading

am11 commented Feb 22, 2026 •

edited

Loading

gwr commented Feb 22, 2026 •

edited

Loading

gwr commented Feb 26, 2026 •

edited

Loading