* POSSIBLE BUG: netfilter/ip_conntrack_core
@ 2004-02-16 14:59 Peter Grace
2004-02-16 15:12 ` Patrick McHardy
2004-02-17 14:04 ` Harald Welte
0 siblings, 2 replies; 6+ messages in thread
From: Peter Grace @ 2004-02-16 14:59 UTC (permalink / raw)
To: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
~ I'm posting to the list blindly this following report:
LIST_DELETE: net/ipv4/netfilter/ip_conntrack_core.c:295
&ct->tuplehash[IP_CT_DIR_REPLY] (c40bf384) not in &ip_conntrack_hash[hr]
I believe the memory addresses are not as pertinent as the message
itself, but the screen filled up with 4-5 of these lines before finally
biting the dust.
Can someone shoot me an e-mail in reply to let me know if this is a bug
in netfilter code or if I'm just somehow confusing the heck out of the
nat filter? I've got a set of nat forwarding rules that forwards an ip
address onto the internal lan, and then from there I'm only allowing
certain packets to go through -- that seems to have exacerbated the
problem..
Thanks in advance!
Pete
- --
- ---
/------------------------------------------------\
|Peter Grace Phone: 484-875-9462
|Technology Analyst Fax: 484-875-9461
|RealTime Technologies, Inc. Cell: 484-919-1400
|835 Springdale Drive, Suite 101
|Exton, PA 19341
\------------------------------------------------/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAMNrc1bytwQSw7hoRAlAdAKDRNDHBduc9hohuYZDiq05u3HFsLACgzFUA
Vkee3U/KD1+wrWRWBohbWCM=
=j2ZU
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: POSSIBLE BUG: netfilter/ip_conntrack_core
2004-02-16 14:59 POSSIBLE BUG: netfilter/ip_conntrack_core Peter Grace
@ 2004-02-16 15:12 ` Patrick McHardy
2004-02-16 15:25 ` Peter Grace
2004-02-17 14:04 ` Harald Welte
1 sibling, 1 reply; 6+ messages in thread
From: Patrick McHardy @ 2004-02-16 15:12 UTC (permalink / raw)
To: Peter Grace; +Cc: Netfilter Development Mailinglist
Peter Grace wrote:
> Hello,
> ~ I'm posting to the list blindly this following report:
Moved from linux-kernel to netfilter-devel ..
>
> LIST_DELETE: net/ipv4/netfilter/ip_conntrack_core.c:295
> &ct->tuplehash[IP_CT_DIR_REPLY] (c40bf384) not in &ip_conntrack_hash[hr]
>
> I believe the memory addresses are not as pertinent as the message
> itself, but the screen filled up with 4-5 of these lines before finally
> biting the dust.
>
> Can someone shoot me an e-mail in reply to let me know if this is a bug
> in netfilter code or if I'm just somehow confusing the heck out of the
> nat filter? I've got a set of nat forwarding rules that forwards an ip
> address onto the internal lan, and then from there I'm only allowing
> certain packets to go through -- that seems to have exacerbated the
> problem..
Please post your ruleset, your kernel version and other relevent
information, this should not happen.
Regards
Patrick
>
> Thanks in advance!
>
> Pete
>
> --
> ---
> /------------------------------------------------\
> |Peter Grace Phone: 484-875-9462
> |Technology Analyst Fax: 484-875-9461
> |RealTime Technologies, Inc. Cell: 484-919-1400
> |835 Springdale Drive, Suite 101
> |Exton, PA 19341
> \------------------------------------------------/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: POSSIBLE BUG: netfilter/ip_conntrack_core
2004-02-16 15:12 ` Patrick McHardy
@ 2004-02-16 15:25 ` Peter Grace
0 siblings, 0 replies; 6+ messages in thread
From: Peter Grace @ 2004-02-16 15:25 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks for the prompt reply!
To netfilter gurus:
I'm running kernel 2.6.1 with debian unstable (currently utilizing gcc
3-3-3 and libc6 2.3.2-ds1-11).
The problem seems to be happening whenever I try to telnet to one of our
systems through the firewall.
In this case, the ip address is 67.105.178.145 which forwards to
10.0.0.5 is causing the odd message following:
LIST_DELETE: net/ipv4/netfilter/ip_conntrack_core.c:295
&ct->tuplehash[IP_CT_DIR_REPLY] (c40bf384) not in &ip_conntrack_hash[hr]
iptables-save output follows (some ip addresses changed to protect
the innocent):
# Generated by iptables-save v1.2.9 on Mon Feb 16 09:48:47 2004
*nat
:PREROUTING ACCEPT [6317:528203]
:POSTROUTING ACCEPT [519:45824]
:OUTPUT ACCEPT [0:0]
- -A PREROUTING -d 67.105.178.144 -j DNAT --to-destination 10.0.0.4
- -A PREROUTING -d 67.105.178.145 -j DNAT --to-destination 10.0.0.5
- -A PREROUTING -d 67.105.178.140 -p tcp -m tcp --dport 110 -j DNAT
- --to-destination 10.0.0.9:110
- -A PREROUTING -d 67.105.178.140 -p tcp -m tcp --dport 995 -j DNAT
- --to-destination 10.0.0.9:995
- -A PREROUTING -d 67.105.178.140 -p tcp -m tcp --dport 143 -j DNAT
- --to-destination 10.0.0.9:143
- -A PREROUTING -d 67.105.178.140 -p tcp -m tcp --dport 993 -j DNAT
- --to-destination 10.0.0.9:993
- -A POSTROUTING -s 10.0.0.4 -d ! 10.0.0.0/255.255.0.0 -j SNAT --to-source
67.105.178.144
- -A POSTROUTING -s 10.0.0.5 -d ! 10.0.0.0/255.255.0.0 -j SNAT --to-source
67.105.178.145
- -A POSTROUTING -s 10.0.0.0/255.255.0.0 -d ! 10.0.0.0/255.255.0.0 -j SNAT
- --to-source 67.105.178.130
COMMIT
# Completed on Mon Feb 16 09:48:47 2004
# Generated by iptables-save v1.2.9 on Mon Feb 16 09:48:47 2004
*mangle
:PREROUTING ACCEPT [50601:25640371]
:INPUT ACCEPT [18633:7025727]
:FORWARD ACCEPT [29086:18125877]
:OUTPUT ACCEPT [17826:1566349]
:POSTROUTING ACCEPT [46912:19692226]
COMMIT
# Completed on Mon Feb 16 09:48:47 2004
# Generated by iptables-save v1.2.9 on Mon Feb 16 09:48:47 2004
*filter
:INPUT ACCEPT [3324:459318]
:FORWARD ACCEPT [1207:70244]
:OUTPUT ACCEPT [2371:282116]
- -A INPUT -s 10.0.0.0/255.255.255.0 -d 10.0.0.6 -j ACCEPT
- -A INPUT -m state --state INVALID -j DROP
- -A INPUT -m state --state INVALID -j ULOG
- -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A INPUT -s X.X.X.X -d 67.105.178.130 -p tcp -m tcp --dport 22 -j ACCEPT
- -A INPUT -s X.X.X.X -d 67.105.178.130 -p tcp -m tcp --dport 22 -j ACCEPT
- -A INPUT -s X.X.X.X -d 67.105.178.130 -p tcp -m tcp --dport 22 -j ACCEPT
- -A INPUT -s X.X.X.X -d 67.105.178.130 -p tcp -m tcp --dport 22 -j ACCEPT
- -A INPUT -s X.X.X.X -d 67.105.178.130 -p tcp -m tcp --dport 22 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p udp -m udp --dport 4569 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p udp -m udp --dport 5036 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p udp -m udp --dport 5060 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p tcp -m tcp --dport 21 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p tcp -m tcp --dport 20 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p tcp -m tcp --dport 113 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p tcp -m tcp --dport 37 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p udp -m udp --dport 37 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p tcp -m tcp --dport 53 -j ACCEPT
- -A INPUT -d 67.105.178.130 -p udp -m udp --dport 53 -j ACCEPT
- -A INPUT -s 67.105.178.130 -d 67.105.178.130 -p tcp -j ACCEPT
- -A INPUT -s 67.105.178.130 -d 67.105.178.130 -p udp -j ACCEPT
- -A INPUT -d 67.105.178.130 -p tcp -j ULOG
- -A INPUT -d 67.105.178.130 -p udp -j ULOG
- -A INPUT -d 67.105.178.130 -p icmp -j ULOG
- -A INPUT -d 67.105.178.0/255.255.255.0 -p icmp -j ULOG
- -A INPUT -d 67.105.178.130 -p tcp -j DROP
- -A INPUT -d 67.105.178.130 -p udp -j DROP
- -A INPUT -d 67.105.178.130 -p icmp -j DROP
- -A INPUT -d 67.105.178.0/255.255.255.0 -p icmp -j DROP
- -A INPUT -d 67.105.178.140 -p tcp -j ULOG
- -A INPUT -d 67.105.178.140 -p udp -j ULOG
- -A INPUT -d 67.105.178.140 -p icmp -j ULOG
- -A INPUT -d 67.105.178.140 -p tcp -j DROP
- -A INPUT -d 67.105.178.140 -p udp -j DROP
- -A INPUT -d 67.105.178.140 -p icmp -j DROP
- -A FORWARD -m state --state INVALID -j DROP
- -A FORWARD -m state --state INVALID -j ULOG
- -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
23 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
446 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
448 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
449 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
5110 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
992 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8470 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8471 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8472 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8473 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8474 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8475 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8476 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
8480 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9470 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9471 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9472 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9473 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9474 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9475 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9476 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9480 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9080 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -m tcp --dport
9081 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -j ULOG
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p tcp -j DROP
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p udp -j ULOG
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p udp -j DROP
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p icmp -j ULOG
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.4 -p icmp -j DROP
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
23 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
446 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
448 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
449 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
5110 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
992 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8470 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8471 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8472 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8473 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8474 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8475 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8476 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
8480 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9470 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9471 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9472 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9473 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9474 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9475 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9476 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9480 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9080 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -m tcp --dport
9081 -j ACCEPT
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -j ULOG
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p tcp -j DROP
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p udp -j ULOG
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p udp -j DROP
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p icmp -j ULOG
- -A FORWARD -s ! 10.0.0.0/255.255.254.0 -d 10.0.0.5 -p icmp -j DROP
- -A FORWARD -d 67.105.178.0/255.255.255.0 -p icmp -j ULOG
- -A FORWARD -d 67.105.178.0/255.255.255.0 -p icmp -j DROP
- -A OUTPUT -s 10.0.0.103 -d 10.0.0.5 -p tcp -m tcp --dport 23 -j ACCEPT
- -A OUTPUT -s 10.0.0.103 -d 10.0.0.5 -p tcp -m tcp --dport 5010 -j ACCEPT
- -A OUTPUT -s 10.0.0.103 -d 10.0.0.5 -p tcp -m tcp --dport 5002 -j ACCEPT
- -A OUTPUT -s 10.0.0.103 -d 10.0.0.5 -p tcp -m tcp --dport 5001 -j ACCEPT
- -A OUTPUT -s 10.0.0.103 -p icmp -j DROP
- -A OUTPUT -s 10.0.0.103 -p udp -j DROP
- -A OUTPUT -s 10.0.0.103 -p tcp -j DROP
- -A OUTPUT -m state --state INVALID -j DROP
- -A OUTPUT -m state --state INVALID -j ULOG
- -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Mon Feb 16 09:48:48 2004
Patrick McHardy wrote:
| Peter Grace wrote:
|
|> Hello, ~ I'm posting to the list blindly this following report:
|
|
| Moved from linux-kernel to netfilter-devel ..
|
|>
|> LIST_DELETE: net/ipv4/netfilter/ip_conntrack_core.c:295
|> &ct->tuplehash[IP_CT_DIR_REPLY] (c40bf384) not in
|> &ip_conntrack_hash[hr]
|>
|> I believe the memory addresses are not as pertinent as the message
|> itself, but the screen filled up with 4-5 of these lines before
|> finally biting the dust.
|>
|> Can someone shoot me an e-mail in reply to let me know if this is a
|> bug in netfilter code or if I'm just somehow confusing the heck
|> out of the nat filter? I've got a set of nat forwarding rules that
|> forwards an ip address onto the internal lan, and then from there
|> I'm only allowing certain packets to go through -- that seems to
|> have exacerbated the problem..
|
|
| Please post your ruleset, your kernel version and other relevent
| information, this should not happen.
|
| Regards Patrick
|
|
|>
|> Thanks in advance!
|>
|> Pete
|>
|> -- --- /------------------------------------------------\ |Peter
|> Grace Phone: 484-875-9462 |Technology Analyst Fax:
|> 484-875-9461 |RealTime Technologies, Inc. Cell: 484-919-1400 |835
|> Springdale Drive, Suite 101 |Exton, PA 19341
|> \------------------------------------------------/
|
|
| - To unsubscribe from this list: send the line "unsubscribe
| linux-kernel" in the body of a message to majordomo@vger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
|
|
- --
- ---
/------------------------------------------------\
|Peter Grace Phone: 484-875-9462
|Technology Analyst Fax: 484-875-9461
|RealTime Technologies, Inc. Cell: 484-919-1400
|835 Springdale Drive, Suite 101
|Exton, PA 19341
\------------------------------------------------/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAMOD61bytwQSw7hoRArt8AKDqSz5rlfG7iTQaux+ffo3Okm4NjQCaAx61
S07okkmMvc6TvUyyjm60WbY=
=W30I
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: POSSIBLE BUG: netfilter/ip_conntrack_core
2004-02-16 14:59 POSSIBLE BUG: netfilter/ip_conntrack_core Peter Grace
2004-02-16 15:12 ` Patrick McHardy
@ 2004-02-17 14:04 ` Harald Welte
[not found] ` <403226F8.4040109@rttx.com>
1 sibling, 1 reply; 6+ messages in thread
From: Harald Welte @ 2004-02-17 14:04 UTC (permalink / raw)
To: Peter Grace; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Mon, Feb 16, 2004 at 09:59:41AM -0500, Peter Grace wrote:
> Hello,
> ~ I'm posting to the list blindly this following report:
We are concerned about your problem, but You didn't even bother to
mention your system hardware, configuration, kernel version, whihc
patches you use or anything else.
Please report to http://bugzilla.netfilter.org/ or the
netfilter-devel@lists.netfilter.org.
> Pete
--
- Harald Welte <laforge@gnumonks.org> http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: POSSIBLE BUG: netfilter/ip_conntrack_core
[not found] ` <20040217145534.GN981@sunbeam.de.gnumonks.org>
@ 2004-02-17 15:24 ` Peter Grace
2004-02-24 19:49 ` Peter Grace
0 siblings, 1 reply; 6+ messages in thread
From: Peter Grace @ 2004-02-17 15:24 UTC (permalink / raw)
To: Harald Welte; +Cc: Netfilter Development Mailinglist
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Harald Welte wrote:
|
| You aren't running an SMP kernel (even if it's only a UP box), are
| you?
Nope, it's a uniprocessor kernel.
Here is miscellaneous data gathered via REPORTING-BUGS instructions:
[1.] One line summary of the problem: Kernel freezes with netfilter
tuplehash problem
[2.] Full description of the problem/report: See previous e-mail
[3.] Keywords (i.e., modules, networking, kernel): netfilter, NAT,
conntrack
[4.] Kernel version (from /proc/version): 2.6.1
...
[7.] Environment: Debian GNU/Linux
[7.1.] Software (add the output of the ver_linux script here)
Linux brdgw1 2.6.1 #1 Fri Jan 23 17:26:33 EST 2004 i586 GNU/Linux
Gnu C 3.3.3
Gnu make 3.80
util-linux 2.12
mount 2.12
module-init-tools 3.0-pre5
e2fsprogs 1.35-WIP
PPP 2.4.2
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.1.15
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0.91
Modules Loaded af_packet unix
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 12
cpu MHz : 199.751
fdiv_bug : no
hlt_bug : no
f00f_bug : yes
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 393.21
[7.3.] Module information (from /proc/modules):
af_packet 21576 2 - Live 0xc4837000
unix 27632 14 - Live 0xc481e000
...
I cut some of the options out that I thought were not pertinent (i.e.,
IO ports and such -- if anyone wants this info, I'll be happy to supply)
Thanks,
Pete
- --
- ---
/------------------------------------------------\
|Peter Grace Phone: 484-875-9462
|Technology Analyst Fax: 484-875-9461
|RealTime Technologies, Inc. Cell: 484-919-1400
|835 Springdale Drive, Suite 101
|Exton, PA 19341
\------------------------------------------------/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAMjI41bytwQSw7hoRAgWCAJ0f+07LMc+IS6lhPNkLfQFOfCXJtwCfQk2Q
4BbpNya/28v/quoUUVAPMkE=
=Eg3q
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: POSSIBLE BUG: netfilter/ip_conntrack_core
2004-02-17 15:24 ` Peter Grace
@ 2004-02-24 19:49 ` Peter Grace
0 siblings, 0 replies; 6+ messages in thread
From: Peter Grace @ 2004-02-24 19:49 UTC (permalink / raw)
To: Netfilter Development Mailinglist
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey guys,
~ This problem happened again today, and this time I actually got a
kernel panic screen. Unfortunately, the stack trace was incomplete
(scrolled off the screen) so I couldn't give you guys a complete trace.
It definitely seemed to be the same problem (I was doing the same thing
that I did before -- adding a new static nat entry)
I'll find my original e-mail to linux-kernel and reforward it here --
below was my last communication to this list that enumerated all of the
stuff from REPORTING-BUGS.
Thanks a bunch,
Pete
Peter Grace wrote:
|
|
| Harald Welte wrote:
|
| | | You aren't running an SMP kernel (even if it's only a UP box),
| are | you?
|
| Nope, it's a uniprocessor kernel.
|
| Here is miscellaneous data gathered via REPORTING-BUGS instructions:
|
| [1.] One line summary of the problem: Kernel freezes with
| netfilter tuplehash problem [2.] Full description of the
| problem/report: See previous e-mail [3.] Keywords (i.e., modules,
| networking, kernel): netfilter, NAT, conntrack [4.] Kernel version
| (from /proc/version): 2.6.1 ... [7.] Environment: Debian GNU/Linux
| [7.1.] Software (add the output of the ver_linux script here)
|
| Linux brdgw1 2.6.1 #1 Fri Jan 23 17:26:33 EST 2004 i586 GNU/Linux
|
| Gnu C 3.3.3 Gnu make 3.80 util-linux
| 2.12 mount 2.12 module-init-tools 3.0-pre5
| e2fsprogs 1.35-WIP PPP 2.4.2 Linux C
| Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps
| 3.1.15 Net-tools 1.60 Console-tools 0.2.3
| Sh-utils 5.0.91 Modules Loaded af_packet unix
|
|
|
| [7.2.] Processor information (from /proc/cpuinfo):
|
| processor : 0 vendor_id : GenuineIntel cpu family :
| 5 model : 2 model name : Pentium 75 - 200 stepping
| : 12 cpu MHz : 199.751 fdiv_bug : no hlt_bug :
| no f00f_bug : yes coma_bug : no fpu : yes
| fpu_exception : yes cpuid level : 1 wp : yes flags
| : fpu vme de pse tsc msr mce cx8 bogomips : 393.21
|
|
| [7.3.] Module information (from /proc/modules):
|
| af_packet 21576 2 - Live 0xc4837000 unix 27632 14 - Live 0xc481e000
|
| ...
|
| I cut some of the options out that I thought were not pertinent
| (i.e., IO ports and such -- if anyone wants this info, I'll be happy
| to supply)
|
| Thanks, Pete
|
|
| -- --- /------------------------------------------------\ |Peter
| Grace Phone: 484-875-9462 |Technology Analyst
| Fax: 484-875-9461 |RealTime Technologies, Inc. Cell: 484-919-1400
| |835 Springdale Drive, Suite 101 |Exton, PA 19341
| \------------------------------------------------/
- --
- ---
/------------------------------------------------\
|Peter Grace Phone: 484-875-9462
|Technology Analyst Fax: 484-875-9461
|RealTime Technologies, Inc. Cell: 484-919-1400
|835 Springdale Drive, Suite 101
|Exton, PA 19341
\------------------------------------------------/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAO6rJ1bytwQSw7hoRAivdAKCTu/2D6MbcoVCsT4m0FwP7LzNXwACfWiqE
zLUEU+vL6W/tnvp8PAkS11w=
=M1g/
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-02-24 19:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-16 14:59 POSSIBLE BUG: netfilter/ip_conntrack_core Peter Grace
2004-02-16 15:12 ` Patrick McHardy
2004-02-16 15:25 ` Peter Grace
2004-02-17 14:04 ` Harald Welte
[not found] ` <403226F8.4040109@rttx.com>
[not found] ` <20040217145534.GN981@sunbeam.de.gnumonks.org>
2004-02-17 15:24 ` Peter Grace
2004-02-24 19:49 ` Peter Grace
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.