Plug-ins fail with FG_ERR_SOCKSCONN

[robgjansen]

Currently using this plug-in seems to fail with FG_ERR_SOCKSCONN.

[robgjansen]

This may be a problem in Tor, as the P2P plug-in and the filetransfer plug-in may be experiencing something similar.

See here for the Tor ticket:
https://trac.torproject.org/projects/tor/ticket/6341#comment:33

[caffeineshock]

It's currently failing at least half the time. But I think this may have something to do with the fact that the browser plug-in doesn't really use the filegetter service interface. That interface retries a connection that failed with FG_ERR_SOCKSCONN. I guess this is needed because we can't really be sure when the Tor network is ready to be used. This should therefore be done in the browser plug-in too. Then it should fail less and it should be easier to approach the problem @robgjansen described.

[robgjansen]

That merge doesn't really solve the underlying problems, but handles it more gracefully. Since I suspect there is a problem somewhere in Tor of elsewhere, I'm closing this issue for now.

[robgjansen]

I believe the biggest source of these errors was fixed in e2d30c9. Please report if you are still seeing high error rates after the patch.

[caffeineshock]

It still fails with that error in 50% of all cases.

[robgjansen]

@caffeineshock

1. Does it fail with that error when not downloading through Scallion/Tor?
2. Whats the smallest experiment setup where I can reproduce the problem?

I'll have to look through some log files to understand what is causing the problem.

[caffeineshock]

@robgjansen It doesn't fail when not using Scallion. But I haven't used SOCKS connections in that case. Can I do that without scallion? I test the browser plug-in with scallion by creating a directory like resource/scallion-browser-example and the following XML-file inside:

<plugin id="scallion" path="libshadow-plugin-scallion.so" />
<plugin id="filex" path="libshadow-plugin-filetransfer.so" />
<plugin id="browser" path="libshadow-plugin-browser.so" />

<cluster id="browser" bandwidthdown="6000" bandwidthup="1000" />
<cluster id="server" bandwidthdown="100000" bandwidthup="100000" />
<link id="link-browser-browser" clusters="browser browser" latency="30" jitter="11" packetloss="0.0">
<link id="link-server-browser" clusters="server browser" latency="50" jitter="11" packetloss="0.0" />
<link id="link-browser-server" clusters="browser server" latency="50" jitter="11" packetloss="0.0" />

<software id="authority" plugin="scallion" time="1" arguments="dirauth 102400 1024000 1024000 ./authority.torrc ./data/authoritydata ~/.shadow/share/geoip" />
<node id="4uthority" software="authority" cluster="browser" bandwidthup="102400" bandwidthdown="102400" cpufrequency="2800000" quantity="1" />

<software id="exit" plugin="scallion" time="300" arguments="exitrelay 1024 102400 102400 ./exit.torrc ./data/exitdata ~/.shadow/share/geoip" />
<node id="exit.tor" cluster="browser" software="exit" cpufrequency="2800000" quantity="1" />

<software id="relay" plugin="scallion" time="300" arguments="relay 1024 102400 102400 ./relay.torrc ./data/relaydata ~/.shadow/share/geoip" />
<node id="relay.tor" cluster="browser" software="relay" cpufrequency="2800000" quantity="2" />

<!-- Servers -->

<software id="server" plugin="filex" time="1" arguments="server 80 ../browser-example/" />
<node id="server.node" software="server" cluster="server" bandwidthdown="60000" bandwidthup="30000" cpufrequency="2800000" />

<!-- Browser -->
<software id="client" plugin="scallion" time="3000" arguments="browser 1024 102400 102400 ./client.torrc ./data/clientdata ~/.shadow/share/geoip server.node 80 localhost 9000 6 /index.htm" />
<node id="client.tor" cluster="browser" software="client" cpufrequency="2800000" logpcap="true" quantity="1" />

<kill time="10000" />

Then I execute the it from that directory through scallion -y -i <name>.xml

[robgjansen]

It doesn't fail when not using Scallion. But I haven't used SOCKS connections in that case. Can I do that without scallion?

Not currently, because we don't have another SOCKS proxy plug-in implemented.

I test the browser plug-in [...]

Thanks! I'll check it out.

[robgjansen]

The following prints to stderr:

fileserver fatal error: file io error
filegetter fatal error: server closed

And I found the following in data/scallion.log:

0:0:14:094798 [thread-0] 1:0:2:130362858 [scallion-critical] [client.tor-60.1.0.0] [browser_activate] filegetter shutdown due to error 'FG_ERR_FATAL' for server.node -> /
[Invalid UTF-8] 0:0:14:104274 [thread-0] 1:0:2:395590758 [scallion-message] [client.tor-60.1.0.0] [browser_activate] Error 404: server.node -> /@\xf0\x98\xfc\xff\x7f

Your browser_activate() is calling filegetter_activate() while filegetter is in the FG_REQUEST_HTTP state. Then the following is getting called with fg->fspec.remote_path='/'.

gint bytes = snprintf(fg->buf + fg->buf_write_offset, (size_t) space, FT_HTTP_GET_FMT, fg->fspec.remote_path, fg->sspec.http_hostname);

So, the browser sent a request for the file /, and the server tries to load docroot// and errors out.

@caffeineshock Any idea why your remote path is / while calling filegetter_activate()?

[caffeineshock]

@robgjansen That's a weird error. Does this happen all the time with the XML above? I'm currently working a lot with the same configuration to try out my changes to Tor and I've never got that.

