Opened 12 years ago

Last modified 12 years ago

#375 closed defect (Not a bug)

MapAddress does not _appear_ to work in 1.2.6

Reported by: DarkMagess Owned by:
Priority: Low Milestone:
Component: Tor - Tor Control Panel Version: 0.1.2.5-alpha
Severity: Keywords:
Cc: DarkMagess Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It's possible that it does work, but it looks like it doesn't. I added the same mapaddress command to 1.2.6 as I

have in 1.1.26, and when I watch the network map pane to see how it's connecting, rather than connect to the
.onion address I'm giving it, it shows it trying to 10.40.40.40 which is the address I'm trying to map the
.onion address to so I can connect through Tor to Freenode. Since the pane isn't showing me the onion address
like it does in the old version, I thought this could mean that it wasn't working. And that would explain why
1.2.6 never lets me get through to IRC.

[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]

Child Tickets

Change History (5)

comment:1 Changed 12 years ago by nickm

MapAddress seems to work for me; it may be simply that what we're telling the controller
has changed. I'm going to poke around a little more, but chances are this is an issue
in how Vidalia is using Tor's interfaces, or in how we're reporting connections to hidden
services on the controller. In both 0.1.2.6-alpha-dev and 0.1.1.26, when I add
"MapAddress 10.1.1.1 www.mit.edu", and connect to 10.1.1.1, I see:

650 STREAM 1 NEW 0 10.1.1.1:80
650 STREAM 1 SENTCONNECT 2 www.mit.edu:80
650 STREAM 1 SUCCEEDED 2 www.mit.edu:80
650 STREAM 1 CLOSED 2 www.mit.edu:80

(But I haven't tried it for hidden services yet)

comment:2 Changed 12 years ago by nickm

I just tried a hidden service with 0.1.2.6-alpha-dev, and got:

650 STREAM 1 NEW 0 10.2.2.2:80
650 STREAM 2 SENTCONNECT 1 18.244.0.188:9031
650 STREAM 2 SUCCEEDED 1 18.244.0.188:9031
650 STREAM 2 CLOSED 1 18.244.0.188:9031
650 STREAM 1 SENTCONNECT 3 6sxoyfb3h2nvok2d.onion:80
650 STREAM 1 SUCCEEDED 3 6sxoyfb3h2nvok2d.onion:80
650 STREAM 1 CLOSED 3 6sxoyfb3h2nvok2d.onion:80

This is about what I'd expect, though I'm not sure whether having NEW report the nominal address
is a bug or a feature.

comment:3 Changed 12 years ago by nickm

13:03 < armadev> re 375, i think reporting the address that's given to tor is

the right plan. consider temporary remaps, e.g. client-side
dns cache.

13:03 < armadev> perhaps a stream event 'remapped' if you want to get detailed
13:03 < armadev> then vidalia could silently replace it in its screen
13:03 < nickm> So if there's a problem, it's on vidalia's side?
13:04 < nickm> armadev: That is, if there's a problem, it's that vidalia is

displaying the "NEW" address.

13:04 < nickm> armadev: agreed?

comment:4 Changed 12 years ago by nickm

So my working theory is this: for hidden service connections that take a long time to
connect, the delay between "NEW" (which has the given address) and "SENTCONNECT" (which
has the mapped address) can be quite high, and the controller will report the provided
address for a long time.

I've added a 'REMAP' stream status event in r9484; this may enable Vidalia to improve
matters here. I'm going to make an entry on the vidalia tracker if I can connect to it,
where this should stay until:

  • we find out that there was a real Tor bug happening here
  • we confirm that the controller accepts and handles REMAP statuses.

comment:5 Changed 12 years ago by nickm

flyspray2trac: bug closed.
Marking as "not a bug" unless more data can be found; see comments.

Note: See TracTickets for help on using tickets.