Closed Bug 50679 Opened 24 years ago Closed 23 years ago

Prefs -> change SOCKS to "SOCKS v5"

Categories

(Core :: Networking, defect, P4)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: sihde, Assigned: jelwell)

References

Details

(Keywords: testcase)

Attachments

(2 files)

patch.
2.89 KB, patch
Details | Diff | Splinter Review
new patch with blake's suggested changes.
1.40 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14 i686)
BuildID:    2000082015

I am behind a Socks 4 firewall.  If I set the "Socks proxy" to my Socks 4 server
(which works fine with Netscape Communicator, rtelnet, etc.), Mozilla can't
connect to sites outside the firewall.  The status bar reports, "Document: Done
(xxx secs)" and the page is completely blank.

Reproducible: Always
Steps to Reproduce:
Open the Preferences dialog, expand the "Advanced" tab, select "Proxies", select
"Manual proxy configuration", enter socks 4 server address in "SOCKS Host",
enter "1080" for port.  Click "OK".  Type a URL that is accessible only via the
Socks server.

Actual Results:  A blank page is displayed and Mozilla reports "Document: Done".

Expected Results:  The requested page should be displayed.			

Using tcpdump reveals that Mozilla is not trying to connect to the socks server
at all, but rather to connect directly:

10:44:15.394580 maguro.almaden.ibm.com.1983 > www2.Stanford.EDU.www: S
3310948038:3310948038(0) win 32120 <mss 1460,sackOK,timestamp 517514263[|tcp]>
(DF)
10:44:18.392885 maguro.almaden.ibm.com.1983 > www2.Stanford.EDU.www: S
3310948038:3310948038(0) win 32120 <mss 1460,sackOK,timestamp 517514563[|tcp]>
(DF)
10:44:18.393770 cisco.almaden.ibm.com > maguro.almaden.ibm.com: icmp: host
www2.Stanford.EDU unreachable - admin prohibited filter

Mozilla reports on the terminal:

Entry at index 0 is http://www.stanford.edu/
Document: Done (3.066 secs)
Error loading URL http://www.stanford.edu/ 

Sites inside the firewall work OK; after all, Mozilla is contacting them
directly.

Quitting and restarting Mozilla doesn't help, and the proxy config settings in
~/.mozilla/default/prefs.js look ok.
Just some info:
Steven Ihde, are you still seeing this in current builds?
I just tested build 2000110108 on Linux.  It does now connect to the Socks
server instead of directly to the site, but it seems to support only Socks5, not
Socks4.  With the Socks4 server at my site this resulted in Mozilla hanging for
a long time.  (I set up a Socks5 server and pointed Mozilla at that and it did
work!) From looking at bug 16103 it appears there are no plans to support Socks4
-- is this correct?  I believe Socks4 is still much more common.  This will
undoubtedly cause a lot of confusion and more bug reports -- perhaps the
configuration dialog should be changed to say "SOCKS5 Host" instead of "SOCKS
Host".
Changed name and verified. This seems like a simple thing to do and will cut
down on our incoming bugs. View Steven's comments for possible quick change that
will save us a lot of headache down the line.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla can't use a Socks proxy → Change SOCKS configuration text
Blocks: 61691
Bad error in UI description. Low effort, low risk, high return -> mozilla0.9.
Keywords: mozilla0.9
OS: Linux → All
Hardware: PC → All
Is it time to declare the end to SOCKS V4?

Here's my best case for doing so:

1- Communicator never supported SOCKS V5 (to my knowledge)
2- SOCKS V4 is not specified in an RFC.
3- SOCKS V5 is reverse compatible for SOCKS V4. To add SOCKS V4 support, someone
has to go back to the Communicator code or start fresh.
4- Most "SOCKS servers" seem to support SOCKS V4 and V5. (I will research this
further).
5- Ideally, we need to clean up our story with networking protocols and clearly
indicate what we are going to support and what we are going to leave behind. We
also need to focus on implementing highly used protocols first.
Target Milestone: --- → Future
changed summary
URL: http://www.stanford.edu/ or any other
Summary: Change SOCKS configuration text → Prefs -> change SOCKS to "SOCKS V5"
These problems have affected my usage of the product and need to be fixed as a
Netscape priority.
Keywords: nsbeta1, nsdogfood
Benjamin, how did this prevent you from doing any work?  This is not dogfood. 
I'm converting it to catfood because most of the users who understand socks at
all will be affected by this.  Gagan, any chance of a quick fix?  Could we move
this bug to someone who can help since it's only a UI change?
Keywords: nsdogfood → nsCatFood
I think this was a dogfood2 (pre-catfood) nomination. 

