[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4865 [Tor Bridge]: managed obfsproxy cannot talk to tor on other than 127.0.0.1
#4865: managed obfsproxy cannot talk to tor on other than 127.0.0.1
------------------------+---------------------------------------------------
Reporter: wwaites | Owner: asn
Type: defect | Status: needs_revision
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Bridge | Version:
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Changes (by nickm):
* status: needs_review => needs_revision
Comment:
The fmt_addr and fmt_addr_decorate macros need to be documented. Also,
standard C best practices suggest enclosing macro arguments in
parenthesis, as in
{{{
#define fmt_addr(a) fmt_addr_iml((a), 0)
}}}
I think router_get_active_listener_port_by_type is probably a questionable
interface. It can't work predictably with multiple listeners, and it
can't help you if the address being listened on isn't the one you
expected. It looks like we're already making that mistake with
CFG_AUTO_PORT handling elsewhere, though, so maybe only an XXXX comment is
in order.
When iterating over configured_ports, you've got to skip the nolisten
ones, I think. Also, we could run into trouble if we call
"get_first_listener_addrport_for_pt" before the listeners are started. Is
this possible? Also, that function should check for failure from
router_get_active_listener_port_by_type.
"get_first_listener_addrport_for_pt" is not a great name; we generally
name functions based on what they do, not who uses them.
Other than that, it seems plausible.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4865#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs