Dan Harkless
2003-Oct-10 03:53 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
Howdy. While experimenting with the ''accounting'' file on my
Red Hat 9 (with
stock 2.4.20-20.9 kernel; all update RPMs) / shorewall-1.4.7 system, I
happened to run ''shorewall status'', which is not among the
commands I
usually run (indeed I don''t think I''ve ever run it on my
system since the
RH9 install).
It got partway through the output of the command and then hung. I thought
it was just the command itself hanging, but I soon realized all my SSH
windows onto the machine were dead, and the machine wasn''t even
responding
to pings.
In a few minutes, I was able to get back on again (was *really* worried up
until then that something worse had happened), and determined that the
machine had apparently had a kernel panic. Unfortunately this is a
remotely-hosted machine, so I couldn''t see what appeared on the
console. I
checked the syslog -- it was not able to log anything before the crash.
I thought perhaps I had hit some bug related to the accounting stuff, so I
mv''ed ''accounting.orig'' back onto
''accounting'' (i.e. back to no accounting
entries) and did one more fresh reboot of my system.
Once it was back up, I tried running ''shorewall status'' again.
Kernel panic
again. So it''s repeatable, and it has nothing to do with accounting.
Unfortunately this is a server machine, so even if there are things I can
try in order to more closely diagnose this, I can''t afford to keep
crashing
the server.
Hopefully before too long I''m going to be setting up a new RH9 system
at
home, so I''ll certainly try ''shorewall status'' there
and see if it crashes
or not. Of course I won''t be able to completely duplicate hardware,
network
configuration, etc., and that might be a factor. I will say that this
machine has never crashed since I put it into production, until now.
Anyway, below is the output ''shorewall status'' gave prior to
crashing the
machine the second time. I see the final thing it did prior to dying was
print the header for the "newnotsyn" section. I''m pretty
sure this is the
point the output stopped at the first time as well, but unfortunately that
window no longer exists, so I can''t say for sure.
Any potential gotchas with newnotsyn? As can be seen in my configuration as
given in my "''accounting'' chain always shows 0 packets on
1-interface
machine" thread, I''m using the ''shorewall.conf''
default of "NEWNOTSYN=No",
and no "newnotsyn" options in ''interfaces''.
-------------------------------CUT HERE-------------------------------
Shorewall-1.4.7 Status at www - Fri Oct 10 02:52:57 PDT 2003
Counters reset Fri Oct 10 02:41:08 PDT 2003
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
128 162K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
2481 310K eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:''
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
0 0 eth0_fwd all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:''
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
128 162K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
2324 673K fw2net all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix `Shorewall:OUTPUT:REJECT:''
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain all2all (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp flags:!0x16/0x02
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix `Shorewall:all2all:REJECT:''
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain common (5 references)
pkts bytes target prot opt in out source destination
0 0 icmpdef icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:135
0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:137:139
0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:445
0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:139
0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:445
6 288 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:135
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:1900
12 585 DROP all -- * * 0.0.0.0/0
255.255.255.255
0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:113
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spt:53 state NEW
0 0 DROP all -- * * 0.0.0.0/0
207.12.255.255
Chain dynamic (2 references)
pkts bytes target prot opt in out source destination
Chain eth0_fwd (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
2481 310K dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
2229 274K tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
2481 310K net2fw all -- * * 0.0.0.0/0 0.0.0.0/0
Chain fw2net (1 references)
pkts bytes target prot opt in out source destination
2145 660K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
11 638 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp flags:!0x16/0x02
168 12241 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain icmpdef (1 references)
pkts bytes target prot opt in out source destination
Chain logflags (5 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 4 level 6 prefix `Shorewall:logflags:DROP:''
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain net2all (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp flags:!0x16/0x02
18 873 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix `Shorewall:net2all:DROP:''
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain net2fw (1 references)
pkts bytes target prot opt in out source destination
2438 308K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp flags:!0x16/0x02
4 304 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
icmp type 8
2 96 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:22
1 44 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:25
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:53
7 469 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp dpt:53
11 528 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:443
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:465
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW tcp dpt:995
18 873 net2all all -- * * 0.0.0.0/0 0.0.0.0/0
Chain newnotsyn (4 references)
pkts bytes target prot opt in out source destination
-------------------------------CUT HERE-------------------------------
--
Dan Harkless
http://harkless.org/dan/
Tom Eastep
2003-Oct-10 08:37 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On Fri, 2003-10-10 at 03:53, Dan Harkless wrote:> > Any potential gotchas with newnotsyn? As can be seen in my configuration as > given in my "''accounting'' chain always shows 0 packets on 1-interface > machine" thread, I''m using the ''shorewall.conf'' default of "NEWNOTSYN=No", > and no "newnotsyn" options in ''interfaces''.No gotchas that I''m aware of. At any rate, all "shorewall status" does is run user space tools; the only command given to iptables is the ''-L'' (list command). FWIW, I run the same kernel, have the same setting for NETNOTSYN, and run ''shorewall status'' without incident. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Dan Harkless
2003-Oct-10 11:17 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On October 10, 2003, Tom Eastep <teastep@shorewall.net> wrote:> > Any potential gotchas with newnotsyn? As can be seen in my configuration as > > given in my "''accounting'' chain always shows 0 packets on 1-interface > > machine" thread, I''m using the ''shorewall.conf'' default of "NEWNOTSYN=No", > > and no "newnotsyn" options in ''interfaces''. > > No gotchas that I''m aware of. At any rate, all "shorewall status" does > is run user space tools; the only command given to iptables is the ''-L'' > (list command).Yeah, I realize the underlying problem is almost certainly a kernel bug, and it''s just that ''shorewall status'' exposes it. Unfortunately I probably don''t have enough information to make a useful bug report to Red Hat.> FWIW, I run the same kernel, have the same setting for NETNOTSYN, and > run ''shorewall status'' without incident.Hmm. Would network card driver be a factor at all, or should it not come into this? I use e100.o (onboard Intel Ethernet chip): www-root> lsmod Module Size Used by Not tainted ipt_TOS 1656 12 (autoclean) ipt_REJECT 3992 4 (autoclean) ipt_LOG 4184 7 (autoclean) ipt_state 1080 20 (autoclean) ip_nat_irc 3280 0 (unused) ip_nat_tftp 2672 0 (unused) ip_nat_ftp 4112 0 (unused) ip_conntrack_irc 4112 1 ip_conntrack_tftp 2640 1 ip_conntrack_ftp 5296 1 ipt_multiport 1176 0 (autoclean) ipt_conntrack 1688 0 (autoclean) iptable_filter 2412 1 (autoclean) iptable_mangle 2776 1 (autoclean) iptable_nat 21752 3 (autoclean) [ip_nat_irc ip_nat_tftp ip_nat_ftp] ip_conntrack 27272 6 (autoclean) [ipt_state ip_nat_irc ip_nat_tftp ip_nat_ftp ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ipt_conntrack iptable_nat] ip_tables 15096 11 [ipt_TOS ipt_REJECT ipt_LOG ipt_state ipt_multiport ipt_conntrack iptable_filter iptable_mangle iptable_nat] e100 54596 1 microcode 4668 0 (autoclean) ohci1394 20168 0 (unused) ieee1394 48780 0 [ohci1394] keybdev 2976 0 (unused) mousedev 5556 0 (unused) hid 22244 0 (unused) input 5856 0 [keybdev mousedev hid] usb-uhci 26412 0 (unused) usbcore 79040 1 [hid usb-uhci] ext3 70784 4 jbd 51924 4 [ext3] I guess I''ll just have to remember never to run ''shorewall status''. :-( Any other commands that''d result in an ''iptables -L'' that I should avoid? -- Dan Harkless http://harkless.org/dan/
Tom Eastep
2003-Oct-10 11:33 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On Fri, 2003-10-10 at 11:17, Dan Harkless wrote:> N, and > > run ''shorewall status'' without incident. > > Hmm. Would network card driver be a factor at all, or should it not come > into this? I use e100.o (onboard Intel Ethernet chip): >It''s a possibility.> > I guess I''ll just have to remember never to run ''shorewall status''. :-( Any > other commands that''d result in an ''iptables -L'' that I should avoid?The following shorewall commands generate "iptables -L": show monitor status -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Dan Harkless
2003-Oct-10 11:52 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On October 10, 2003, Tom Eastep <teastep@shorewall.net> wrote:> > Hmm. Would network card driver be a factor at all, or should it not come > > into this? I use e100.o (onboard Intel Ethernet chip): > > It''s a possibility.''Kay, thanks.> > I guess I''ll just have to remember never to run ''shorewall status''. :-( > > Any other commands that''d result in an ''iptables -L'' that I should > > avoid? > > The following shorewall commands generate "iptables -L": > > show > monitor > statusHaven''t had any problem running ''shorewall show'' on the accounting chains. Presumably if I did ''shorewall show newnotsyn'' (and maybe ''shorewall show'' with no arguments?) I''d get the crash. Pretty sure I ran ''shorewall monitor'' the other day, and there was no crash. Sounds like from the description that it wouldn''t show the newnotsyn chain. Perhaps changing NEWNOTSYN to Yes might alleviate the crash? You do mention in shorewall.conf that there are some setups where you need to do that (though you''re not real clear on why), but those setups don''t apply to me, as far as I''m aware. What would I lose by changing NEWNOTSYN to Yes? Reduced ability to drop "stealth scan" packets or something? I note that in my /var/log/messages, of 632 "Shorewall" lines, 269 of them are ":newnotsyn:DROP" lines, so it''s certainly doing a lot of... something. -- Dan Harkless http://harkless.org/dan/
Tom Eastep
2003-Oct-10 12:11 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On Fri, 2003-10-10 at 11:52, Dan Harkless wrote:> > Perhaps changing NEWNOTSYN to Yes might alleviate the crash?I have no idea.> You do mention > in shorewall.conf that there are some setups where you need to do that > (though you''re not real clear on why), but those setups don''t apply to me, > as far as I''m aware.The only case where NEWNOTSYN=No can mess up on a single interface system is where that system acts as a router; I don''t believe that applies to you.> > What would I lose by changing NEWNOTSYN to Yes? Reduced ability to drop > "stealth scan" packets or something?Yes.> I note that in my /var/log/messages, > of 632 "Shorewall" lines, 269 of them are ":newnotsyn:DROP" lines, so it''s > certainly doing a lot of... something.NEWNOTSYN=Yes allows initial TCP packets other than SYN packets to be accepted. What you are seeing in your log are probably residue from terminated TCP sessions where one end or the other didn''t get cleaned up completely. Of course, what the ''newnotsyn'' chain does with packets that pass through it is totally independent of the ability to display the chain''s contents. The chain contains: a) A rule with a LOG (ULOG) target to log the packet. b) A rule with the DROP target to drop the packet. [root@lists shorewall]# shorewall show newnotsyn Shorewall-1.4.7 Chain newnotsyn at lists.shorewall.net - Fri Oct 10 12:10:22 PDT 2003 Counters reset Fri Oct 10 12:10:06 PDT 2003 Chain newnotsyn (3 references) pkts bytes target prot opt in out source destination 1 40 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:newnotsyn:DROP:'' 1 40 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 [root@lists shorewall]# Nothing that doesn''t occur in lots of other chains. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Dan Harkless
2003-Oct-10 12:27 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On October 10, 2003, Tom Eastep <teastep@shorewall.net> wrote:> The only case where NEWNOTSYN=No can mess up on a single interface > system is where that system acts as a router; I don''t believe that > applies to you.I see. Thanks.> Of course, what the ''newnotsyn'' chain does with packets that pass > through it is totally independent of the ability to display the chain''s > contents.Good point.> The chain contains: > > a) A rule with a LOG (ULOG) target to log the packet. > b) A rule with the DROP target to drop the packet.[...]> Nothing that doesn''t occur in lots of other chains.Okay. Well, as I said, I''m not positive it halted just before displaying the newnotsyn chain contents both times, only that it was partway through the ''shorewall status'' output both times. Perhaps next time I''m on-site where my server is located I''ll try shutting down processes that''d be actively writing to disk and then try a few different things to see if the crash goes away (and if it doesn''t, at least take note of where the kernel panic is located). Thanks for your guidance. -- Dan Harkless http://harkless.org/dan/
Tom Eastep
2003-Oct-10 12:31 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On Fri, 2003-10-10 at 12:25, Dan Harkless wrote:> > Okay. Well, as I said, I''m not positive it halted just before displaying > the newnotsyn chain contents both times, only that it was partway through > the ''shorewall status'' output both times. Perhaps next time I''m on-site > where my server is located I''ll try shutting down processes that''d be > actively writing to disk and then try a few different things to see if the > crash goes away (and if it doesn''t, at least take note of where the kernel > panic is located). > > Thanks for your guidance.You''re welcome -- and please keep us informed about what you learn. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Rodolfo J. Paiz
2003-Oct-10 14:41 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
At 12:33 10/10/2003, Tom Eastep wrote:>On Fri, 2003-10-10 at 11:17, Dan Harkless wrote: > > N, and > > > run ''shorewall status'' without incident. > > > > Hmm. Would network card driver be a factor at all, or should it not come > > into this? I use e100.o (onboard Intel Ethernet chip): > > > >It''s a possibility.Especially if he''s using the stock module that comes with the kernel. That module was _very_ buggy, and all were advised to get newer source straight from Intel a few months ago when I remember seeing this problem. I do not know if recent kernels (vanilla or Red Hat) fixed this issue. But you might want to find yourself a new e100.o just to check. -- Rodolfo J. Paiz rpaiz@simpaticus.com
Dan Harkless
2003-Oct-10 14:48 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
On October 10, 2003, "Rodolfo J. Paiz" <rpaiz@simpaticus.com> wrote:> > > Hmm. Would network card driver be a factor at all, or should it not come > > > into this? I use e100.o (onboard Intel Ethernet chip): > > > >It''s a possibility. > > Especially if he''s using the stock module that comes with the kernel.I am.> That module was _very_ buggy, and all were advised to get newer source > straight from IntelOh! I never heard about this. Thanks for the info!> a few months ago when I remember seeing this problem."This problem" meaning a crash when running ''shorewall status'' / ''iptables -L''?> I do not know if recent kernels (vanilla or Red Hat) fixed this > issue.I''m running the latest RH9 kernel release, so "no" on that count.> But you might want to find yourself a new e100.o just to check.I''ll look into it. Greatly appreciate the info. -- Dan Harkless http://harkless.org/dan/
Rodolfo J. Paiz
2003-Oct-10 15:23 UTC
[Shorewall-users] ''shorewall status'' repeatably crashes RH9 / shorewall-1.4.7 system
At 15:47 10/10/2003, you wrote:> > a few months ago when I remember seeing this problem. > >"This problem" meaning a crash when running ''shorewall status'' / >''iptables -L''?No, I just meant lots of "my Intel Ethernet doesn''t work" messages on mailing lists. -- Rodolfo J. Paiz rpaiz@simpaticus.com
Simon Matter
2004-Mar-17 11:53 UTC
Re: ''shorewall status'' repeatably crashes RH9 /shorewall-1.4.7 system
I had two kernel panics on a firewall when doing ''shorewall show connections'' after the box has been running stable for several months. The box is running RedHat 7.3 and it happened with both kernel-2.4.20-28.7 and kernel-2.4.20-30.7.legacy. I was using the eepro100 and the e100 drivers and it crashed with both. Hmm... Simon> > On October 10, 2003, Tom Eastep <teastep@shorewall.net> wrote: >> > Any potential gotchas with newnotsyn? As can be seen in my >> configuration as >> > given in my "''accounting'' chain always shows 0 packets on 1-interface >> > machine" thread, I''m using the ''shorewall.conf'' default of >> "NEWNOTSYN=No", >> > and no "newnotsyn" options in ''interfaces''. >> >> No gotchas that I''m aware of. At any rate, all "shorewall status" does >> is run user space tools; the only command given to iptables is the ''-L'' >> (list command). > > Yeah, I realize the underlying problem is almost certainly a kernel bug, > and > it''s just that ''shorewall status'' exposes it. Unfortunately I probably > don''t have enough information to make a useful bug report to Red Hat. > >> FWIW, I run the same kernel, have the same setting for NETNOTSYN, and >> run ''shorewall status'' without incident. > > Hmm. Would network card driver be a factor at all, or should it not come > into this? I use e100.o (onboard Intel Ethernet chip): > > www-root> lsmod > Module Size Used by Not tainted > ipt_TOS 1656 12 (autoclean) > ipt_REJECT 3992 4 (autoclean) > ipt_LOG 4184 7 (autoclean) > ipt_state 1080 20 (autoclean) > ip_nat_irc 3280 0 (unused) > ip_nat_tftp 2672 0 (unused) > ip_nat_ftp 4112 0 (unused) > ip_conntrack_irc 4112 1 > ip_conntrack_tftp 2640 1 > ip_conntrack_ftp 5296 1 > ipt_multiport 1176 0 (autoclean) > ipt_conntrack 1688 0 (autoclean) > iptable_filter 2412 1 (autoclean) > iptable_mangle 2776 1 (autoclean) > iptable_nat 21752 3 (autoclean) [ip_nat_irc ip_nat_tftp > ip_nat_ftp] > ip_conntrack 27272 6 (autoclean) [ipt_state ip_nat_irc > ip_nat_tftp ip_nat_ftp ip_conntrack_irc ip_conntrack_tftp > ip_conntrack_ftp ipt_conntrack iptable_nat] > ip_tables 15096 11 [ipt_TOS ipt_REJECT ipt_LOG ipt_state > ipt_multiport ipt_conntrack iptable_filter iptable_mangle iptable_nat] > e100 54596 1 > microcode 4668 0 (autoclean) > ohci1394 20168 0 (unused) > ieee1394 48780 0 [ohci1394] > keybdev 2976 0 (unused) > mousedev 5556 0 (unused) > hid 22244 0 (unused) > input 5856 0 [keybdev mousedev hid] > usb-uhci 26412 0 (unused) > usbcore 79040 1 [hid usb-uhci] > ext3 70784 4 > jbd 51924 4 [ext3] > > I guess I''ll just have to remember never to run ''shorewall status''. :-( > Any > other commands that''d result in an ''iptables -L'' that I should avoid? > > -- > Dan Harkless > http://harkless.org/dan/ > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
Tom Eastep
2004-Mar-17 14:52 UTC
Re: ''shorewall status'' repeatably crashes RH9 /shorewall-1.4.7 system
On Wednesday 17 March 2004 03:53 am, Simon Matter wrote:> I had two kernel panics on a firewall when doing ''shorewall show > connections'' after the box has been running stable for several months. > The box is running RedHat 7.3 and it happened with both kernel-2.4.20-28.7 > and kernel-2.4.20-30.7.legacy. I was using the eepro100 and the e100 > drivers and it crashed with both. Hmm... >"shorewall show connections" prints a heading then does: cat /proc/net/ip_conntrack From what I understand, the code that handles read requests to that particular pseudo-file is not a thing of beauty. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net