jperkin what's the new hostname of what used to be pkgsrc.smartos.org ?

Or if this is the correct one, it is at least unreachable for me at home and work, it points to www.svc.78b95b46-e120-4408-8a54-e4940ed364d6.us-central-1.triton.zone. 28 IN A 192.207.255.7

yeh it hasn't changed, and is up for me

you're missing a 6 at the end there..

looks ok from netbsd.org too

damn, was hoping the viona tx change would help with netbsd bhyve instability but it still sucks

Hmm works if I force the route over VPN too

I guess my ISP must be dropping it somewhere

OK just a me issue then

about viona tx, what kind of instability are you seeing?

Have you tried doubling the vqsize ?

just oddness which is what makes it very difficult to track down, system seems fine for a bit but then networking just stops working, though new connections are sometimes fine, and I occasionally see panics that don't make much sense

similar to what others have reported to the list where openbsd pf in a vm just stops after a while

haven't messed with vqsize, happy to try anything!

i have mine set to 16k for all my freebsd vms

unfortunately it's not so easy on smartos as the viona bhyve args are hardcoded in boot.c

ah, though bhyve accepts last arg as the one it uses, so lets see if bhyve_extra_opts works

ok that's now running, let's see if it helps (FTR, set bhyve_extra_opts to "-o config.dump=1", looked at platform.log to get syntax, then reset opts to "-o pci.0.6.0.vqsize=32768")

well, rsync hasn't died yet which is a good sign, usually it doesn't get past packages named [A-Z]*, but things are usually a bit better after a fresh boot

yeh no good, still hangs, tried both 32k and 16k

sjorge: I wonder if your isp is blocking 192.0.0.0/8 instead of just 192.168.0.0/16?

heh, reminds me of the time we (bbc, solid engineering team) got merged with a failed streaming .com (sigh), they were wondering why some people in ireland couldn't connect to their infrastructure - turned out they were using 192.160/16 thinking it was internal..

Yeah, I've seen a bunch of stuff like that over the years.

@sjorge we were seeing some loss over Zayo to EDPNET; I've added this AS to our route optimization; would be interesting to see if this helps

i'll remove the route to force it over my vpn and check again

seems to be reachable, getting about 200kb/s, less than over vpn, but at least it's working now!

jperkin: is the absence of gcc10 from trunk a temporary thing?

sjorge: We've done some checks against the IP you show up with on IRC, and by our measurement we're getting >75% packet loss to that ASN.

But sometimes routers deprioritize echo replies, so that might be a bit misleading.

pjustice: do you still require it? it was deliberately dropped as it's unused since 21.4.0 and building additional gcc's is quite expensive.

if you don't have specific gcc requirements then 'build-essential' will always pull in the correct version for your image

I'll fix my $%^&* then. Thanks!

cool, if there are legitimate requests for older versions then of course I'll add it back, but generally you'd want to use the exact compiler used by all of the other software, otherwise you run into potential runtime issues (e.g. multiple libstdc++), plus having to install additional gcc*-libs packages for everything

21.4.0 was gcc10, 22.4.0 gcc12, trunk and 23.4.0 in a few weeks are gcc13

I may have had something somewhere that didn't want to build due to the ever increasing strictness of the compilers, but if I find that I'll cope somehow.

bahamat: I just fired off an mtr run and see around 80-90% loss too

basically once it hits zayo in france

Yeah :-/

Unfortunately, that's outside of where we can control it.

If we're a zayo customer (I'll need to check on that), we might be able to report this as an issue, but other than that it's basically up to them to deal with it.

i'll route it back through mullvad for now

popping put in the US seems side step those hops

I have a handful of systems where I used pkg_alternatives to set the desired version. (Yeah, I know...)

What's the best way to clean that up so that the build-essential depended version is what gets used?

that reminds me, i should talk to gordon to see if he's ok w/ the mdns support in smb

(looking at the mailing list)

he had talked about maybe making it plugin based, but that gets messy if you want to support advertising an smb share as a time machine volume

at least just running a command and such

apparently some linux systems will also advertise NFS shares via mdns, but i've not found anything to tell if there's anything that actually consumes the info

danmcd I just make changes to OS-4525, but I really don't know what we should return for TCP states that don't exist in Linux, I think whatever should be better that the current situation where is no TCP_INFO in LX.

s/make/made/g

neirac: I see. You're very close. I think I introduced one piece of merge hell, and I apologize.

Also there was one mapping decision you made that wasn't documented in the comment block (TCPS_BOUND in illumos maps to LISTEN in Linux as there's no BOUND in linux...).

Fix the nits, get some test results I can paste into the OS-4525 ticket, and we can take this in.

danmcd I did the native TCP_INFO first, but it really needs more testing and changes to software to start using it, and also really know what every tcp field means if we implement the same Linux fields, but really maybe just push 0s to the fields we don't have and data to the ones that have the same meaning that in Linux.

as rmustacc suggested, doing the LX part first is the easier path, and also Linux apps already are using the tcp option and we don't.

Agree about with RM's suggestion; and the wrinkles I mentioned are exactly the sorts of things he mentioned.

jperkin also have you tried with the e1000 nic type for your netbsd vms ?

danmcd thanks!, I'll try to test this during the night.