Hi, can anyone point me in the right direction when it comes to network config for smartos in virtualbox? My smartos install can connect to the outside, but the VMs are unable to.

I am using a Briged Adapter, if that is usefull info

Are the VMs using the same nic tag as the GZ nic you *can* reach?

Yes, there is only one NIC tag and they both use that one

Okay... I wonder if there's a VBox setting for the bridged Adapter where more-than-one-MAC can be assigned to it? Because I *suspect* what's happening is *something* doesn't like more than the GZ's MAC address on that link.

Whether it's VBox, or your VBox host, something's stopping bits from moving.

I take it you can move bits between GZ and NGZ just fine, right?

(1st-order reality check question ^^^ .)

I don't know if bridged mode works, way back when I used nat mode: perkin.org.uk/posts/automated-virtualbox-smartos-installs.html

Oh shit yes this is virtualbox.

I have OmniOS (only global) on VBox on my personal MacBook Pros, and I can't use bridged on there at all, even for the GZ.

Thanks for that reminder jperkin.

jperkin: is there an archive of older binary packages somewhere? I'd like to find unbound-1.17.1nb1 for a test.

pjustice: possibly, all the older releases are archived under /pkgsrc/public/packages in Manta, but if that particular revision was only available for a certain time in e.g. trunk and then updated then no

is your unbound issue easily reproducible? happy to take a look after I'm done with some percona bits

Well, that's part of what I'm trying to determine. Wanted to put back the previous version, as my current understanding of the differences between two systems is basically that the one didn't get restarted and is still running the 1.17.1nb1 version.

(and I'm living in fear of it getting cycled...)

2022Q4 has 1.17.0

Lemme see if the tgz is in manta

trunk only has 1.18.0 now

Yup, that's the issue

Ok, 1.17.0 installed. The problem has vanished. These machines previously had 1.17.1nb1, and the upgrade to 1.18.0 arrived in early September, I think.

I've spent hours poring over the diff between 1.17.1 and 1.18.0, but it's huge.

I'm noticing that 1.18.0 calls sendmsg(), but 1.17.0 doesn't seem to, for queries that generally trigger the misbehavior in 1.18.0.

Ahhh, so there WAS a difference.

pjustice: were you mailing smartos-discuss?

eys

yes

Okay... I wonder if 1.18.0 is doing sendmsg without turning on "xnet sockets" which support the modern sendmsg() semantics?

But the differences, as noted there, have resolved to the package version.

It appears that older versions don't do sendmsg() at all.

I know jperkin understands that issue/problem/design-decision-back-from-sun-days.

Or at least I'm not seeing any.

I saw that up top... fascinating.

Anyway, lemme look at something...

... okay, I have 1.17.1 on my OmniOS zone. I don't see any odd patches in their build of 1.18 (which will likely show up on the next stable, 151048).

Our sendmsg() SHOULDN'T be any different than Omni's.

There are some sendmsg() apps that need "-D_XPG4_2" to use the modern sendmsg().

No idea why your unbound 1.18 is throwing these errors.

dtrace -n 'sendmsg:entry { printf("\n\tsendmsg from: %s", execname);}'

that shows no sendmsg from "unbound" (but if I swap to "send" I see them).

Yes, I'm seeing send() and sendto() happening, but no sendmsg() in 1.17.0.

I haven't had much luck figuring out where to look to see if _XPG4_2 is getting defined in the build.

The choice of which variant of send*() to call seems to come down to which callback gets used -- comm_point_udp_ancil_callback or comm_point_udp_callback

perhaps check if the omnios-extras unbound has extra patches?

pjustice: Are you running virtualbox bridged to a wifi interface?

bahamat: I think that was a different conversation with someone else.

pjustice: Oh, sorry, yes it was..

( bahamat vbox is @jhertz) "ancil" ==> Ancillary data. THIS is why you need sendmsg()./

no worries

Looking up that symbol...

... yeah.. .IPV6_PKTINFO

So to send ancillary data like that you need to use X/Net sockets not normal libsocket ones. (It's a distinction I think we need to kill, but that's a whole #illumos problem, not specific to us in #smartos).

I'm sure jperkin has seen stuff like this in OTHER pkgsrc apps.

Given that, the question would seem to be what defines to the build changed between these two versions.

_XPG4_2 would seem to be a prime candidate.

Did the ...ancil... function get introduced with 1.18 ?

Oooh..

No, I don't think there's really a significant change to the code as regards calling sendmsg. The difference would seem to have to be in defines.

Or linking with `-lxnet`

Both versions are linked with -lsocket

You can cheat by using #define _XPG_42 or whatever it is... this is a problem jperkin is best-suited to solving.

I'm going to have to wander off to an appointment for a bit here. Will check here when I return.