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. All the best, Jacob _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
