Closed
Bug 243986
Opened 20 years ago
Closed 7 years ago
SOCKS5: DNS error (hostname not found) -> proxy hostname not found error
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
mozilla53
Tracking | Status | |
---|---|---|
firefox53 | --- | fixed |
People
(Reporter: benc, Assigned: xeonchen)
References
()
Details
(Whiteboard: [proxy][necko-active])
Attachments
(1 file)
STEPS: Configure SOCKS5 w/ correct configuration. Click on link w/ incorrect/non-existent hostname. OBSERVED: The error message displayed is the error for a proxy w/ a bad hostname, not the actual connection. EXPECTED: The normal DNS error (under current SOCKS5 DNS behavior, see bug 134105). -or- correct SOCKS error handling (if that bug is ever fixed).
Comment 1•20 years ago
|
||
benc: Might it be that this bug here also applies to SOCKS4 (see Bug 276269)?
Updated•18 years ago
|
Assignee: darin → nobody
QA Contact: benc → networking
Updated•8 years ago
|
Whiteboard: [necko-backlog]
Assignee | ||
Updated•8 years ago
|
Whiteboard: [necko-backlog] → [proxy][necko-backlog]
Assignee | ||
Comment 2•7 years ago
|
||
I use OpenSSH tunneling to create a SOCKS5 server, and I can reproduce this bug. However, the the server closes the connection ([1]) if we send an invalid host name to resolve on server side, looks like OpenSSH doesn't handle this correctly: > debug1: channel 8: new [dynamic-tcpip] > debug2: channel 8: pre_dynamic: have 0 > debug2: channel 8: pre_dynamic: have 3 > debug2: channel 8: decode socks5 > debug2: channel 8: socks5 auth done > debug2: channel 8: pre_dynamic: need more > debug2: channel 8: pre_dynamic: have 0 > debug2: channel 8: pre_dynamic: have 28 > debug2: channel 8: decode socks5 > debug2: channel 8: socks5 post auth > debug2: channel 8: dynamic request: socks5 host nonexistent.mozilla.org port 443 command 1 > debug3: send packet: type 90 > debug3: receive packet: type 92 > channel 8: open failed: administratively prohibited: open failed > debug2: channel 8: zombie > debug2: channel 8: garbage collecting > debug1: channel 8: free: direct-tcpip: listening port 1080 for nonexistent.mozilla.org port 443, connect from ::1 port 60847 to ::1 port 1080, nchannels 9 In Sec. 6 "Replies" of RFC 1928, it is supposed to response an error code instead of closing directly. [1] https://dxr.mozilla.org/mozilla-central/rev/7083c0d30e75fc102c715887af9faec933e936f8/netwerk/socket/nsSOCKSIOLayer.cpp#1158
Assignee: nobody → xeonchen
Whiteboard: [proxy][necko-backlog] → [proxy][necko-active]
Comment hidden (mozreview-request) |
Assignee | ||
Comment 4•7 years ago
|
||
I've just tested this with TorSocks
Comment 5•7 years ago
|
||
mozreview-review |
Comment on attachment 8820642 [details] Bug 243986 - Handle SOCKS5 remote DNS resolution error; https://reviewboard.mozilla.org/r/100112/#review104112 ship it!
Attachment #8820642 -
Flags: review?(daniel) → review+
Assignee | ||
Updated•7 years ago
|
Keywords: checkin-needed
Pushed by ihsiao@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/10aef51fa9df Handle SOCKS5 remote DNS resolution error; r=bagder
Keywords: checkin-needed
Comment 7•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/10aef51fa9df
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox53:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
You need to log in
before you can comment on or make changes to this bug.
Description
•