Don't fragment bit doesn't get set in Sequoia

Hi, I've noticed a weird behavior happening on Sequoia with DF bit:

  1. On machine where SIP is disabled, when I do /sbin/ping -D -s 1400 8.8.8.8 I do see the DF bit in wireshark

  2. On machine where SIP is enabled, when I do /sbin/ping -D -s 1400 8.8.8.8 I do not see the DF bit in wireshark

The -D flag should set the DF bit but for some reason it doesn’t if the SIP is enabled.

Perhaps there was any change in permission/entitlements mechanism in Sequoia that can explain it ? I'm using the built-in ping command so maybe it should be signed with more entitlements ?

Answered by DTS Engineer in 827648022
I suspect that new restrictions might have been introduced

I asked about this internally and AFAICT this wasn’t a deliberate change. Weirdly, I can reproduce the problems as you’ve described it [1] but other internal folks can’t.

It’s clear that we need to look at this issue properly. To that end, please file a bug about this. If you reply here with your bug number, I’ll add info about my own experiments.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, the non-SIP part. I don’t have time to experiment with disabling SIP today.

Is this behaviour new in macOS 15? Or did you see the same oddity on macOS 14?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

It worked on macOS 14 but no longer works on macOS 15. I suspect that new restrictions might have been introduced, preventing the DF (Don't Fragment) bit from appearing in ICMP requests.

I attempted to generate such a packet using setsockopt by setting the DONTFRAG attribute on an ICMP connection, but it did not succeed. I also tried the same approach with UDP, but without success.

Could this require new entitlements for setting the DF flag in a packet?

Below are the entitlements of /sbin/ping. I recognize the last two, which are typically used when an app is sandboxed. However, could there be additional entitlements missing ?

<key>com.apple.private.network.management.data.development</key><true/>
<key>com.apple.private.virtualswitch.underlay-scoped</key><true/>
<key>com.apple.security.network.client</key><true/>
<key>com.apple.security.network.server</key><true/></dict>

Thanks

I suspect that new restrictions might have been introduced

I asked about this internally and AFAICT this wasn’t a deliberate change. Weirdly, I can reproduce the problems as you’ve described it [1] but other internal folks can’t.

It’s clear that we need to look at this issue properly. To that end, please file a bug about this. If you reply here with your bug number, I’ll add info about my own experiments.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, the non-SIP part. I don’t have time to experiment with disabling SIP today.