On 8/31/2013 7:23 PM, Jim Henderson wrote:
> On Sat, 31 Aug 2013 19:00:22 -0700, Patrick Elliott wrote:
>
>> Hmm. How about - "Without hunting down some third party tool to do it."?
>
> That might have been a good qualifier to add, yes.
>
>> Though, some things the OS just won't let you do at all. Like, well,
>> nearly any tool used to test network issues is "throttled", as in, in
>> this case, "strangled" by the "protections" added, to prevent certain
>> types of packets, which "might" be from a virus/worm/botnet. I am sure
>> you could, somehow, if you wanted to spend stupid amounts of time
>> hunting for a solution, find a way to turn that off, maybe...
>
> Haven't run into that one.
>
Well. It was, in my case, an attempt to get around the stupid decision 
of my neighbors ISP to block control packets on their modems, so that, 
when there was a problem, you couldn't use tracert, or ping, to check if 
the problem was some place in their network, or if the modem needed to 
be powered down, and back on, or something. So, I tried, instead, on my 
own machine, to run one that generates the same thing, using regular 
TCP/IP. But, since the packets where set to have odd timeouts, and 
contain very little actually "data", the new safeguards flagged them as 
possible DOS traffic, and simply killed them, without ever sending them.

> That's not really an OS issue, though.  That's an HP issue, as
> described.  I don't think you can blame Microsoft for HP's bad design
> decision.
>
> Jim
>
Its more of a "layering" issue. The firewall can block some things, the 
virus scanner others, the HP software is assuming that neither of these 
things are going to be in the way, and.. as near as I can tell, it works 
fine, if, for example, you are running it wireless, or connected "to" 
the router. But, then they got lazy and figured, "Heck, why not connect 
it to the USB using the same thing." Then.. everything gets in the way, 
including an OS that pretty much won't let you find/figure out/fix 
problems like this, by actually knowing where the bloody 
driver/settings, etc. might all be, so you can, I don't know.. manually 
edit settings, if you had to? :p So, yeah. It might be an HP problem, 
but its an HP problem that, if it was easy to fix, they had like 3-4 
years, since they started using this method to get the things to talk to 
each other, to actually put out a bug fix for, and haven't. Which, 
usually, means the OS is making assumptions that are keeping them from 
reliably fixing it.

Mind, I know this was a poor example. But, I also know that there are 
situations that *definitely* ended up being the OS in the way, entirely, 
not just some other companies buggy installer. And, again, when things 
do go wrong.. Its not like you can throw tests at it, from a command 
line, or from a basic script, or anything else you might do, to see what 
the frak is really going on. All the OS will tell you is, "This looks 
like its working, because the driver says so, I don't know why the fuck 
it crashes 1/3 of the way into a scan!", or the like. I would hardly 
call that "working"...

Post a reply to this message