Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Dag-Erling Smørgrav wrote: > Yuri Pankov writes: >> There's apparently a bug in VMware Workstation NAT implementation, >> [...] The patch itself is attached. > > Could you please open a differential and add me as reviewer? https://reviews.freebsd.org/D18636 And there's already a PR for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234426 signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <865zvkpphn@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg rav?= w rites: > Cy Schubert writes: > > I know our code is full of workarounds and theirs probably too. The > > question is should we? IMO no. > > Unfortunately, the world is imperfect and does not care about your > opinion. Correct. I know that too well. > 90% of the hardware we run on deviates from the spec in some > way or another and requires workarounds in the kernel. We even have a > whole system of quirks for disks and USB devices. Libfetch contains > workarounds for buggy HTTP servers. OpenSSH has hundreds of lines of > code devoted to identifying the server and selecting workarounds to > apply. Without those workarounds, FreeBSD would not be a viable piece > of software. Wishing they weren't needed is a waste of time and energy. Well, the patch isn't a hackish as some workounds. This probably doesn't warrant a MK_option however since it changes the default, a mention in the man page should be made. I'm still of the opinion that a management solution would be better, which I'm sure RH is taking. I've been in this business long enough to know that it's a miracle that any of this stuff works. Much of it is held together with bubble gum and string. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Yuri Pankov writes: > There's apparently a bug in VMware Workstation NAT implementation, > [...] The patch itself is attached. Could you please open a differential and add me as reviewer? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. I don't speak for them, but I assure you that both their code and ours are full of workarounds for bugs in third-party software and hardware, and it is ridiculous to claim otherwise. > No. We do like Red Hat does. Advise the customer to use a workaround > until the other vendor fixes their code. With respect, that's not your decision. It's mine. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > I know our code is full of workarounds and theirs probably too. The > question is should we? IMO no. Unfortunately, the world is imperfect and does not care about your opinion. 90% of the hardware we run on deviates from the spec in some way or another and requires workarounds in the kernel. We even have a whole system of quirks for disks and USB devices. Libfetch contains workarounds for buggy HTTP servers. OpenSSH has hundreds of lines of code devoted to identifying the server and selecting workarounds to apply. Without those workarounds, FreeBSD would not be a viable piece of software. Wishing they weren't needed is a waste of time and energy. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <86pntszlae@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg rav?= w rites: > Cy Schubert writes: > > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. > > I don't speak for them, but I assure you that both their code and ours > are full of workarounds for bugs in third-party software and hardware, > and it is ridiculous to claim otherwise. I know our code is full of workarounds and theirs probably too. The question is should we? IMO no. It's yet another thing that diverges from baseline and that adds support costs (well, ok we're not a for profit business but you get the idea). Sure, you may be the person to support ssh here but divergence from baseline is usually not a good thing. When I was developer as a living management would rule against this kind of thing. Their rationale at the time was, "what if you're away?" At the time I'd curse at them but thinking about it years later, they did have a point. > > > No. We do like Red Hat does. Advise the customer to use a workaround > > until the other vendor fixes their code. > > With respect, that's not your decision. It's mine. With respect, I disagree with your decision then. Please don't make that decision because your going to show me though. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > Add it to ssh_config or sshd_config if one must but have VMware fix > their bugs. Putting workarounds in our O/S to work around a bug in some > other vendor's virtualization is something I don't support. It's something we do *all the time*. Otherwise we'd just be a toy OS that hobbyists played with in the weekends on an old spare machine they keep in a basement closet. > If we must > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > in src.conf. Then it's useless. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <861s681ypd@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg rav?= w rites: > Cy Schubert writes: > > Add it to ssh_config or sshd_config if one must but have VMware fix > > their bugs. Putting workarounds in our O/S to work around a bug in some > > other vendor's virtualization is something I don't support. > > It's something we do *all the time*. Otherwise we'd just be a toy OS > that hobbyists played with in the weekends on an old spare machine they > keep in a basement closet. Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. > > > If we must > > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > > in src.conf. > > Then it's useless. No. We do like Red Hat does. Advise the customer to use a workaround until the other vendor fixes their code. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <82004750-097a-47e5-9981-86b4b7a5f...@gmail.com>, Enji Cooper writes : > > On Dec 22, 2018, at 1:03 PM, Cy Schubert = > wrote: > > =E2=80=A6 > > > Regarding the Red Hat bugzilla bug, looks like they're doing the right > > thing by reaching out to VMware. This should be our position as well. > > Add it to ssh_config or sshd_config if one must but have VMware fix > > their bugs. Putting workarounds in our O/S to work around a bug in = > some > > other vendor's virtualization is something I don't support. If we must > > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable = > it > > in src.conf. > > This is the reason why I CCed mp@ :).. Mark works for VMware (I worked = > with him a bit when I was at Isilon). > > =E2=80=A6 > > > We, FreeBSD, should try to open a ticket or reach out to VMware to add > > a +1 to the issue that RH has already opened. This is the right thing > > to do. In this case we should consider ourselves an O/S vendor too, > > which BTW we are. > > Yes, but unless there=E2=80=99s a champion internal to the project = > driving this, it=E2=80=99s up to individual users to drive the bug = > report/fix. If, however, there were regular regression tests run with = > VMware (and this can be done with pyvmomi/paramiko, etc), then we the = > project could provide this guarantee to VMware and vice versa if VMware = > invested the time in making this so--which I thought they did with = > 10.x=E2=80=A6 but if they don=E2=80=99t have an easy way to verify = > changes, there=E2=80=99s a bit of a chicken and egg problem. I'm suggesting we do. Regression tests might require that FreeBSD have a VMware cluster of one or preferably two machines somewhere. That is if VMware is willing to "help" out. The reason I suggest a cluster of two is vmotion can negatively affect some applications (Oracle RAC comes to mind). It would be interesting to find out how FreeBSD and apps running on FreeBSD react to being vmotioned from one ESXi host to another. Testing vCPU and vRAM hot add are other items that should be in our test suite. How well would FreeBSD work with vNUMA? > > > BTW the 2018-11-08 entry in the RH bug talks about adding the > > workaround to sshd_config. > > =E2=80=A6 which is what I did instead of making the code change. Does this suggest that sshd on servers running under VMware are also affected, i.e. ssh session from a computer not running on VMware such as from real hardware or a from PuTTY session o a PC to sshd on a VM? > > Thanks so very much for the patch and (more importantly) for the = > discussion/solution Yuri!! I really appreciate your unblocking me. Yes, thank you Yuri for pointing out the problem and providing a solution. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 22, 2018, at 1:03 PM, Cy Schubert wrote: … > Regarding the Red Hat bugzilla bug, looks like they're doing the right > thing by reaching out to VMware. This should be our position as well. > Add it to ssh_config or sshd_config if one must but have VMware fix > their bugs. Putting workarounds in our O/S to work around a bug in some > other vendor's virtualization is something I don't support. If we must > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > in src.conf. This is the reason why I CCed mp@ :).. Mark works for VMware (I worked with him a bit when I was at Isilon). … > We, FreeBSD, should try to open a ticket or reach out to VMware to add > a +1 to the issue that RH has already opened. This is the right thing > to do. In this case we should consider ourselves an O/S vendor too, > which BTW we are. Yes, but unless there’s a champion internal to the project driving this, it’s up to individual users to drive the bug report/fix. If, however, there were regular regression tests run with VMware (and this can be done with pyvmomi/paramiko, etc), then we the project could provide this guarantee to VMware and vice versa if VMware invested the time in making this so--which I thought they did with 10.x… but if they don’t have an easy way to verify changes, there’s a bit of a chicken and egg problem. > BTW the 2018-11-08 entry in the RH bug talks about adding the > workaround to sshd_config. … which is what I did instead of making the code change. Thanks so very much for the patch and (more importantly) for the discussion/solution Yuri!! I really appreciate your unblocking me. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>, Yuri Pankov write s: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --e7sW91Qf9WxzTaujtGEdAimN5k2EtpJ6Q > Content-Type: multipart/mixed; boundary="3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm"; > protected-headers="v1" > From: Yuri Pankov > To: Cy Schubert > Cc: Mark Peek , Enji Cooper , > Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= > , freebsd-current > Message-ID: <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net> > Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 > changes > References: <20181027.wbmkrgwj050...@slippy.cwsent.com> > In-Reply-To: <20181027.wbmkrgwj050...@slippy.cwsent.com> > > --3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > Cy Schubert wrote: > > In message , Yuri=20 > > Pankov write > > s: > >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH > >> Content-Type: multipart/mixed; boundary=3D"c7yUHUJpZYpJqOrOWLAb4sE3Rmh= > 2alrdi"; > >> protected-headers=3D"v1" > >> From: Yuri Pankov > >> To: Cy Schubert > >> Cc: Mark Peek , Enji Cooper , > >> Warner Losh , =3D?UTF-8?Q?Dag-Erling_Sm=3Dc3=3Db8rgra= > v?=3D > >> , freebsd-current > >> Message-ID: > >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8= > p1 > >> changes > >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> > >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> > >> > >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi > >> Content-Type: text/plain; charset=3Dutf-8 > >> Content-Language: en-US > >> Content-Transfer-Encoding: quoted-printable > >> > >> Cy Schubert wrote: > >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=3D= > 20 > >>> Pankov write > >>> s: > >>>> Yuri Pankov wrote: > >>>>> In-Reply-To: ai=3D > >> > >>> l.gmail. > >>>>> com> > >>>>> Mark Peek wrote: > >>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > > >>> wro=3D3D > >>>>> te: > >>>>>> =3D3D20 > >>>>>>> > >>>>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote= > : > >>>>>>>> > >>>>>>>> Mark Peek wrote: > >>>>>>>>> Thanks for the cc:. I forwarded the original report on to an=3D= > 20 > >>> interna=3D3D > >>>>> l > >>>>>>>>> VMware desktop product contact. > >>>>>>>> > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>>> What version of Workstation or Fusion is this occurring on? I=3D= > 20 > >>> saw > >>>>>>>>> Workstation 14 mentioned but curious if it occurs on=3D20 > >>> Workstation 15 > >>>>>>>>> (latest). > >>>>>>>> > >>>>>>>> Running the latest available for download: 15.0.2 build-10952284= > =2E > >>>>>>> > >>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=3D= > 20 > >>> wasn=3D3DE2=3D3D > >>>>> =3D3D80=3D3D99t > >>>>>>> affecting me on 10.x. I didn=3D3DE2=3D3D80=3D3D99t install 11.0.0= > , so I=3D20 > >>> don=3D3DE2=3D3D80=3D3D99=3D3D > >>>>> t know if it > >>>>>>> affects that version... > >>>>>>> > >>>>>>> Thanks so much! > >>>>>>> > >>>>>>> -Enji > >>>>>> =3D3D20 > >>>>>> =3D3D20 > >>>>>> BTW, there appears to be a workaround here using -o=3D20 > >>> 'IPQoS=3D3D3Dthroughput=3D3D > >>>>> ' > >>>>>> (untested by me). I've seen the issue forwarded internally but no=3D= > 20 > >>> furth=3D3D > >>>>> er > >>>>>> discussions yet. > >>>>>> =3D3D20 > >>>>>> https://communities.vmware.com/thread/590825 > >>>> > >>>> Yes, tha
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message , Yuri > Pankov write > s: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH >> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi"; >> protected-headers="v1" >> From: Yuri Pankov >> To: Cy Schubert >> Cc: Mark Peek , Enji Cooper , >> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= >> , freebsd-current >> Message-ID: >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 >> changes >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi >> Content-Type: text/plain; charset=utf-8 >> Content-Language: en-US >> Content-Transfer-Encoding: quoted-printable >> >> Cy Schubert wrote: >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20 >>> Pankov write >>> s: >>>> Yuri Pankov wrote: >>>>> In-Reply-To: > >>> l.gmail. >>>>> com> >>>>> Mark Peek wrote: >>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper >>> wro=3D >>>>> te: >>>>>> =3D20 >>>>>>> >>>>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>>>>>>> >>>>>>>> Mark Peek wrote: >>>>>>>>> Thanks for the cc:. I forwarded the original report on to an=20 >>> interna=3D >>>>> l >>>>>>>>> VMware desktop product contact. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>>> What version of Workstation or Fusion is this occurring on? I=20 >>> saw >>>>>>>>> Workstation 14 mentioned but curious if it occurs on=20 >>> Workstation 15 >>>>>>>>> (latest). >>>>>>>> >>>>>>>> Running the latest available for download: 15.0.2 build-10952284. >>>>>>> >>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20 >>> wasn=3DE2=3D >>>>> =3D80=3D99t >>>>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20 >>> don=3DE2=3D80=3D99=3D >>>>> t know if it >>>>>>> affects that version... >>>>>>> >>>>>>> Thanks so much! >>>>>>> >>>>>>> -Enji >>>>>> =3D20 >>>>>> =3D20 >>>>>> BTW, there appears to be a workaround here using -o=20 >>> 'IPQoS=3D3Dthroughput=3D >>>>> ' >>>>>> (untested by me). I've seen the issue forwarded internally but no=20 >>> furth=3D >>>>> er >>>>>> discussions yet. >>>>>> =3D20 >>>>>> https://communities.vmware.com/thread/590825 >>>> >>>> Yes, that's exactly what the patch attached to original message does i= >> f >>>> we are running as a VMware guest. The workaround is known and it work= >> s, >>>> but it's not immediately clear and I just wanted it to be the default >>>> for the time being. >>> =20 >>> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20 >>> intended? >> >> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can >> be ripped out easily when no longer needed, and yes, it's enabled >> unconditionally for now. And the check itself is if 'kern.vm_guest' >> reports 'vmware'. > > It doesn't look that conditional to me. Indeed, and that's what I said exactly :-) The added code is enabled unconditionally, and the added code also has a check for vmware guest. The ifdefs are there only to show that this is local addition, nothing else. I'm not saying it needs to be done this way, this is just something I did quickly after installing yet another VM and forgetting to modify my ~/.ssh/config to include the workaround. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message , Yuri
Pankov write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH
> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi";
> protected-headers="v1"
> From: Yuri Pankov
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID:
> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1
> changes
> References: <20181009.wbmk9h5t050...@slippy.cwsent.com>
> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com>
>
> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Cy Schubert wrote:
> > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20
> > Pankov write
> > s:
> >> Yuri Pankov wrote:
> >>> In-Reply-To:
> > l.gmail.
> >>> com>
> >>> Mark Peek wrote:
> >>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper
> > wro=3D
> >>> te:
> >>>> =3D20
> >>>>>
> >>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
> >>>>>>
> >>>>>> Mark Peek wrote:
> >>>>>>> Thanks for the cc:. I forwarded the original report on to an=20
> > interna=3D
> >>> l
> >>>>>>> VMware desktop product contact.
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>>> What version of Workstation or Fusion is this occurring on? I=20
> > saw
> >>>>>>> Workstation 14 mentioned but curious if it occurs on=20
> > Workstation 15
> >>>>>>> (latest).
> >>>>>>
> >>>>>> Running the latest available for download: 15.0.2 build-10952284.
> >>>>>
> >>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20
> > wasn=3DE2=3D
> >>> =3D80=3D99t
> >>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20
> > don=3DE2=3D80=3D99=3D
> >>> t know if it
> >>>>> affects that version...
> >>>>>
> >>>>> Thanks so much!
> >>>>>
> >>>>> -Enji
> >>>> =3D20
> >>>> =3D20
> >>>> BTW, there appears to be a workaround here using -o=20
> > 'IPQoS=3D3Dthroughput=3D
> >>> '
> >>>> (untested by me). I've seen the issue forwarded internally but no=20
> > furth=3D
> >>> er
> >>>> discussions yet.
> >>>> =3D20
> >>>> https://communities.vmware.com/thread/590825
> >>
> >> Yes, that's exactly what the patch attached to original message does i=
> f
> >> we are running as a VMware guest. The workaround is known and it work=
> s,
> >> but it's not immediately clear and I just wanted it to be the default
> >> for the time being.
> >=20
> > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20
> > intended?
>
> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can
> be ripped out easily when no longer needed, and yes, it's enabled
> unconditionally for now. And the check itself is if 'kern.vm_guest'
> reports 'vmware'.
It doesn't look that conditional to me.
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+= crypto
CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
.endif
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
.include
.PATH: ${SSHDIR}
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri > Pankov write > s: >> Yuri Pankov wrote: >>> In-Reply-To: l.gmail. >>> com> >>> Mark Peek wrote: On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wro= >>> te: =20 > >> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >> >> Mark Peek wrote: >>> Thanks for the cc:. I forwarded the original report on to an > interna= >>> l >>> VMware desktop product contact. >> >> Thank you. >> >>> What version of Workstation or Fusion is this occurring on? I > saw >>> Workstation 14 mentioned but curious if it occurs on > Workstation 15 >>> (latest). >> >> Running the latest available for download: 15.0.2 build-10952284. > > This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it > wasn=E2= >>> =80=99t > affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I > don=E2=80=99= >>> t know if it > affects that version... > > Thanks so much! > > -Enji =20 =20 BTW, there appears to be a workaround here using -o > 'IPQoS=3Dthroughput= >>> ' (untested by me). I've seen the issue forwarded internally but no > furth= >>> er discussions yet. =20 https://communities.vmware.com/thread/590825 >> >> Yes, that's exactly what the patch attached to original message does if >> we are running as a VMware guest. The workaround is known and it works, >> but it's not immediately clear and I just wanted it to be the default >> for the time being. > > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this > intended? It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can be ripped out easily when no longer needed, and yes, it's enabled unconditionally for now. And the check itself is if 'kern.vm_guest' reports 'vmware'. > Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and > Windows) running on VMware clusters with NSX network (with plans to > totally virtualize the network), we've noticed other network > quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris > <--> Linux. I'm not surprised that this regression also exists. > > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri Pankov write s: > Yuri Pankov wrote: >> In-Reply-To: > com> >> Mark Peek wrote: >> > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wro= >> te: >> >=20 >> >> >> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >> >>> >> >>> Mark Peek wrote: >> Thanks for the cc:. I forwarded the original report on to an interna= >> l >> VMware desktop product contact. >> >>> >> >>> Thank you. >> >>> >> What version of Workstation or Fusion is this occurring on? I saw >> Workstation 14 mentioned but curious if it occurs on Workstation 15 >> (latest). >> >>> >> >>> Running the latest available for download: 15.0.2 build-10952284. >> >> >> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn=E2= >> =80=99t >> >> affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I don=E2=80=99= >> t know if it >> >> affects that version... >> >> >> >> Thanks so much! >> >> >> >> -Enji >> >=20 >> >=20 >> > BTW, there appears to be a workaround here using -o 'IPQoS=3Dthroughput= >> ' >> > (untested by me). I've seen the issue forwarded internally but no furth= >> er >> > discussions yet. >> >=20 >> > https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does if > we are running as a VMware guest. The workaround is known and it works, > but it's not immediately clear and I just wanted it to be the default > for the time being. The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this intended? Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and Windows) running on VMware clusters with NSX network (with plans to totally virtualize the network), we've noticed other network quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris <--> Linux. I'm not surprised that this regression also exists. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
On Sat, Dec 22, 2018, 11:03 AM Yuri Pankov Mark Peek wrote: > > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wrote: > > > >> > >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > >>> > >>> Mark Peek wrote: > Thanks for the cc:. I forwarded the original report on to an internal > VMware desktop product contact. > >>> > >>> Thank you. > >>> > What version of Workstation or Fusion is this occurring on? I saw > Workstation 14 mentioned but curious if it occurs on Workstation 15 > (latest). > >>> > >>> Running the latest available for download: 15.0.2 build-10952284. > >> > >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t > >> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it > >> affects that version... > >> > >> Thanks so much! > >> > >> -Enji > > > > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > > (untested by me). I've seen the issue forwarded internally but no further > > discussions yet. > > > > https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does if > we are running as a VMware guest. The workaround is known and it works, > but it's not immediately clear and I just wanted it to be the default > for the time being. > Fixes my world... Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > >> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>> >>> Mark Peek wrote: Thanks for the cc:. I forwarded the original report on to an internal VMware desktop product contact. >>> >>> Thank you. >>> What version of Workstation or Fusion is this occurring on? I saw Workstation 14 mentioned but curious if it occurs on Workstation 15 (latest). >>> >>> Running the latest available for download: 15.0.2 build-10952284. >> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t >> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it >> affects that version... >> >> Thanks so much! >> >> -Enji > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > (untested by me). I've seen the issue forwarded internally but no further > discussions yet. > > https://communities.vmware.com/thread/590825 Yes, that's exactly what the patch attached to original message does if we are running as a VMware guest. The workaround is known and it works, but it's not immediately clear and I just wanted it to be the default for the time being. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > > > On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > > > > Mark Peek wrote: > >> Thanks for the cc:. I forwarded the original report on to an internal > >> VMware desktop product contact. > > > > Thank you. > > > >> What version of Workstation or Fusion is this occurring on? I saw > >> Workstation 14 mentioned but curious if it occurs on Workstation 15 > >> (latest). > > > > Running the latest available for download: 15.0.2 build-10952284. > > This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t > affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it > affects that version... > > Thanks so much! > > -Enji BTW, there appears to be a workaround here using -o 'IPQoS=throughput' (untested by me). I've seen the issue forwarded internally but no further discussions yet. https://communities.vmware.com/thread/590825 Mark ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > > Mark Peek wrote: >> Thanks for the cc:. I forwarded the original report on to an internal >> VMware desktop product contact. > > Thank you. > >> What version of Workstation or Fusion is this occurring on? I saw >> Workstation 14 mentioned but curious if it occurs on Workstation 15 >> (latest). > > Running the latest available for download: 15.0.2 build-10952284. This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it affects that version... Thanks so much! -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > Thanks for the cc:. I forwarded the original report on to an internal > VMware desktop product contact. Thank you. > What version of Workstation or Fusion is this occurring on? I saw > Workstation 14 mentioned but curious if it occurs on Workstation 15 > (latest). Running the latest available for download: 15.0.2 build-10952284. > On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > >> I've been hit by this as well. At least two others on IRC have had the >> same issue. >> >> Warner >> >> On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: >> >>> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: Hi, There's apparently a bug in VMware Workstation NAT implementation, made visible by the change to default values of IPQoS in OpenSSH 7.8p1, making all ssh connections from the guest behind the NAT to fail with obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: Broken pipe". I wonder if we could integrate the attached patch (or some smarter version of it) for the time being as the bug affects several major WS releases, and it's not immediately clear where the problem is. The change itself: >>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 The bug reports (some of them): https://bugzilla.redhat.com/show_bug.cgi?id=1624437 https://communities.vmware.com/message/2803219#2803219 The patch itself is attached. >>> >>> Cool… yeah… I’ve been running into this issue for a while with >>> VMware Fusion 11.0.1. >>> I CCed mp@ for visibility. >>> Thanks! >>> -Enji >>> >> > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Thanks for the cc:. I forwarded the original report on to an internal VMware desktop product contact. What version of Workstation or Fusion is this occurring on? I saw Workstation 14 mentioned but curious if it occurs on Workstation 15 (latest). Mark On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > I've been hit by this as well. At least two others on IRC have had the > same issue. > > Warner > > On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: > >> >> > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: >> > >> > Hi, >> > >> > There's apparently a bug in VMware Workstation NAT implementation, made >> > visible by the change to default values of IPQoS in OpenSSH 7.8p1, >> > making all ssh connections from the guest behind the NAT to fail with >> > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: >> > Broken pipe". >> > >> > I wonder if we could integrate the attached patch (or some smarter >> > version of it) for the time being as the bug affects several major WS >> > releases, and it's not immediately clear where the problem is. >> > >> > The change itself: >> > >> > >> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 >> > >> > The bug reports (some of them): >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 >> > https://communities.vmware.com/message/2803219#2803219 >> > >> > The patch itself is attached. >> > >> >> Cool… yeah… I’ve been running into this issue for a while with >> VMware Fusion 11.0.1. >> I CCed mp@ for visibility. >> Thanks! >> -Enji >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
I've been hit by this as well. At least two others on IRC have had the same issue. Warner On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: > > > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: > > > > Hi, > > > > There's apparently a bug in VMware Workstation NAT implementation, made > > visible by the change to default values of IPQoS in OpenSSH 7.8p1, > > making all ssh connections from the guest behind the NAT to fail with > > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: > > Broken pipe". > > > > I wonder if we could integrate the attached patch (or some smarter > > version of it) for the time being as the bug affects several major WS > > releases, and it's not immediately clear where the problem is. > > > > The change itself: > > > > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 > > > > The bug reports (some of them): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 > > https://communities.vmware.com/message/2803219#2803219 > > > > The patch itself is attached. > > > > Cool… yeah… I’ve been running into this issue for a while with > VMware Fusion 11.0.1. > I CCed mp@ for visibility. > Thanks! > -Enji > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: > > Hi, > > There's apparently a bug in VMware Workstation NAT implementation, made > visible by the change to default values of IPQoS in OpenSSH 7.8p1, > making all ssh connections from the guest behind the NAT to fail with > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: > Broken pipe". > > I wonder if we could integrate the attached patch (or some smarter > version of it) for the time being as the bug affects several major WS > releases, and it's not immediately clear where the problem is. > > The change itself: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 > > The bug reports (some of them): > > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 > https://communities.vmware.com/message/2803219#2803219 > > The patch itself is attached. > Cool… yeah… I’ve been running into this issue for a while with VMware Fusion 11.0.1. I CCed mp@ for visibility. Thanks! -Enji signature.asc Description: Message signed with OpenPGP
workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Hi,
There's apparently a bug in VMware Workstation NAT implementation, made
visible by the change to default values of IPQoS in OpenSSH 7.8p1,
making all ssh connections from the guest behind the NAT to fail with
obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
Broken pipe".
I wonder if we could integrate the attached patch (or some smarter
version of it) for the time being as the bug affects several major WS
releases, and it's not immediately clear where the problem is.
The change itself:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
The bug reports (some of them):
https://bugzilla.redhat.com/show_bug.cgi?id=1624437
https://communities.vmware.com/message/2803219#2803219
The patch itself is attached.
diff --git a/crypto/openssh/readconf.c b/crypto/openssh/readconf.c
index f97a6ac72a95..9ed6902a0f46 100644
--- a/crypto/openssh/readconf.c
+++ b/crypto/openssh/readconf.c
@@ -16,6 +16,9 @@
__RCSID("$FreeBSD$");
#include
+#ifdef VMWARE_GUEST_WORKAROUND
+#include
+#endif
#include
#include
#include
@@ -1954,6 +1957,15 @@ fill_default_options(Options * options)
{
char *all_cipher, *all_mac, *all_kex, *all_key;
int r;
+#ifdef VMWARE_GUEST_WORKAROUND
+ char scval[7]; /* "vmware\0" */
+ size_t scsiz = sizeof(scval);
+ int vmwguest = 0;
+
+ if (sysctlbyname("kern.vm_guest", scval, , NULL, 0) == 0 &&
+ strcmp(scval, "vmware") == 0)
+ vmwguest = 1;
+#endif
if (options->forward_agent == -1)
options->forward_agent = 0;
@@ -2088,8 +2100,18 @@ fill_default_options(Options * options)
if (options->visual_host_key == -1)
options->visual_host_key = 0;
if (options->ip_qos_interactive == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_interactive = IPTOS_LOWDELAY;
+ else
+#endif
options->ip_qos_interactive = IPTOS_DSCP_AF21;
if (options->ip_qos_bulk == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_bulk = IPTOS_THROUGHPUT;
+ else
+#endif
options->ip_qos_bulk = IPTOS_DSCP_CS1;
if (options->request_tty == -1)
options->request_tty = REQUEST_TTY_AUTO;
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+= crypto
CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
.endif
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
.include
.PATH: ${SSHDIR}
signature.asc
Description: OpenPGP digital signature