It seems to happen after the first document was downloaded. You could try turning on debug messages. Then the paths of embedded object are printed after parsing with libtidy. The output of grep browser_get_embedded_objects data/scallion.log should be like the following:

0:0:26:646277 [thread-0] 1:0:1:794649205 [scallion-debug] [client.tor-60.1.0.0] [browser_get_embedded_objects] server.node -> /example_1.css
0:0:26:663058 [thread-0] 1:0:1:794649205 [scallion-debug] [client.tor-60.1.0.0] [browser_get_embedded_objects] server.node -> /example_2.css
0:0:26:663105 [thread-0] 1:0:1:794649205 [scallion-debug] [client.tor-60.1.0.0] [browser_get_embedded_objects] server.node -> /example.js
0:0:26:663138 [thread-0] 1:0:1:794649205 [scallion-debug] [client.tor-60.1.0.0] [browser_get_embedded_objects] server.node -> /example.gif

[robgjansen]

That gives me:

0:0:26:319500 [thread-0] 1:3:2:100288982 [scallion-debug] [client.tor-60.1.0.0] [browser_get_embedded_objects] server.node -> /
[Invalid UTF-8] 0:0:26:319513 [thread-0] 1:3:2:100288982 [scallion-debug] [client.tor-60.1.0.0] [browser_get_embedded_objects] server.node -> /\xf0\x18\xda\xb6\xff\x7f

[caffeineshock]

1. What happens if you just run shadow --browser --log-level=debug | grep browser_get_embedded_objects (The XML file above is only a simple scallion-version of that example)
2. Have you checked whether the HTML document is unmodified (git diff HEAD resource/browser-example/index.htm) and/or contains those crazy paths?
3. What is your version of libtidy? Mine is 0.99-0 (20091223cvs-1ubuntu2)

[robgjansen]

What happens if you just run shadow --browser --log-level=debug | grep browser_get_embedded_objects (The XML file above is only a simple scallion-version of that example)

You must run that from the shadow base directory, because the server serves ./resource/browser-example. That wasn't immediately obvious. Then I get this:

0:0:0:009427 [thread-0] 0:0:20:179012589 [browser-debug] [browser.node-6.0.0.0] [browser_get_embedded_objects] server.node -> /
[Invalid UTF-8] 0:0:0:009442 [thread-0] 0:0:20:179012589 [browser-debug] [browser.node-6.0.0.0] [browser_get_embedded_objects] server.node -> /P\x0cA\xe1\xff\x7f
0:0:0:009460 [thread-0] 0:0:20:179012589 [browser-debug] [browser.node-6.0.0.0] [browser_get_embedded_objects] server.node -> /example_1.css
0:0:0:009532 [thread-0] 0:0:20:179012589 [browser-debug] [browser.node-6.0.0.0] [browser_get_embedded_objects] server.node -> /example_2.css
0:0:0:009542 [thread-0] 0:0:20:179012589 [browser-debug] [browser.node-6.0.0.0] [browser_get_embedded_objects] server.node -> /example.js
0:0:0:009558 [thread-0] 0:0:20:179012589 [browser-debug] [browser.node-6.0.0.0] [browser_get_embedded_objects] server.node -> /example.gif
fileserver fatal error: file io error
filegetter fatal error: server closed

(I wish the built-in example didn't need any paths, i.e., read static webpages and objects that are defined in the code rather than reading a file.)

Have you checked whether the HTML document is unmodified (git diff HEAD resource/browser-example/index.htm) and/or contains those crazy paths?

Yep. It looks like this:

<html>
  <head>
    <link rel="stylesheet" media="screen" href="example_1.css" />
    <link rel="stylesheet" media="screen" href="//server.node/example_2.css" />
    <style type="text/css">
      /* Is ignored */
      @import url("example_3.css");
    </style>
    <script type="text/javascript" src="/example.js"></script>
  </head>
  <body>
    <img src="http://server.node/example.gif" />
  </body>
</html>

What is your version of libtidy? Mine is 0.99-0 (20091223cvs-1ubuntu2)

[rob@thor shadow]$ yum info libtidy-devel libtidy
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Installed Packages
Name        : libtidy
Arch        : x86_64
Version     : 0.99.0
Release     : 22.20091203.fc17
Size        : 385 k
Repo        : installed
From repo   : fedora
Summary     : Shared libraries for tidy
URL         : http://tidy.sourceforge.net/
License     : W3C
Description : Shared libraries for tidy.

Name        : libtidy-devel
Arch        : x86_64
Version     : 0.99.0
Release     : 22.20091203.fc17
Size        : 1.0 M
Repo        : installed
From repo   : fedora
Summary     : Development files for tidy
URL         : http://tidy.sourceforge.net/
License     : W3C
Description : Development files for tidy.

[caffeineshock]

I'm very clueless as to what is causing this ... As far as I remember you tested shadow --browser. But I switched from libxml2 to libtidy after adding that example. So maybe it hasn't been working for your setup since then. Maybe it has to do with handling of encodings (at least this looks very sloppy implemented by me). I will have a look at it, but I won't be able to in time with the release date of 1.6.0. If you want to debug it you might want to have a look at shd-html.c which handles the HTML parsing.

[robgjansen]

The errors:

fileserver fatal error: file io error
filegetter fatal error: server closed

are because the function html_find_objects tests the url variable for NULL when it never gets initialized.