George, Thanks for the info!
This should approximate your suggestion: https://github.com/david415/obfsproxy/tree/david-bananaphone-managed Let me know your suggestions for improvement. Either way I'll work on this more soon. Onward! David On Sun, Nov 10, 2013 at 3:21 AM, George Kadianakis <[email protected]> wrote: > David Stainton <[email protected]> writes: > >> Hi, >> >> Yeah... I should add a doc string to the BaseTransport __init__ >> explaining that it runs upon connect. >> >> OK yesterday I implemented transport class method called setup()... >> The BananaphoneTransport overrides setup()... storing the markov model >> in a class attribute. >> I had to modify pyobfsproxy.py and run the class setup() method after >> the external cli args are parsed. >> >> I made it work for external cli mode... by making pyobfsproxy.py run >> the setup method for each transport after >> args.validation_function(args) runs... because the setup method needs >> some args to read the corpus file and build the markov model. >> >> What should I do to get arguments passed to obfsproxy when running in >> managed mode? >> > > Hm. Good question. > > You probably want to go to obfsproxy/managed/server.py and > obfsproxy/managed/client.py and place a strategic > run_transport_setup() hook. I would place it before the > launch_transport_listener() call. You might also need to use > obfsproxy/transports/get_transport_class() somewhere in there. > > Another nice thing would be if you could pass the pt_config struct in > setup(), so that transports can use pt_config elements during > initialization. As an example, see how obfs2 configures its > shared-secret in its __init__ using getServerTransportOptions(). That > could be done in its setup(), I think. > > Does this make sense? If you don't want to do this coding, I can do it > at some point next week. > > Cheers! > > ( > And while I'm on it, let me tell you about the different ways that you > can pass parameters to obfsproxy. I wanted to document this somewhere, > and this thread seems like a good excuse :) > > - External mode: > You can pass global parameters to external mode transports by using > the register_external_mode_cli() and validate_external_mode_cli() > functions. > > - Managed mode: > - Global parameters: > These are parameters that are passed to obfsproxy on startup. > > - Server: > On the server-side we can pass global parameters to obfsproxy by > using the TOR_PT_SERVER_TRANSPORT_OPTIONS environment > variable. Obfsproxy exposes those parameters using the > transport_config struct and > obfsproxy/common/transport_config.py:getServerTransportOptions . > - Client: > On the client-side we don't have a way to pass global parameters > to obfsproxy yet. If we ever need to, we can do it with > environment variables here too. > > - Per-connection parameters: > These are parameters which are supposed to be different for each > connection. An example of such a parameter can be a shared-secret > used for a specific bridge connection. > > - Server: > On the server-side we don't have a way to pass per-connection > parameters at the moment. > - Client: > On the client-side we pass per-connection parameters using the > SOCKS handshake as a covert channel. Transports can retrieve these > parameters using the handle_socks_args() method. > ) _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
