On 05/11/2012 11:01 PM, johnmurphy...@safe-mail.net wrote: >> 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). >
That's odd. > How is that a kernel bug? > It's missing the UID entirely? On a connection where it _previously_ had the UID? That seems pretty weird to me... > How do I disable time wait? I'm not sure that there is a sysctl for it - I couldn't find one. > > BTW. totally off topic, but is there a full pic of your tattoo out in the net? Probably not. ;-) All the best, Jacob _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
