If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#31
|
|||
|
|||
I just had a radical idea
Char Jackson wrote:
Thanks for the detailed reply. As for the possibility of corrupt updates being shared within the LAN, I assume each update package is signed so that a host knows if it can be trusted. However, if MS isn't taking advantage of the other hosts on the LAN in this way, then I might as well just disable the whole thing. The scary part, even omitting the possibility of malicious tampering, is that updates are not delivered whole from host to host using WUDO. Instead pieces of the update file are delivered and the pieces can come from different hosts through different routes. It was bad enough when you'd get an update (in whole) from Microsoft's WSUS server and had problems getting it installed. With WUDO, rebuilding the update file from pieces adds another potential instability, and you haven't a clue from where the bad update piece originated. The piecemeal approach is to permit resume of the update retrieval (from multiple sending hosts). https://www.deviousweb.com/2015/08/0...-optimization/ "WUDO works a lot like bittorrent. Your computer is used as part of a global peer-to-peer network to allow the distributed delivery of software updates with each person distributing a little bit of the files across multiple computers and helping everyone download updates more quickly." https://thehackernews.com/2015/08/wi...10-update.html "our computer running Windows 10 is used as part of a peer-to-peer network to deliver software updates faster to others, each person distributing a little bit of the files across multiple computers and helping everyone download updates quickly." So, to speed up the download, the P2P client (WUDO) grabs pieces of the file across multiple hosts while retrieving them in parallel streams over the network to rebuild them locally. I'd rather get one complete file and from a known source (Microsoft's WSUS server). There also seem to be a plethora of conditions that will prevent the use of WUDO, so your host ends up using WSUS instead. https://cmma.org/cmma-blog/the-pros-...-optimization/ "No control over content" That point concerns me. While WUDO builds a local cache for P2P distribution of the update (in pieces), it seems it will add more to the local cache for a host than the updates only needed by that particular host. BITS was a known network traffic manager, plus any process can utilize BITS to manage their downloads, like updates to a program and not just for Windows (I've yet, however, to see anyone other than Microsoft using it, but then I'm not knowledgeable about the inner workings of all software regarding their updates). WUDO doesn't use BITS, and why users have been reporting their network getting choked by WUDO. With the problems with WUDO choking your network, its efficiency and parallelism is lost with slow delivery. All because Microsoft, as with everything Windows 10, thinks your computer is their property, so they're going to steal a portion of your PC to use as their distributed server farm. I don't run any variant of Bittorrent or its ilk on my hosts. I certainly don't want a variant from Microsoft. I'd rather schedule a run of WSUSoffline which connects to *Microsoft's* WSUS server. It definitely impacts the usability of the host where it runs and generates lots of traffic (and why I schedule it), and I can tote or FTP its update store to my other hosts over my local network WHEN *I* choose. Just as with Windows 10 updates not being under your control of when and preparing for the update(s) (by closing all your work and saving a backup image since System Restore has proven unreliable), I don't want some other backgrounded update distribution scheme employed to distribute updates to other hosts when I'm not going to apply them there anyway at the time of piecemeal delivery (I disable the BITS and WU services to enforce when *I* want to do the updates). More FM (****ing magic) to go wrong, harder to troubleshoot, doesn't save on network bandwidth (since even in paralleled piecemeal fashion the entire file still has to get sent) and isn't as well backgrounded as BITS, and all under the guise of getting you the updates quicker (which I've yet to see any benchmarking to prove so) but is really to offline some of the update network off Microsoft's servers. |
Ads |
#32
|
|||
|
|||
I just had a radical idea
On 03/17/2019 5:39 PM, VanguardLH wrote:
Char Jackson wrote: Thanks for the detailed reply. As for the possibility of corrupt updates being shared within the LAN, I assume each update package is signed so that a host knows if it can be trusted. However, if MS isn't taking advantage of the other hosts on the LAN in this way, then I might as well just disable the whole thing. The scary part, even omitting the possibility of malicious tampering, is that updates are not delivered whole from host to host using WUDO. Instead pieces of the update file are delivered and the pieces can come from different hosts through different routes. It was bad enough when you'd get an update (in whole) from Microsoft's WSUS server and had problems getting it installed. With WUDO, rebuilding the update file from pieces adds another potential instability, and you haven't a clue from where the bad update piece originated. The piecemeal approach is to permit resume of the update retrieval (from multiple sending hosts). https://www.deviousweb.com/2015/08/0...-optimization/ "WUDO works a lot like bittorrent. Your computer is used as part of a global peer-to-peer network to allow the distributed delivery of software updates with each person distributing a little bit of the files across multiple computers and helping everyone download updates more quickly." https://thehackernews.com/2015/08/wi...10-update.html "our computer running Windows 10 is used as part of a peer-to-peer network to deliver software updates faster to others, each person distributing a little bit of the files across multiple computers and helping everyone download updates quickly." So, to speed up the download, the P2P client (WUDO) grabs pieces of the file across multiple hosts while retrieving them in parallel streams over the network to rebuild them locally. I'd rather get one complete file and from a known source (Microsoft's WSUS server). There also seem to be a plethora of conditions that will prevent the use of WUDO, so your host ends up using WSUS instead. https://cmma.org/cmma-blog/the-pros-...-optimization/ "No control over content" That point concerns me. While WUDO builds a local cache for P2P distribution of the update (in pieces), it seems it will add more to the local cache for a host than the updates only needed by that particular host. BITS was a known network traffic manager, plus any process can utilize BITS to manage their downloads, like updates to a program and not just for Windows (I've yet, however, to see anyone other than Microsoft using it, but then I'm not knowledgeable about the inner workings of all software regarding their updates). WUDO doesn't use BITS, and why users have been reporting their network getting choked by WUDO. With the problems with WUDO choking your network, its efficiency and parallelism is lost with slow delivery. All because Microsoft, as with everything Windows 10, thinks your computer is their property, so they're going to steal a portion of your PC to use as their distributed server farm. I don't run any variant of Bittorrent or its ilk on my hosts. I certainly don't want a variant from Microsoft. I'd rather schedule a run of WSUSoffline which connects to *Microsoft's* WSUS server. It definitely impacts the usability of the host where it runs and generates lots of traffic (and why I schedule it), and I can tote or FTP its update store to my other hosts over my local network WHEN *I* choose. Just as with Windows 10 updates not being under your control of when and preparing for the update(s) (by closing all your work and saving a backup image since System Restore has proven unreliable), I don't want some other backgrounded update distribution scheme employed to distribute updates to other hosts when I'm not going to apply them there anyway at the time of piecemeal delivery (I disable the BITS and WU services to enforce when *I* want to do the updates). More FM (****ing magic) to go wrong, harder to troubleshoot, doesn't save on network bandwidth (since even in paralleled piecemeal fashion the entire file still has to get sent) and isn't as well backgrounded as BITS, and all under the guise of getting you the updates quicker (which I've yet to see any benchmarking to prove so) but is really to offline some of the update network off Microsoft's servers. Yeah, It stinks like bittorrent, so they can shove both of them where the Sun don't shine. Rene |
#33
|
|||
|
|||
I just had a radical idea
On Sun, 17 Mar 2019 17:39:10 -0500, VanguardLH wrote:
Char Jackson wrote: Thanks for the detailed reply. As for the possibility of corrupt updates being shared within the LAN, I assume each update package is signed so that a host knows if it can be trusted. However, if MS isn't taking advantage of the other hosts on the LAN in this way, then I might as well just disable the whole thing. The scary part, even omitting the possibility of malicious tampering, is that updates are not delivered whole from host to host using WUDO. Instead pieces of the update file are delivered and the pieces can come from different hosts through different routes. It was bad enough when you'd get an update (in whole) from Microsoft's WSUS server and had problems getting it installed. With WUDO, rebuilding the update file from pieces adds another potential instability, and you haven't a clue from where the bad update piece originated. The piecemeal approach is to permit resume of the update retrieval (from multiple sending hosts). I'm perfectly comfortable with what you call the scary part because it works just like bittorrent, which you mention in the next paragraph below. https://www.deviousweb.com/2015/08/0...-optimization/ "WUDO works a lot like bittorrent. Your computer is used as part of a global peer-to-peer network to allow the distributed delivery of software updates with each person distributing a little bit of the files across multiple computers and helping everyone download updates more quickly." https://thehackernews.com/2015/08/wi...10-update.html "our computer running Windows 10 is used as part of a peer-to-peer network to deliver software updates faster to others, each person distributing a little bit of the files across multiple computers and helping everyone download updates quickly." So, to speed up the download, the P2P client (WUDO) grabs pieces of the file across multiple hosts while retrieving them in parallel streams over the network to rebuild them locally. I'd rather get one complete file and from a known source (Microsoft's WSUS server). There also seem to be a plethora of conditions that will prevent the use of WUDO, so your host ends up using WSUS instead. https://cmma.org/cmma-blog/the-pros-...-optimization/ "No control over content" That point concerns me. While WUDO builds a local cache for P2P distribution of the update (in pieces), it seems it will add more to the local cache for a host than the updates only needed by that particular host. BITS was a known network traffic manager, plus any process can utilize BITS to manage their downloads, like updates to a program and not just for Windows (I've yet, however, to see anyone other than Microsoft using it, but then I'm not knowledgeable about the inner workings of all software regarding their updates). WUDO doesn't use BITS, and why users have been reporting their network getting choked by WUDO. With the problems with WUDO choking your network, its efficiency and parallelism is lost with slow delivery. All because Microsoft, as with everything Windows 10, thinks your computer is their property, so they're going to steal a portion of your PC to use as their distributed server farm. I don't run any variant of Bittorrent or its ilk on my hosts. I certainly don't want a variant from Microsoft. I'd rather schedule a run of WSUSoffline which connects to *Microsoft's* WSUS server. It definitely impacts the usability of the host where it runs and generates lots of traffic (and why I schedule it), and I can tote or FTP its update store to my other hosts over my local network WHEN *I* choose. Just as with Windows 10 updates not being under your control of when and preparing for the update(s) (by closing all your work and saving a backup image since System Restore has proven unreliable), I don't want some other backgrounded update distribution scheme employed to distribute updates to other hosts when I'm not going to apply them there anyway at the time of piecemeal delivery (I disable the BITS and WU services to enforce when *I* want to do the updates). More FM (****ing magic) to go wrong, harder to troubleshoot, doesn't save on network bandwidth (since even in paralleled piecemeal fashion the entire file still has to get sent) and isn't as well backgrounded as BITS, and all under the guise of getting you the updates quicker (which I've yet to see any benchmarking to prove so) but is really to offline some of the update network off Microsoft's servers. Good points, thanks. |
#34
|
|||
|
|||
I just had a radical idea
Char Jackson wrote:
Thanks for the detailed reply. As for the possibility of corrupt updates being shared within the LAN, I assume each update package is signed so that a host knows if it can be trusted. However, if MS isn't taking advantage of the other hosts on the LAN in this way, then I might as well just disable the whole thing. They're signed. Doesn't matter how they're sliced and diced, a package cannot be installed without the signature working. Change 1 bit of content, the signature will fail. Even when materials come straight from a Windows Update server, we have to assume the delivery method could be compromised in flight. The signing step, is the ultimate protection for that path. That covers MITM attacks. Paul |
#35
|
|||
|
|||
I just had a radical idea
On Mon, 18 Mar 2019 01:12:19 -0400, Paul wrote:
Char Jackson wrote: Thanks for the detailed reply. As for the possibility of corrupt updates being shared within the LAN, I assume each update package is signed so that a host knows if it can be trusted. However, if MS isn't taking advantage of the other hosts on the LAN in this way, then I might as well just disable the whole thing. They're signed. Doesn't matter how they're sliced and diced, a package cannot be installed without the signature working. Change 1 bit of content, the signature will fail. Even when materials come straight from a Windows Update server, we have to assume the delivery method could be compromised in flight. The signing step, is the ultimate protection for that path. That covers MITM attacks. Then, as I suspected, it doesn't matter where update chunks come from. Could be MS, another PC on the LAN, or another PC on the Internet. It's all the same. However, if as you said earlier, the feature doesn't really work, then it's pointless. I might as well disable the feature and get updates from MS. The reason I asked in the first place is that I have about two dozen Win10 VMs, and counting, and it seemed a shame to get updates for each of them separately. I guess that's how it needs to be, though. |
#36
|
|||
|
|||
I just had a radical idea
Char Jackson wrote:
The reason I asked in the first place is that I have about two dozen Win10 VMs, and counting, and it seemed a shame to get updates for each of them separately. I guess that's how it needs to be, though. That's what I use WSUSoffline for. I run it to create a repository that I could network to or tote around on a USB flash drive (to, say, mount in your VMs). I have WSUS offline retrieve updates for several products. Looks like the W100_x64 is for Windows 10 x64 and it's about 9 GB in size. |
#37
|
|||
|
|||
I just had a radical idea
Char Jackson wrote:
Then, as I suspected, it doesn't matter where update chunks come from. Could be MS, another PC on the LAN, or another PC on the Internet. It's all the same. However, if as you said earlier, the feature doesn't really work, then it's pointless. I might as well disable the feature and get updates from MS. The reason I asked in the first place is that I have about two dozen Win10 VMs, and counting, and it seemed a shame to get updates for each of them separately. I guess that's how it needs to be, though. If I knew what the magic recipe was to get DoSvc to work, I'd tell ya :-) I was just annoyed it lay there like a dead fish and didn't do anything. I probably made a mistake somewhere setting it up. Not enough disk space or the like. I prefer software that tells you instantly you fouled up. I don't like experiments with long baselines, where it takes three months to get a budge out of them. I'm just not that patient. In theory, setting up one VM, switching on local DoSvc, then issuing commands to do Windows Update, should be populating its DoSvc cache. Then, installing a second VM, should "listen" to its buddy on the LAN. You then need a recorder on the first VM, to log the amount of traffic that results (to prove that's where the update came from). Due to the "noise level" on Windows 10, it's pretty hard to isolate behaviors and prove they're the exact source of traffic. Win10 could start randomly pulling in cat pictures, while I'm monitoring for DoSvc. It does that for background images for the lock screen. It does that for "Apps" and "App Updates" which are done randomly, and outside the normal Windows Update path. And that sort of **** happens the moment I try to do an HDTune run. We really need service designs, where DoSvc says: "Won't serve content because: Bad mood" "Serving KB123456 to 192.168.1.2" "Saving recently obtained KB123457 to cache" "Discarding KB123456 because: superseded" Paul |
Thread Tools | |
Display Modes | Rate This Thread |
|
|