From: Stuart Young <cef-lkml@optusnet.com.au>
To: linux-kernel@vger.kernel.org, Rohit Neupane <rohitneupane@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Weird Problem with TCP
Date: Fri, 3 Sep 2004 01:06:23 +1000 [thread overview]
Message-ID: <200409030106.24476.cef-lkml@optusnet.com.au> (raw)
In-Reply-To: <93e09f0104090206334a708289@mail.gmail.com>
On Thu, 2 Sep 2004 23:33, Rohit Neupane wrote:
> On Thu, 02 Sep 2004 11:56:59 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote:
> > > * Everything works fine for about 5-10 mins then all of a sudden TCP
> > > services are not accessable.
> > > * For some reason TCP times out. However at the same time
> > > ping,traceroute and dns trace works without any problem.
> > > * The connected TCP sokets keeps working without any problem. I
> > > verified this by using Msn chat. I observerd that I chat session (
> > > which I had started when everything was normal) continued without any
> > > problem however I was not able to initiate a new chat session.
> >
> > Are you using session tracking. The symptoms you describe are
> > classically those of session tracking nat/firewalling/whatever running
> > out of table entries and being unable to allow new connections.
>
> No, it is not running any session tracking (ip_conntrack) neither it
> does nat. It is just a firewall with around 1600 rules in FORWARD
> mangle table and around 1500 rules in FORWARD filter table. Out of
> 1500 rules , 1377 rules are MAC filter rules.
> And it had 3 alias address for the interface conneted to the wirelss.
EEEEK! 1600? That is insane!
Consider cutting your rules into sections, and jumping to other tables to do
sections of the work. Perhaps you can filter on the start of the MAC address
and break this into smaller sections?
Also of note: MAC addresses are easily spoofed, so if you're using this to
lock out people on wireless, forget it, it doesn't work. Get them to use
tunnels (eg: ipsec) instead. The only real way MAC addresses even sort of
work is when you're providing a hotspot, ie: where you can't guarantee the
client to have anything apart from base wireless, and you should therefore
keep a tight leash on users connections by either timing them out regularly,
or making them keep open a https:// page to a login/AAA server (ie: a page
that auto-refreshes - when they stop refreshing the page, consider their
connection stale).
--
Stuart Young (aka Cef)
cef-lkml@optusnet.com.au is for LKML and related email only
next prev parent reply other threads:[~2004-09-02 15:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-02 9:21 Rohit Neupane
2004-09-02 10:56 ` Alan Cox
2004-09-02 13:33 ` Rohit Neupane
2004-09-02 15:06 ` Stuart Young [this message]
2004-09-05 21:46 ` Denis Vlasenko
[not found] ` <41372F3A.4040301@zianet.com>
2004-09-02 15:10 ` Rohit Neupane
2004-09-06 0:40 ` Andre Tomt
[not found] ` <1094168287.4025.35.camel@mentorng.gurulabs.com>
2004-09-03 3:07 ` Rohit Neupane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409030106.24476.cef-lkml@optusnet.com.au \
--to=cef-lkml@optusnet.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rohitneupane@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome