> > echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
>
> not the right option; this is different, and to avoid an issue with time wait.
>
> the feature i'm thinking of is time-wait negotiation, which can be
> tweaked to always put this state on the peer (or fail if not
> available).
>
> last time i mess
> echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
not the right option; this is different, and to avoid an issue with time wait.
the feature i'm thinking of is time-wait negotiation, which can be
tweaked to always put this state on the peer (or fail if not
available).
last time i messed with this is wa
On Fri, May 11, 2012 at 8:01 PM, wrote:
> How do I disable time wait?
actually not straight forward. depending on kernel, first try:
echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
some other settings to aggressively prune lingering kernel states:
echo 2 > /proc/sys/net/ipv4/tcp_fin_timeout (or 1)
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 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
On 05/11/2012 11:09 PM, coderman wrote:
> On Fri, May 11, 2012 at 7:52 PM, Jacob Appelbaum wrote:
>> ...
>> If this is actually the case, I'd say that this is a kernel bug. :(
>
> some would call it a kernel "feature" to conserve memory space already
> wasted on TIME_WAIT. not everything is desi
On Fri, May 11, 2012 at 7:52 PM, Jacob Appelbaum wrote:
>...
> If this is actually the case, I'd say that this is a kernel bug. :(
some would call it a kernel "feature" to conserve memory space already
wasted on TIME_WAIT. not everything is designed around your
particular use case. (it is not un
> On 05/11/2012 07:43 PM, coderman wrote:
> > On Thu, May 10, 2012 at 8:52 PM, Marsh Ray 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 appl
On 05/11/2012 07:43 PM, coderman wrote:
> On Thu, May 10, 2012 at 8:52 PM, Marsh Ray 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.
On Thu, May 10, 2012 at 8:52 PM, Marsh Ray 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
> On Thu, May 10, 2012 at 10:11:06PM -0400, johnmurphy...@safe-mail.net wrote:
> > IN= OUT=eth0 SRC=192.168.178.50 DST=some-target LEN=40 TOS=0x00 PREC=0x00
> > TTL=64 ID=0 DF PROTO=TCP SPT=50447 DPT=443 WINDOW=1002 RES=0x00 ACK URGP=0
> >
> > This packet is https, most likely generated by my fir
On 05/10/2012 09:11 PM, johnmurphy...@safe-mail.net wrote:
Hi List,
I am trying to tweak my transparent netfilter setup (Tor Stable,
Debian Wheezy, GNU/Linux, iptables v1.4.12.2, Kernel 3.2.0-amd64). So
far, redirection and torification works fine. I have have several
users, some of them have th
On Thu, May 10, 2012 at 10:11:06PM -0400, johnmurphy...@safe-mail.net wrote:
> IN= OUT=eth0 SRC=192.168.178.50 DST=some-target LEN=40 TOS=0x00 PREC=0x00
> TTL=64 ID=0 DF PROTO=TCP SPT=50447 DPT=443 WINDOW=1002 RES=0x00 ACK URGP=0
>
> This packet is https, most likely generated by my firefox user
Hi List,
I am trying to tweak my transparent netfilter setup (Tor Stable, Debian Wheezy,
GNU/Linux, iptables v1.4.12.2, Kernel 3.2.0-amd64). So far, redirection and
torification works fine. I have have several users, some of them have their TCP
traffic forwarded to Tor, some are allowed to send
13 matches
Mail list logo
