Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e3b438..bc571b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3200,6 +3200,12 @@ L: [EMAIL PROTECTED]
W: http://www.netfilter.org/
W: http://www.iptab
On Wed, 20 Jun 2001, Pete Toscano wrote:
> I had a similar problem with this yesterday. Try moving your .config
> file to a safe place, making mrproper, then moving your .config back and
> rebuilding. I did this and all was well.
>
> HTH,
> pete
Thanks Pete. I will give that a try..
>
>
I had a similar problem with this yesterday. Try moving your .config
file to a safe place, making mrproper, then moving your .config back and
rebuilding. I did this and all was well.
HTH,
pete
On Wed, 20 Jun 2001, Ted Gervais wrote:
> Wondering something..
> I ran insmod to bring up ip_tables
oni wrote:
>
> > Have you also compiled modules for ipchains and ipfwadm support??
>
>
> Yes. Is this a mistake??
>
> >
> >
> > On Wed, 20 Jun 2001, Ted Gervais wrote:
> >
> > > Wondering something..
> > > I ran insmod to bring up ip_tab
On Wed, 20 Jun 2001, Jonathan Brugge wrote:
> > > > Wondering something..
> > > > I ran insmod to bring up ip_tables.o and I received the following
> >error:
> > > >
> > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved
> > > > symbol nf_unregister_sockopt
> > > > /lib/mod
> > On Wed, 20 Jun 2001, Ted Gervais wrote:
> >
> > > Wondering something..
> > > I ran insmod to bring up ip_tables.o and I received the following
>error:
> > >
> > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved
> > > symbol nf_unregister_sockopt
> > > /lib/modules/2.4.5
On Wed, 20 Jun 2001, Luigi Genoni wrote:
> Have you also compiled modules for ipchains and ipfwadm support??
Yes. Is this a mistake??
>
>
> On Wed, 20 Jun 2001, Ted Gervais wrote:
>
> > Wondering something..
> > I ran insmod to bring up ip_tables.o and I r
Have you also compiled modules for ipchains and ipfwadm support??
On Wed, 20 Jun 2001, Ted Gervais wrote:
> Wondering something..
> I ran insmod to bring up ip_tables.o and I received the following error:
>
> /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresol
Wondering something..
I ran insmod to bring up ip_tables.o and I received the following error:
/lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved
symbol nf_unregister_sockopt
/lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved
symbol nf_register_sockopt
This is
On Fri, Jun 08, 2001 at 07:17:22AM +0200, Nico Schottelius wrote:
> Hello!
>
> I don't really know howto specify that kmod
> should autoload the ipchains module, when I am
> using ipchains.
>
> Anyone any idea howto tell kmod to load it then ?
there is no way to do t
On Mon, 18 Jun 2001, J Sloan wrote:
> > I just ran into something odd. To me anyways, it was odd.
> > I just installed and brought up kernel 2.4.5 and my ipchains failed.
> > So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> > that also fails.
&g
Ted Gervais wrote:
> I just ran into something odd. To me anyways, it was odd.
> I just installed and brought up kernel 2.4.5 and my ipchains failed.
> So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> that also fails.
>
> Has anyone got any version of ipc
Ted Gervais wrote:
>
> I just ran into something odd. To me anyways, it was odd.
> I just installed and brought up kernel 2.4.5 and my ipchains failed.
> So I upgraded to the latest (that I could find) ipchains-1.3.10, and
> that also fails.
>
> Has anyone got any versio
ronto:~# uname -r
2.4.5-ac15
ronto:~# ipchains --version
ipchains 1.3.10, 1-Sep-2000
ronto:~# ipchains -L
Chain input (policy ACCEPT):
target prot opt sourcedestination ports
DENY all l- pD951B780.dip.t-dialin.net anywhere
n/a
DENY all l
I just ran into something odd. To me anyways, it was odd.
I just installed and brought up kernel 2.4.5 and my ipchains failed.
So I upgraded to the latest (that I could find) ipchains-1.3.10, and
that also fails.
Has anyone got any version of ipchains to work with the new(er) kernels?
---
Doubt
Hello!
I don't really know howto specify that kmod
should autoload the ipchains module, when I am
using ipchains.
Anyone any idea howto tell kmod to load it then ?
Nico
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Fri, 27 Apr 2001, David S. Miller wrote:
> Kai, can you try this patch out? I think it does the right
> thing. What I'm mostly interested in is if your ipchains
> setup works for the resulting kernel, I've already checked
> that it links properly. :-)
I'm n
Kai Germaschewski writes:
> If you get this mail, it works okay :-) (Just using a simple
> masquerading setup here)
Cool, I've sent this fix off to Rusty and Linus already.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Fri, 27 Apr 2001, David S. Miller wrote:
> Kai, can you try this patch out? I think it does the right
> thing. What I'm mostly interested in is if your ipchains
> setup works for the resulting kernel, I've already checked
> that it links properly. :-)
If you get th
Kai, can you try this patch out? I think it does the right
thing. What I'm mostly interested in is if your ipchains
setup works for the resulting kernel, I've already checked
that it links properly. :-)
--- net/ipv4/netfilter/Makefile.~1~ Thu Apr 26 23:30:39 2001
+++ net/ipv4
Kai Germaschewski writes:
> Anyway, the appended patch fixed the problem for me, vmlinux links okay
> now - didn't try if it works, though.
This may work, but it is evidently the wrong change.
The helpers list desired by net/ipv4/netfilter/ip_nat_*.c is
in net/ipv4/netfilter/ip_nat_helper.c a
On Fri, 27 Apr 2001, David S. Miller wrote:
>> net/network.o: In function `ip_nat_setup_info':
>> net/network.o(.text+0x37b3e): undefined reference to `helpers'
>> net/network.o(.text+0x37b54): undefined reference to `helpers'
>
> Your configuration seems impossible, somehow the config system al
v4/netfilter/Config.in explains everything:
: if [ "$CONFIG_IP_NF_CONNTRACK" != "y" ]; then
: if [ "$CONFIG_IP_NF_IPTABLES" != "y" ]; then
: tristate 'ipchains (2.2-style) support' CONFIG_IP_NF_COMPAT_IPCHAINS
CONFIG_IP_NF_COMPAT_IPCHAINS depends o
On Fri, 27 Apr 2001, David S. Miller wrote:
> Your configuration seems impossible, somehow the config system allowed
> you to set CONFIG_IP_NF_COMPAT_IPCHAINS without setting
> CONFIG_IP_NF_CONNTRACK.
Wow.
Now, if I set "connection tracking" to "y", the ipc
Your configuration seems impossible, somehow the config system allowed
you to set CONFIG_IP_NF_COMPAT_IPCHAINS without setting
CONFIG_IP_NF_CONNTRACK.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
net/network.o: In function `ip_nat_setup_info':
net/network.o(.text+0x37b3e): undefined reference to `helpers'
net/network.o(.text+0x37b54): undefined reference to `helpers'
.config bzip2'ed:
begin 644 .config.bz2
M0EIH.3%!629362!2/`L``EC?@$`0$`)_XC"((L@@8`;<+Z'5[WNZN[I;
M9NYNVL,\6=>&IDTU,0T
On Wed, 25 Apr 2001, Andrew B. Cramer wrote:
> Greetings All,
Hey Andy - haven't heard from you since work on a replacement linuxHQ (ahh
- those were the days, lot's of free time :) )
> After upgrading from kernel 2.0.38 w/ slackware-3.4 to
> kernel 2.2.16 w/ slackware-7.1 I have develope
192.168.0.0 i/f 192.168.0.1 subnet
> 255.255.255.128
> eth1 - 100meg on net 192.168.0.128 i/f 192.168.0.130 subnet
> 255.255.255.128
>
> >From either network I can use ipchains and surf/telnet/ftp/... on
> each network to the ppp0 dialup connection. I cannot ping or
> a
192.168.0.130 subnet
255.255.255.128
>From either network I can use ipchains and surf/telnet/ftp/... on
each network to the ppp0 dialup connection. I cannot ping or
anything from eth0 to eth1 or back.
-Route with ppp0 up
Destination Gateway Genm
Rusty Russell writes:
> Oops. Thanks to Anton for testing and touching up this patch.
>
> The 2.0/2.2 setsockopt code used to do the copy_from_user for you...
I've applied this to my tree, thanks a lot.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
In message <01013014063301.15042@Petete> you write:
> I use kernel 2.4.0 + ipchains compatibilty. I use ipchains 1.3.9
>
> This code:
>
> ipchains -A input -p tcp --dport 80 -s 192.168.0.35 -j REDIRECT 81
Oops. Thanks to Anton for testing and touching up thi
Sun UltraSparc 450, 1 hd scsi, 512 mb ram, kernel 2.4.0,
debian woody, kernel 2.4.0
I use kernel 2.4.0 + ipchains compatibilty. I use ipchains 1.3.9
This code:
ipchains -A input -p tcp --dport 80 -s 192.168.0.35 -j REDIRECT 81
CRASHES the machine! No response
of these are enabled and your machine acts
> > as a
> > router lots of CPU could get burned in defragmentation, and packets
> > will not forwarded until all fragments arrived.
>
> Hmm... ok, what if I'm on a single nic system using ipchains on the
> input and want t
in defragmentation, and packets
> will not forwarded until all fragments arrived.
Hmm... ok, what if I'm on a single nic system using ipchains on the
input and want to always defrag before they hit the ipchains
filter, what settings would I need? No masq., no NAT. (bearing in
mind that ipchains
On Wed, Jan 17, 2001 at 05:15:54PM -, Tony Gale wrote:
>
> On 17-Jan-2001 Jussi Hamalainen wrote:
> > On Wed, 17 Jan 2001, Tony Gale wrote:
> >
> >> It looks like this is due to the odd way in which ipchains handles
> >> fragments. Try:
> >>
>
On 17-Jan-2001 Jussi Hamalainen wrote:
> On Wed, 17 Jan 2001, Tony Gale wrote:
>
>> It looks like this is due to the odd way in which ipchains handles
>> fragments. Try:
>>
>> echo 1 > /proc/sys/net/ipv4/ip_always_defrag
>
> Thanks, this seems to do the t
On Wed, 17 Jan 2001, Tony Gale wrote:
> It looks like this is due to the odd way in which ipchains handles
> fragments. Try:
>
> echo 1 > /proc/sys/net/ipv4/ip_always_defrag
Thanks, this seems to do the trick. Does this oddity still exist
in 2.4?
--
-=[ Count Zero / TBH - J
It looks like this is due to the odd way in which ipchains handles
fragments. Try:
echo 1 > /proc/sys/net/ipv4/ip_always_defrag
-tony
On 17-Jan-2001 Jussi Hamalainen wrote:
> There seems to be a bug in ipchains. Matching port 65535 seems to
> always fail. If I set the chain policy
There seems to be a bug in ipchains. Matching port 65535 seems to
always fail. If I set the chain policy to REJECT or DENY and then
add a rule that accepts TCP to/from ports 0:65535, packets going to
port 65535 will still be caught by the kernel. Is there a fix for
this? It's driving me nuts
In message <3A585D9F.21907.1452FA04@localhost> you write:
> I've noticed that my Linux boxes take quite a hit in terms of
> packets per second rate when I define ipchains rules with
> 2.2.X kernels. Does the netfilter replacement found in 2.4
> kernels improve this performa
I've noticed that my Linux boxes take quite a hit in terms of
packets per second rate when I define ipchains rules with
2.2.X kernels. Does the netfilter replacement found in 2.4
kernels improve this performance?
11101101 (Ed)
-
To unsubscribe from this list: send the line "unsubsc
On Tue, Dec 19, 2000 at 08:32:48PM -0500, John Covici wrote:
> I configured 2.4.0 test12 to use the ipchains compatability option as
> a module and I did a modprobe on all the other modules in that section
> of such as iptable_filter, etc. When I tried to do the modprobe on
>
I&#
I configured 2.4.0 test12 to use the ipchains compatability option as
a module and I did a modprobe on all the other modules in that section
of such as iptable_filter, etc. When I tried to do the modprobe on
ip_nf_compat_ipchains (if I have the name correct) it said device or
resource busy
Hi,
This tiny patch extends ipchains logging. This way one can distinguish
(plain) connection attempts and (stealth) scans. E.g.
kernel: Packet log: input - lo PROTO=6 127.0.0.1:40326 127.0.0.1:80
L=40 S=0x00 I=5808 F=0x T=51 (#1)
vs.
L=40 S=0x00 I=5808 F=0x T=51 SYN ACK (#1)
and
L=40 S
On Wed, 6 Dec 2000, Rusty Russell wrote:
>Date: Wed, 06 Dec 2000 11:40:12 +1100
>From: Rusty Russell <[EMAIL PROTECTED]>
>To: Mike A. Harris <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PATCH] ipchains log will show all flags
>
>In mess
In message <[EMAIL PROTECTED]> you write
:
> Personally, I'd like to see the rule number stay on the end,and
> have the new display just before it. The rule number in the
> middle looks messy.
But what will break people's perl scripts?
I think leaving the rule number at the end is probably the
On Wed, 6 Dec 2000, Rusty Russell wrote:
>Date: Wed, 06 Dec 2000 00:55:09 +1100
>From: Rusty Russell <[EMAIL PROTECTED]>
>To: Christian W. Zuckschwerdt <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PATCH] ipchains log will show all flags
>
>In m
On 05-Dec-2000 Christian W. Zuckschwerdt wrote:
> Hi Linus,
>
> This tiny patch extends ipchains logging. This way one can
> distinguish
> (plain) connection attempts and (Xmas, Fin,...) scans. E.g.
> kernel: Packet log: input - lo PROTO=6 127.0.0.1:40326
> 127.0.0.1:80
>
In message <0012051408110.1526-10@localhost> you write:
> Hi Linus,
>
> This tiny patch extends ipchains logging. This way one can distinguish
> (plain) connection attempts and (Xmas, Fin,...) scans. E.g.
> kernel: Packet log: input - lo PROTO=6 127.0.0.1:40326 127.0.0
Hi Linus,
This tiny patch extends ipchains logging. This way one can distinguish
(plain) connection attempts and (Xmas, Fin,...) scans. E.g.
kernel: Packet log: input - lo PROTO=6 127.0.0.1:40326 127.0.0.1:80
L=40 S=0x00 I=5808 F=0x T=51 (#1)
vs.
L=40 S=0x00 I=5808 F=0x T=51 (#1) B
In message <[EMAIL PROTECTED]> you
write:
> hi!
>
> i have the following very nasty problem.
> everytime i execute ipchains -F [rule] my box freezes for 25 minutes!
> i run slackware on 2.2.17.
You mean `ipchains -F [chain]'? It's possible that your rules could
Good afternoon, Michael,
(The linux-kernel mailing list is not really the best place for
userspace issues. You should probably use the ipmasq list for future
questions. See http://netfilter.kernelnotes.org/ipchains/ for the
ipchains homepage and http://ipmasq.cjb.net for info on that
hi!
i have the following very nasty problem.
everytime i execute ipchains -F [rule] my box freezes for 25 minutes!
i run slackware on 2.2.17.
a friend of mine told me that he had a simliar problem and fixed it with
downgrading shlibs.
any suggestion??
thx
michael
below the output of
sorry: it was with iptables, not ipchains
=
modprobe iptable_nat
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
=
g. everything else as in previous post
les
-
To unsubscribe from this list: send the line "unsubscri
[My first linux crash in over 3 years]
My linux box was set up for ipmasq with:
===
/sbin/modprobe ip_masq_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
/sbin/ipchains -M -S 7200 10 160
/sbin/ipchains -P forward DENY
/s
On Sat, Sep 09, 2000 at 03:03:27PM +0900, NIIBE Yutaka wrote:
> - }
> + if (optname == IP_PKTINFO || optname == IP_RECVTTL
> + || optname == IP_RECVTOS || optname == IP_RECVOPTS
> + || optname == IP_RETOPTS || optname == IP_TOS
> + || optname == IP_TTL || optname ==
David S. Miller wrote:
> Could you send me a patch which fixes the problem in this way?
Sure. Here is the one. The occurrence of the IP_XXX corresponds the
one in switch/case.
Thank you for your time,
--- linux-2.4.0-test8-pre6/net/ipv4/ip_sockglue.c Fri Aug 11 05:01:26 2000
+++ linux/
From: NIIBE Yutaka <[EMAIL PROTECTED]>
Date: Sat, 09 Sep 2000 12:18:28 +0900
I'd like to explain my point clearly. My point is that accessing
with get_user as int is questionable. In my case, it's string. I
don't think all the string argment to the kernel should be aligned.
Tha
at the argument is properly
> aligned to 4 bytes?
Because (I think) it's not needed by the interface definition.
> I would really like to see specific examples of the failure before I
> consider this issue further.
OK, here's example (I'm talking about ipchains 1.3.
From: NIIBE Yutaka <[EMAIL PROTECTED]>
Date:Sat, 09 Sep 2000 11:25:28 +0900
Here's a patch, avoiding useless access.
This seems like a large ugly hack.
Why not make sure in the user tools that the argument is properly
aligned to 4 bytes?
IP-chains works fine on Alpha and Sparc
With ipchains, we have alignment problem. H. Kambara
<[EMAIL PROTECTED]> found that it core dumps on SuperH machine.
The cause of this problem is get_user accesses wrongly in
ip_setsockopt.
Here's a patch, avoiding useless access.
diff -ruN linux-2.4.0-test8-pre6/net/ipv4/ip_sockgl
61 matches
Mail list logo