nscatfood sounds good.

There is no quick socks4 implementation if thats what you are asking for! Yes at 
this stage fixing the UI to correctly reflect that we only can handle socks5 
seems to be the right thing to do. over to ben
Assignee: gagan → ben
nav triage team:

Sounds easy enough, marking nsbeta1+ and adding relnote keyword
Keywords: nsbeta1 → nsbeta1+, relnote
Priority: P3 → P4
helping to reduce ben's nsbeta1+ and nsbeta1 bugs.
Assignee: ben → jelwell
moving the milestone to where it belongs, in the milestone field.
Keywords: mozilla0.9
Target Milestone: Future → mozilla0.9.1
Since Communicator had preferences for SOCKS V4, and we now support SOCKS V5,
shouldn't this pref change also change the value in prefs.js?

There seem to be two ways to implement this:

Migrate the curent user_pref "network.proxy.socks" into two values:

user_pref "network.proxy.socks4"
user_pref "network.proxy.socks5"

-OR-

Create a new pref just for SOCKS V5 (and leave the old one implicit for V4)

user_pref "network.proxy.socks5"

By writing SOCKS V5 prefs into the existing entry from Communicator, we go deaf
to the SOCKS server if it doesn't support both versions. (the original problem
here). Unless someone wants to EOL SOCKS V4, I think we should leave some legacy
value behind, someday we might support that value again.

Based on this decision, I can write a test case and post it here.
QA Contact: tever → benc
Attached patch patch. — — Splinter Review 

    
    

    
  
Need reviews. I don't know if I am supposed to touch the l10n directories...

Ben: can you split the desire to change split the pref into socks4/5 into a new bug?
Status: NEW → ASSIGNED

    
    

    
  
Joe, Bug 78119 was sent to prefs-back end.


    
    

    
  
Use a lowercase v (and no need to make the l10n changes) and r=blake.
Summary: Prefs -> change SOCKS to "SOCKS V5" → Prefs -> change SOCKS to "SOCKS v5"

    
    

    
  
The capital "V" is the the proper spelling from what I gather on the NEC site.

Personally, I do not care, we already do this wrong in the AIM and the NIM
modules ("SOCKS 4" "SOCKS 5").

http://www.socks.nec.com/socksfaq.html

    
    

    
  
NEC's site is at least inconsistent (it uses both in alternation).  However, I 
suspect there's a rhyme and reason to it...

    
    

    
  
OK, time to get this sr= and checked in or admit we don't really care...

    
    

    
  
it's marketings call. I'm just trying to put the info on the table...

    
    

    
  
To clarify, the caps I don't care.

Fixing the version info, I do care.

We really have to check this in because there are two standards (V4 and V5) and
they do not interoperate. This isn't like HTTP 0.9, 1.0, and 1.1 working
seamlessly. Frankly, this protocol was poorly designed and we need to live with it.

When we released Communicator 4 (V4) and Netscape Proxy Server (V5) they could
not communicate with each other. I got an earful from Sony, Citibank and the
like. Does someone in eClient care that can sr=?

http://www.packetgram.com/pktg/proxy/socksversion.html



    
    

    
  
sr=hewitt

    
    

    
  
r=timeless

    
    

    
  
nav triage: this would have been nice to have, but its not a netscape beta 
stopper at this point. moving to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2

    
    

    
  
I'm really confused here.  Vishy, this bug has nsbeta1+, it was targeted at
0.9.1 and it has a patch with review and super review.  This is a minimal risk,
1 line, wording (exempt from super review) fix that goes to standards compliance
and accuracy of information.  There is no such thing as SOCKS (that's like
saying use MAIL instead of use IMAP mail) and leaving it like this is lying to
the user.  

    
    

    
  
checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
verified win2k 2001061905

Status: RESOLVED → VERIFIED

    
    

    
  
I need to check all plats...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Sure.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
cleared old keywords, + testcase (visual check of Prefs dialog in functional test)

VERIFIED:
Mozilla 0.9.2 all plats.

Keywords: nsbeta1+, 
          
            nsCatFood, 
          
            relnote → testcase

    
    

    
  
.
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: