> On 05/11/2012 07:43 PM, coderman wrote: > > On Thu, May 10, 2012 at 8:52 PM, Marsh Ray <ma...@extendedsubset.com> wrote: > >> ... > >>> How is it possible for a packet not to have an associated uid? > >> ... > >> I'm not a netfilter expert, but it looks this is a pure TCP ACK packet. > >> With > >> LEN=40 there's no application data in it. It may have been auto-generated > >> by > >> the kernel as a reply to the external packet and never tagged with a user > >> for that reason. > > > > if the application closes a socket there are time wait states that > > retain the socket ip:port endpoint in kernel land without an > > associated application user ID. > > > > try disabling time wait to confirm. if it is indeed sockets locally > > closed but still receiving (and ACK'ing) you may get a little extra > > bandwidth dropping them (remote re-sends until timeout) but it > > shouldn't affect functionality. > > If this is actually the case, I'd say that this is a kernel bug. :( > > The best bet is probably to ensure that _all_ packets, regardless of UID > are sent over Tor and only specific UID's are _excepted_ from the policy.
Jacob, this is exactly what I am doing. (Route every tcp traffic through tor except for one firefox user). How is that a kernel bug? How do I disable time wait? BTW. totally off topic, but is there a full pic of your tattoo out in the net? _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
