search for: ips_seen_reply

Displaying 3 results from an estimated 3 matches for "ips_seen_reply".

2003 Aug 02
0
[SECURITY] Netfilter Security Advisory: Conntrack list_del() DoS
...gt;status); conntrack->master =3D expected; expected->sibling =3D conntrack; LIST_DELETE(&ip_conntrack_expect_list, expected); @@ -768,11 +766,11 @@ *set_reply =3D 1; } else { /* Once we've had two way comms, always ESTABLISHED. */ - if (h->ctrack->status & IPS_SEEN_REPLY) { + if (test_bit(IPS_SEEN_REPLY_BIT, &h->ctrack->status)) { DEBUGP("ip_conntrack_in: normal packet for %p\n", h->ctrack); *ctinfo =3D IP_CT_ESTABLISHED; - } else if (h->ctrack->status & IPS_EXPECTED) { + } else if (test_bit(IPS_EXPECTED...
2003 Feb 26
0
[Bug 56] New: super-long erroneous timeouts in conntrack table (semantics of list_del() change)
...list_del() now zeros prev and next pointer of list_head, which circumvents is_confirmed() test. This didn't cause troubles to most conntrack entries which disappear by timing out. But as our cache was bypassing some of the connections, the machine was seeing only one way stream of packets (!IPS_SEEN_REPLY). And when the originating host terminates a bypassed connection by sending out RST packets, the corresponding entry is repeatedly removed from hash with death_by_tiemout() and soon confirmed again adding jiffies to expire time every time. Applying the following patch solved the problem. As I...
2014 May 28
2
[Bug 950] New: ct status
...*/ 75 .symbols = { 76 SYMBOL("expected", IPS_EXPECTED), 77 SYMBOL("seen-reply", IPS_SEEN_REPLY), 78 SYMBOL("assured", IPS_ASSURED), 79 SYMBOL("confirmed", IPS_CONFIRMED), 80 SYMBOL("snat", IPS_SRC_NAT), 81...