[Package Issue]: TheDocumentFoundation.LibreOffice

[TheCodeingPadawan]

Please confirm these before moving forward

• I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
• I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Installation issue.

Brief description of your issue

When trying to install LibreOffice via winget, the download keeps stopping.
The thing is, it will be downloading fine, but winget seems to think it is stalling.
It looks to be trying to read the file before it is done.

Steps to reproduce

try and install libreoffice and see it stalling. You can keep spamming the command and it will eventually fully download and successfully install.

Actual behavior

Will be downloading, then thinks its stalled or something and trys again. It will then keep downloading, then trys to read the Executable before it is done.

Expected behavior

It should download in one go, and wait for the download to finish before attempting to install.

Environment

Windows Package Manager (Preview) v1.28.100-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.6899
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.28.100.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                E:\Users\~~REDACTED~~\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled
PS C:\WINDOWS\system32>

Screenshots and Logs

[Dragon1573]

👀 Unable to reproduce. Is it caused by your network issue?

[TheCodeingPadawan]

Odd. So running winget download --skip-dependencies TheDocumentFoundation.LibreOffice -d .\bin\
I get the same problem. What is odd however, this problem is only happening with TheDocumentFoundation.LibreOffice package.

I ran winget update --all and successfully downloaded and installed 60 other packages. So what network problem would allow for all but the data from one source to download correctly?

[TheCodeingPadawan]

PS C:\WINDOWS\system32> (Invoke-WebRequest ifconfig.me/ip).Content.Trim()
~~REDACTED~~ (ISP IP)
PS C:\WINDOWS\system32> nslookup download.documentfoundation.org
Server:  4c28b70ab5e8
Address:  10.0.0.243

Non-authoritative answer:
Name:    vm185.documentfoundation.org
Addresses:  2a00:1828:a012:185::1
          89.238.68.185
Aliases:  download.documentfoundation.org

PowerShell is correctly being split tunneled outside of my VPN, so it cannot be a IP block from a VPN address filter.
The domain name is successfully being looked up and serving a correct response. So a DNS issue is unlikely.

[TheCodeingPadawan]

Ok. solved it.

Adding PowerShell to the split tunnel config, does not mean that commands executed in PowerShell are afforded the same connection rules.

After tracking down where the winget executable is actively stored on the system. Adding a split tunnel rule for C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.28.100.0_x64__8wekyb3d8bbwe\winget.exe not only allowed the file to be downloaded quicker, but also had no dropouts.

documentfoundation.org must have some kind of IP based rate limiting/bandwidth capping going on that is affecting VPN IP addresses.