[OTR-dev] Going forward

[Len Sassaman]

On Thu, 23 Dec 2004, Ralf-Philipp Weinmann wrote:

> I think I'd rather prefer the AIM proxy solution with an appropriate pf
> rdr rule (I think this is the same idea Len suggested).

There's three scenarios we're looking at. The first is to use a local
proxy on the client machine, and configure the iChat client to use that
proxy. iChat proxy support (SOCKS5 and HTTPS) works, *except* when the
client is on the local machine. (iChat speaks a completely different
protocol than gaim over HTTP proxies, and we haven't looked to closely at
that.)

Due to the iChat/local proxy bug, I suggested we do a system-wide network
shim for a passive proxy instead. This has the added benefit of not
requiring any user configuration of chat clients, and, once installed,
will work for any chat program on the client computer.

No luck. We were attempting to use ipfw fwd rules to direct outgoing
traffic destined for the Oscar port to a local proxy. The traffic never
makes it (though the rule is triggered.) I have a little more debugging to
do, but at this point I think it's pretty safe to conclude there's a bug
in the Darwin kernel with regard to this specific usage of ipfw fwd
rules.

The final option, assuming that the above are indeed bugs that are
unfixable outside of Apple, and won't be fixed in a timely fashion, is to
use the FreeBSD-style divert sockets (see divert (4)) supported in Darwin.
I am certain this works; however, this is considerably more difficult to
implement than the other two options, which *ought* to work anyway.

Both of the ipfw-based solutions should be easily portable to other
Unix-like OSes, so the work we'd put in on this could be useful for more
than just OS X, assuming we don't find more bugs in ipfw support on other
OSes.

For reference, I've filed two problem reports with Radar regarding the
iChat and Darwin bugs: #3930258 and #3930228.



--Len.