636088 - Blocked LSP: Microsoft Proxy Client / Microsoft Firewall Client Service Provider

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Sarat]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

I have configured the proxy using the Internet Settings of the system. All other browsers including Safari and Chrome is working fine with it. But in Firefox 4, I have to manually specify the proxy server in order to get things done.

Reproducible: Always

Steps to Reproduce:
N/A
Actual Results:  
Pages are not loading

Expected Results:  
Firefox must use the system proxy settings in order to load the page

Comment 1

[Matthias Versen [:Matti]]

You didn't provide enough information.
What are the proxy settings in IE: manual proxy, a pac file etc... ?

Comment 2

[Sarat]

Attachment: Blank Proxy Settings.

Comment 3

[Sarat]

(In reply to comment #1)
> You didn't provide enough information.
> What are the proxy settings in IE: manual proxy, a pac file etc... ?

Please see the attachment of proxy settings.

I'm accessing Internet by overriding the proxy settings using Microsoft Proxy Client. My settings for Firefox 4 is to use "System Proxy Settings". But when I select this option Firefox is unable to connect Internet.

I can also access Internet directly by Specifying Proxy settings. If I manually enter the proxy information, it works fine. But I'm using Proxy Client to override the default proxy restrictions and use my special permissions like GMail, Google Talk etc.

Please let me know if I need to provide more details.

Comment 4

[Matthias Versen [:Matti]]

Is it possible that the "Microsoft Proxy Client" is using an LSP ?
Please run the command "netsh winsock show catalog >C:\lsp.txt" in a cmd window (without the quotes) and attach the file c:\lsp.txt to this bug using the "add an attachment" link above.

Comment 5

[Sarat]

Attachment: Winsock Show Catalog

Comment 6

[Sarat]

Please find the attachment.

(In reply to comment #4)
> Is it possible that the "Microsoft Proxy Client" is using an LSP ?
> Please run the command "netsh winsock show catalog >C:\lsp.txt" in a cmd window
> (without the quotes) and attach the file c:\lsp.txt to this bug using the "add
> an attachment" link above.

Comment 7

[Matthias Versen [:Matti]]

They are using an LSP: "Microsoft Firewall Client Service Provider"
We block some LSPs with Gecko2.0, this LSP could be affected

Comment 8

[Sarat]

There are several companies are using the same proxy clients and this could negatively affect or forced to switch to other browsers like Google Chrome or Safari as it works perfect with them. Isn't it possible to revoke the restrictions?

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I think this is Microsoft's problem.  Their LSP should be categorizing itself appropriately (in fact, MS Firewall Client is one of the examples they use in the MSDN article about LSP categorization!)

I see that you're running Microsoft Firewall Client 2004.  Surely there's a newer version of this by now?  I'd imagine that a newer version would fix this.

Comment 10

[Sarat]

I'm not sure why this happens. All other browsers are working perfect in the system (Chrome and Safari)

-Sarat

(In reply to comment #9)
> I think this is Microsoft's problem.  Their LSP should be categorizing itself
> appropriately (in fact, MS Firewall Client is one of the examples they use in
> the MSDN article about LSP categorization!)
> 
> I see that you're running Microsoft Firewall Client 2004.  Surely there's a
> newer version of this by now?  I'd imagine that a newer version would fix this.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Because other browsers (to the best of my knowledge) don't set LSP categories on their executables.

Comment 12

[Ed Morley [:emorley]]

Edit: mid-air/beaten to it, but might as well post anyway I guess!

Sarat, a number of Firefox crashes are caused by buggy LSPs that are present on user's systems. Unfortunately all the user sees is Firefox crashing and has no idea it's actually caused by LSPs related to malware/badly written software, so blame Firefox. In bug 523410, all LSPs that do not declare themselves in the SYSTEM category were blocked intentionally in order to reduce the number of these crashes. The change only landed for Firefox 4, not the 3.x branches. 

LSPs that categorise themselves properly as SYSTEM, will not be affected. It sounds like your old version of the Firewall client does not do this; ie: doesn't even follows Microsoft's own MSDN advice page. This may have been fixed in a newer version of the Firewall client.

Chrome/Opera have not done anything like blocking LSPs (yet), which is why they still work for you. IE does do something similar, when in low-rights mode, so would also be affected in certain scenarios.

For more details on why the change was made in the first place, see bug 523410.

Comment 13

[Robert Strong (they/them - no direct email)]

Actually, IE doesn't do anything with LSP categories. What happens is that many LSP's aren't written to do the right thing (e.g. only access parts of the OS that are accessible in protected mode, etc.) when an app runs in protected mode and hence won't work with IE when it runs in protected mode.

Comment 14

[Robert Strong (they/them - no direct email)]

Kyle, using crashstats 20110105-pub-crashdata for all Firefox crashes (includes 3.6.x) I see a total of 1573 crashes with _PR_MD_SEND out of which there are only 46 with an os version of 6.0 and greater. It doesn't seem to be a problem worth trying to fix to me since we aren't seeing that many _PR_MD_SEND crashes with Vista and above on 3.6.x.

Comment 15

[Robert Strong (they/them - no direct email)]

Talked with jst about this and he asked me to nominate so drivers van evaluate this since there doesn't appear to be many crashes with Vista and above on 3.6.x even though we don't block LSP's on 3.6.x. See comment #14 for more detail from crash stats (would appreciate it if someone verified my findings). Bug 621320 and bug 630481 are both cases similar to this bug report.

iirc the way I implemented this will require a single line patch to remove our LSP categorization.

Comment 16

[Johnathan Nightingale [:johnath]]

Okay - drivers argue for the importance of letting this firewall work over the unclear benefit of the LSP blocking in terms of crash reduction.

Comment 17

[Johnathan Nightingale [:johnath]]

Rob - can we get a patch today for this so that we can move towards RC post-haste?

Comment 18

[Robert Strong (they/them - no direct email)]

Not a problem

Comment 19

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Comment 20

[Sarat]

(In reply to comment #19)
> Created attachment 515147 [details] [diff] [review]
> patch rev1

Hello,

Is it possible for me to test this patch? How can I do it?

Comment 21

[Robert Strong (they/them - no direct email)]

(In reply to comment #20)
> (In reply to comment #19)
> > Created attachment 515147 [details] [diff] [review]
> > patch rev1
> 
> Hello,
> 
> Is it possible for me to test this patch? How can I do it?
It would be easiest by using tomorrow's nightly build... I'll give you details on what to do after I land the patch

Comment 22

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/e180004e766e

Comment 23

[Sarat]

(In reply to comment #22)
> Pushed to mozilla-central
> http://hg.mozilla.org/mozilla-central/rev/e180004e766e

Thanks Robert. I shall check and update you on Monday morning (IST). I can test this only at my office as the proxy client is only available there.

Comment 24

[Robert Strong (they/them - no direct email)]

(In reply to comment #23)
> (In reply to comment #22)
> > Pushed to mozilla-central
> > http://hg.mozilla.org/mozilla-central/rev/e180004e766e
> 
> Thanks Robert. I shall check and update you on Monday morning (IST). I can test
> this only at my office as the proxy client is only available there.
No problem.

You reopened this bug which you probably did unintentionally. In the future, please be careful not to do this when commenting in bugs.

Comment 27

[ungershane14]

[Tracking Requested - why for this release]: