For use-cases like SmartOS-on-SmartOS, viona must configure itself, in certain circumstances, to be a promiscuous MAC client on top of the provided vnic. This could be very rudimentary at first, being enabled only when the zone has been configured to allow such promiscuous access. Toggling such functionality could be enabled later, when viona supports the virtio-net control queue feature.
Dan McDonald commented on 2025-07-09T14:54:36.899-0400:
14716 may be necessary, but not sufficient, to solve this bug.
Carlos Neira commented on 2025-07-11T10:07:18.550-0400:
As part of development and in the spirit of dogfooding, we attempted to update this SmartOS on SmartOS setup by @Nahum Shalman ( ).
However, during a debugging session with @Dan McDonald and @Nahum Shalman, we discovered that the VM's connectivity was not working. In that session, we identified a bhyve(8) network-backend option as the culprit.
The avalaible network-backend-options are:
promiscphys
Enable promiscuous mode at the physical level
(default: false)
promiscsap
Enable promiscuous mode at the SAP level
(default:true)
promiscmulti
Enable promiscuous mode for all multicast addresses
(default: true)
promiscrxonly
The selected promiscuous modes are only enabled for
received traffic (default: true).
These are enabled by default, except for promiscphys
Setting this backend option when a zone specifies allow_mac_spoofing=true, along with adding support for unfiltered promiscuous mode to the bhyve brand, resolved the problem.
Testing done:
With a new PI image build with this branch 515 . This setup was replicated using bhyve
Provisioning a bhyve zone with allow_mac_spoofing=true.
[root@boldo /opt/templates]# cat coal-headnode.json
{
"alias": "coal-headnode2",
"brand": "bhyve",
"ram": 32096,
"vcpus": 3,
"autoboot": false,
"nics": [
{
"mac": "52:54:00:00:00:00",
"nic_tag": "sdc_admin0",
"model": "e1000",
"ip": "dhcp",
"allow_dhcp_spoofing": true,
"allow_ip_spoofing": true,
"allow_mac_spoofing": true,
"allow_restricted_traffic": true,
"allow_unfiltered_promisc": true,
"dhcp_server": true
},
{
"mac": "52:54:00:00:00:01",
"nic_tag": "sdc_external0",
"model": "e1000",
"ip": "dhcp",
"allow_dhcp_spoofing": true,
"allow_ip_spoofing": true,
"allow_mac_spoofing": true,
"allow_restricted_traffic": true,
"allow_unfiltered_promisc": true,
"dhcp_server": true
}
],
"disks": [
{
"size": 8192,
"model": "virtio"
},
{
"size": 65440,
"model": "virtio"
}
]
} Provisioning a bhyve zone without allow_mac_spoofing
[root@boldo /opt/templates]# cat ubu.json
{
"alias": "ubuntu-dev",
"brand": "bhyve",
"ram": 4096,
"vcpus": 3,
"autoboot": false,
"nics":
[
{
"nic_tag": "sdc_external0",
"model": "virtio",
"ip": "dhcp",
"dhcp_server": true
}],
"disks": [
{
"image_uuid": "97219479-f34c-4f1d-8a71-cd774dada4cf",
"boot": true,
"model": "virtio"
},
{
"model": "virtio",
"size": 25600
}
]
}We check that both bhyve processes are running and their internal vm names
SOFTC VM ZONE TOPO MiB F NAME
fffffeb2141f41c0 fffffeb166b5b000 fffffeb16faa4540 3/1/1 32129 T SYSbhyve-75
fffffeb230171080 fffffeb167c11000 fffffeb16faa4000 3/1/1 4129 T SYSbhyve-118SYSbhyve-75 is our COAL bhyve vm, checking the bhyve argument for that gives us
[root@boldo /opt/templates]# pargs 11790
11790: bhyve -H -U d5ad188a-7a73-4aef-a25a-5d9a7a3f7696 -B 1,manufacturer=Joyent,produ
argv[0]: bhyve
argv[1]: -H
argv[2]: -U
argv[3]: d5ad188a-7a73-4aef-a25a-5d9a7a3f7696
argv[4]: -B
argv[5]: 1,manufacturer=Joyent,product=SmartDC HVM,version=7.20250707T155014Z,serial=d5ad188a-7a73-4aef-a25a-5d9a7a3f7696,sku=001,family=Virtual Machine
argv[6]: -s
argv[7]: 31,lpc
argv[8]: -l
argv[9]: com1,/dev/zconsole
argv[10]: -l
argv[11]: com2,socket,/tmp/vm.ttyb
argv[12]: -l
argv[13]: bootrom,/usr/share/bhyve/uefi-csm-rom.bin
argv[14]: -s
argv[15]: 0,hostbridge,model=i440fx
argv[16]: -c
argv[17]: 3
argv[18]: -m
argv[19]: 32096
argv[20]: -s
argv[21]: 0:4:0,virtio-blk,/dev/zvol/rdsk/zones/d5ad188a-7a73-4aef-a25a-5d9a7a3f7696/disk0
argv[22]: -s
argv[23]: 0:4:1,virtio-blk,/dev/zvol/rdsk/zones/d5ad188a-7a73-4aef-a25a-5d9a7a3f7696/disk1
argv[24]: -s
argv[25]: 0:4:2,virtio-blk,/dev/zvol/rdsk/zones/d5ad188a-7a73-4aef-a25a-5d9a7a3f7696/disk2
argv[26]: -s
argv[27]: 0:4:3,virtio-blk,/dev/zvol/rdsk/zones/d5ad188a-7a73-4aef-a25a-5d9a7a3f7696/disk3
argv[28]: -s
argv[29]: 6:0,virtio-net-viona,net0,promiscphys=true
argv[30]: -s
argv[31]: 6:1,virtio-net-viona,net1,promiscphys=true
argv[32]: -s
argv[33]: 30:0,fbuf,vga=off,unix=/tmp/vm.vnc
argv[34]: -s
argv[35]: 30:1,xhci,tablet
argv[36]: SYSbhyve-75promiscphys=true as required.
Sysbhyve-118 is a Linux Bhyve vm with no allow_mac_spoofing specified.
[root@boldo /opt/templates]# pargs 12397
12397: bhyve -H -U 2231ec78-e3e2-43a6-a2b9-dce0683d02b0 -B 1,manufacturer=Joyent,produ
argv[0]: bhyve
argv[1]: -H
argv[2]: -U
argv[3]: 2231ec78-e3e2-43a6-a2b9-dce0683d02b0
argv[4]: -B
argv[5]: 1,manufacturer=Joyent,product=SmartDC HVM,version=7.20250707T155014Z,serial=2231ec78-e3e2-43a6-a2b9-dce0683d02b0,sku=001,family=Virtual Machine
argv[6]: -s
argv[7]: 31,lpc
argv[8]: -l
argv[9]: com1,/dev/zconsole
argv[10]: -l
argv[11]: com2,socket,/tmp/vm.ttyb
argv[12]: -l
argv[13]: bootrom,/usr/share/bhyve/uefi-csm-rom.bin
argv[14]: -s
argv[15]: 0,hostbridge,model=i440fx
argv[16]: -c
argv[17]: 3
argv[18]: -m
argv[19]: 4096
argv[20]: -s
argv[21]: 0:4:0,virtio-blk,/dev/zvol/rdsk/zones/2231ec78-e3e2-43a6-a2b9-dce0683d02b0/disk0
argv[22]: -s
argv[23]: 0:4:1,virtio-blk,/dev/zvol/rdsk/zones/2231ec78-e3e2-43a6-a2b9-dce0683d02b0/disk1
argv[24]: -s
argv[25]: 6:0,virtio-net-viona,net0
argv[26]: -s
argv[27]: 30:0,fbuf,vga=off,unix=/tmp/vm.vnc
argv[28]: -s
argv[29]: 30:1,xhci,tablet
argv[30]: SYSbhyve-118So as expected, we don’t see promiscphys=true in the backend options.
Carlos Neira commented on 2025-07-11T14:31:48.833-0400 (edited 2025-07-11T14:33:16.940-0400):
Case 2: Test allow_ip_spoofing in a bhyve vm (COAL) with promiscphys=true with 515
zone nics definition:
"nics": [
{
"mac": "52:54:00:00:00:00",
"nic_tag": "sdc_admin0",
"model": "e1000",
"ip": "dhcp",
"allow_dhcp_spoofing": true,
"allow_ip_spoofing": true,
"allow_mac_spoofing": true,
"allow_restricted_traffic": true,
"allow_unfiltered_promisc": true,
"dhcp_server": true
},
{
"mac": "52:54:00:00:00:01",
"nic_tag": "sdc_external0",
"model": "e1000",
"ip": "dhcp",
"allow_dhcp_spoofing": true,
"allow_ip_spoofing": true,
"allow_mac_spoofing": true,
"allow_restricted_traffic": true,
"allow_unfiltered_promisc": true,
"dhcp_server": true
}
],[root@headnode (coal) ~]# dladm show-vnic
LINK OVER SPEED MACADDRESS MACADDRTYPE VID ZONE
external0 vioif1 1000 2:8:20:f8:88:d fixed 0 --
manta0 vioif1 1000 90:b8:d0:7a:67:e4 fixed 0 --
[root@headnode (coal) ~]# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
vioif0 Ethernet up 1000 full vioif0
vioif1 Ethernet up 1000 full vioif1
[root@headnode (coal) ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vioif0: flags=1001000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4,FIXEDMTU> mtu 1500 index 2
inet 10.99.99.7 netmask ffffff00 broadcast 10.99.99.255
ether 52:54:0:0:0:0
external0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 10.88.88.200 netmask ffffff00 broadcast 10.88.88.255
ether 2:8:20:f8:88:d
manta0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 10.77.77.5 netmask ffffff00 broadcast 10.77.77.255
ether 90:b8:d0:7a:67:e4
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@headnode (coal) ~]# ifconfig external0:1 plumb 10.88.88.230/24 up
[root@headnode (coal) ~]# ping -i 10.88.88.230 tritondatacenter.com
tritondatacenter.com is alive
[root@headnode (coal) ~]# ping -i manta0 tritondatacenter.com
ping: sendto No route to host
[root@headnode (coal) ~]# ping -i external0:1 tritondatacenter.com
tritondatacenter.com is aliveCase 2: COAL bhyve vm without promiscphys=true (not running the current fix) same nic definitions.
[root@headnode (coal) ~]# ifconfig external0:1 plumb 10.88.88.230/24 up
[root@headnode (coal) ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vioif0: flags=1001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,FIXEDMTU> mtu 1500 index 2
inet 10.99.99.7 netmask ffffff00 broadcast 10.99.99.255
ether 52:54:0:0:0:0
external0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 10.88.88.200 netmask ffffff00 broadcast 10.88.88.255
ether 2:8:20:f8:88:d
external0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 10.88.88.230 netmask ffffff00 broadcast 10.88.88.255
manta0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 10.77.77.5 netmask ffffff00 broadcast 10.77.77.255
ether 90:b8:d0:7a:67:e4
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@headnode (coal) ~]# ping -i 10.88.88.230 8.8.8.8
no answer from 8.8.8.8
Carlos Neira commented on 2025-07-11T16:15:59.224-0400 (edited 2025-07-11T16:46:24.189-0400):
on-link peers works both ways
Test without fix applied, in COAL bhyve vm, ping coal-nat(native) zone at 10.88.88.2
[root@headnode (coal) ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vioif0: flags=1001000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4,FIXEDMTU> mtu 1500 index 2
inet 10.99.99.7 netmask ffffff00 broadcast 10.99.99.255
ether 52:54:0:0:0:0
external0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 10.88.88.200 netmask ffffff00 broadcast 10.88.88.255
ether 2:8:20:f8:88:d
external0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 10.88.88.230 netmask ffffff00 broadcast 10.88.88.255
manta0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 10.77.77.5 netmask ffffff00 broadcast 10.77.77.255
ether 90:b8:d0:7a:67:e4
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@headnode (coal) ~]# ping -i external0:1 10.88.88.2
no answer from 10.88.88.2
[root@headnode (coal) ~]# ping -i external0 10.88.88.2
no answer from 10.88.88.2From coal-nat(native) zone ping 10.88.88.230 in COAL bhyve vm
,---. | ,---. ,---.
`---. ,-.-. ,---. ,---. |--- | | `---. minimal-64-lts
| | | | ,---| | | | | | 24.4.1
`---' ` ' ' `---' ` `---' `---' `---'
[root@coal-nat ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
net0: flags=1104843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.3.200 netmask ffffff00 broadcast 192.168.3.255
ether 62:95:d2:9:1d:d6
net1: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 10.88.88.2 netmask ffffff00 broadcast 10.88.88.255
ether 52:8d:42:57:32:22
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@coal-nat ~]# ping -i net1 10.88.88.230
no answer from 10.88.88.230
[root@coal-nat ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
net0: flags=1104843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.3.200 netmask ffffff00 broadcast 192.168.3.255
ether 62:95:d2:9:1d:d6
net1: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 10.88.88.2 netmask ffffff00 broadcast 10.88.88.255
ether 52:8d:42:57:32:22
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@coal-nat ~]# ping -i net1 10.88.88.200
no answer from 10.88.88.200Test with 515 applied
Ping from COAL bhyve vm to coal-nat (native zone)
[root@headnode (coal) ~]# ping google.cl
google.cl is alive
[root@headnode (coal) ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vioif0: flags=1001000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4,FIXEDMTU> mtu 1500 index 2
inet 10.99.99.7 netmask ffffff00 broadcast 10.99.99.255
ether 52:54:0:0:0:0
external0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 10.88.88.200 netmask ffffff00 broadcast 10.88.88.255
ether 2:8:20:f8:88:d
manta0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 10.77.77.5 netmask ffffff00 broadcast 10.77.77.255
ether 90:b8:d0:7a:67:e4
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@headnode (coal) ~]# ifconfig external0:1 plumb 10.88.88.230/24 up
[root@headnode (coal) ~]# ping 10.88.88.2
10.88.88.2 is alive
[root@headnode (coal) ~]# ping -i external0:1 10.88.88.2
10.88.88.2 is alive
[root@headnode (coal) ~]#From coal-nat(native) zone ping 10.88.88.230 in COAL bhyve vm
[root@coal-nat ~]# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
net0: flags=1104843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,ROUTER,IPv4> mtu 1500 index 2
inet 192.168.3.200 netmask ffffff00 broadcast 192.168.3.255
ether 62:95:d2:9:1d:d6
net1: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 3
inet 10.88.88.2 netmask ffffff00 broadcast 10.88.88.255
ether 52:8d:42:57:32:22
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@coal-nat ~]# ping -i net1 10.88.88.230
10.88.88.230 is alive
[root@coal-nat ~]# ping -i net1 10.88.88.200
10.88.88.200 is alive
[root@coal-nat ~]#Dan McDonald commented on 2025-07-15T15:48:48.531-0400 (edited 2025-07-15T15:50:48.812-0400):
Additional testing, using Kebecloud VM omnios which is an OmniOS guest inside BHYVE. All tests using illumos primitives in the guest, and Triton’s ADMINUI with operator privileges:
- By default omnios has no anti-spoofing bypasses.
Bypass changes via ADMINUI for IP spoofing get tested with adding addresses to a plumbed guest NIC. e.g. ifconfig vioif0:1 plumb 172.24.4.199/24 up where vioif0 has a 172.24.4.X address already. Changing this flag works before 6892, and should after.
Adding a vnic with a unique MAC is done with the combination of dladm create-vnic and ifconfig.
Final configuration of the guest is:
vioif0: flags=1000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4> mtu 1500 index 2
inet 172.24.4.147 netmask ffffff00 broadcast 172.24.4.255
ether 90:b8:d0:e9:10:8b
vioif0:1: flags=1000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4> mtu 1500 index 2
inet 172.24.4.199 netmask ffffff00 broadcast 172.24.4.255
macbypass0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 172.24.4.200 netmask ffffff00 broadcast 172.24.4.255
ether 2:8:20:12:99:63 Before 6892 having bypass changes for MAC spoofing are ineffective. FURTHERMORE, if macbypass0 is plumbed it stops traffic from reaching vioif0, possibly due to mac confusion.
Dan McDonald commented on 2025-07-16T00:45:37.353-0400:
AFTER 6892 things change. The standalone SmartOS stuff works in an improved fashion per earlier tests. On a Triton CN, for ANY NIC (native, BHYVE, etc.) to set the allowed_unfiltered_promisc field you MUST use NAPI’s UpdateNic primitive on the headnode. This was true before this change, and will be after it, though NOW it will work with BHYVE. Testing on an OmniOS guest using a vnic assigned to a zone works rather well.
# ifconfig -a ; netstat -rnc
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vioif0: flags=1000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4> mtu 1500 index 2
inet 172.24.4.156 netmask ffffff00 broadcast 172.24.4.255
ether 90:b8:d0:7d:53:4c
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
vioif0: flags=20002000940<RUNNING,PROMISC,MULTICAST,IPv6> mtu 1500 index 2
inet6 ::/0
ether 90:b8:d0:7d:53:4c
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default 172.24.4.1 UG 2 1
127.0.0.1 127.0.0.1 UH 2 0 lo0
172.24.4.0/24 172.24.4.156 U 3 533 vioif0
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------- -----
::1 ::1 UH 2 0 lo0
# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / ipkg shared
1 bypass running /zones/bypass lipkg excl
# zlogin bypass
[Connected to zone 'bypass' pts/1]
Last login: Wed Jul 16 04:44:42 2025 on pts/1
OmniOS r151054 omnios-r151054-180b86b9dd July 2025
root@bypass:~# ifconfig -a ; netstat -rnc
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
macbypass0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.24.4.201 netmask ffffff00 broadcast 172.24.4.255
ether 2:8:20:30:d1:29
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
macbypass0: flags=20002000840<RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 ::/0
ether 2:8:20:30:d1:29
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default 172.24.4.1 UG 2 1
127.0.0.1 127.0.0.1 UH 2 0 lo0
172.24.4.0/24 172.24.4.201 U 4 8 macbypass0
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------- -----
::1 ::1 UH 2 0 lo0
root@bypass:~# ping google.com
google.com is alive
root@bypass:~#
logout
[Connection to zone 'bypass' pts/1 closed]
# ping google.com
google.com is alive
# Dan McDonald commented on 2025-07-16T11:44:08.281-0400:
Of note: While testing this I triggered a kernel panic in mac_sw_lso() on a promiscuous delivery path, but the delivery path (mac_sw_lso()) needs to be more robust against certain kinds of failures.