rite a NAT module, since imho the normal NAT
> framework is able to cope with this protocol.
>
> Thanks to the people behind ethereal for including Quake III
> protocol recognition in their sniffer.
>
> Regards,
> Filip
>
Brad
=
Brad Chapman
Permanent e-mail: [EMAIL PR
Mr. Filip,
--- Sneppe Filip <[EMAIL PROTECTED]> wrote:
> Brad Chapman wrote:
> >
> > OK. I understand this analysis, but to me, it doesn't explain why
> >this conntracker is needed. AFAICT on my system, everything is handled by
> >the basic UDP
pr 12 16:44:37 2002
+++ ipt_REJECT.hFri Apr 12 16:44:28 2002
@@ -9,6 +9,7 @@
IPT_ICMP_ECHOREPLY,
IPT_ICMP_NET_PROHIBITED,
IPT_ICMP_HOST_PROHIBITED,
+ IPT_ICMP_ADMIN_PROHIBITED,
IPT_TCP_RESET
};
=
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mai
Mr. Harald,
--- Harald Welte <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 12, 2002 at 01:55:11PM -0700, Brad Chapman wrote:
> > Mr. Harald,
>
> Brad,
>
> > Here is a patchset to add ICMP type-3-code-13 to the REJECT target.
> > Patches are enclosed and
Mr. Harald,
--- Harald Welte <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 15, 2002 at 11:29:07AM +0800, Fabrice MARIE wrote:
> >
> > Hello,
> >
> > On Monday 15 April 2002 08:46, Brad Chapman wrote:
> > > Mr. Harald,
> > > > Thanks for the
ilable? Anyone willing to undertake a project like this?
Harald Welte wrote an ECN target a few weeks ago and then got rid of it
because of a b0rKed design. I think DSCP does everything your ECN target/match
can do, and I think it does more as well (not sure about this). Perhaps if your
ECN ta
somewhere else (I can't figure this stuff out :(
It's highly confusing. I think Mr. Harald can tell you with certainty.
Harald?
>
> Regards,
>
> kisza
>
> --
Brad
=
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
somewhere else (I can't figure this stuff out :(
It's highly confusing. I think Mr. Harald can tell you with certainty.
Harald?
>
> Regards,
>
> kisza
>
> --
Brad
=
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
' is a little bit ugly.
>
> What about 'stateless' (also misleading a little bit...)?
Here are a few possibilities, OTTOMH: nostate, conntrack, ctblock
>
> Technically, the debug and notrack/stateless tables could be unified.
> For a clean separation of func
tem. What about hooking the
table directly into the conntrack core, and simply calling ipt_do_table() _before_
the ip_conntrack_in() function is entered, either directly at NF_IP_PRE_ROUTING, or
after ip_conntrack_local() at NF_IP_LOCAL_OUT?
Precedent: the nat table. What does everyone think?
>
Mr. Jozsef,
--- Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Apr 2002, Brad Chapman wrote:
>
> > > So we need to filter them out before conntrack and currently that seems
> > > impossible without adding the notrack/prestate table.
>
> >
ntrack_protocol_tcp_init(void);
#endif /*_IP_CONNTRACK_PROTOCOL_H*/
=
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
Alternate e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Tax Center - online filing wit
ither?
Thanks,
Brad
=
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
Alternate e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
Mr. Josefsson,
--- Martin Josefsson <[EMAIL PROTECTED]> wrote:
> On Sun, 2002-04-21 at 00:21, Brad Chapman wrote:
> > Everyone,
> >
> > In the current CVS repository, the 0-newnat13.patch appears to have
> > been very badly broken - it doesn't app
_HO, that he should be allowed to join the Core Team.
What do you both think?
>
>
> > Regards,
> > kisza
>
> --
> Live long and prosper
> - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/
Thanks,
Brad
=
Brad Chapman
Perm
Mr. Harald,
--- Harald Welte <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 29, 2002 at 02:01:30PM -0700, Brad Chapman wrote:
> > It seems to me that kisza is currently the only person whatsoever
> > actually doing anything at all with ip6tables. Considering that, along with
>
Mr. Harald,
--- Harald Welte <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 29, 2002 at 02:01:30PM -0700, Brad Chapman wrote:
> > It seems to me that kisza is currently the only person whatsoever
> > actually doing anything at all with ip6tables. Considering that, along with
>
Mr. Harald,
--- Harald Welte <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 15, 2002 at 03:41:25AM -0700, Brad Chapman wrote:
> > > There is no real change in the structure layout, it's just one additional
> > > value that is becoming valid...
> >
> >
patibility with older kernels and older iptables installations. You mentioned
using a piggyback mechanism for the ipt_match/ipt_target structs to prevent
API changes. Will a new API eventually emerge (ipt_modifier)? And if a new API
does emerge, what kernel version would it be aimed for (2.4.xx?
ter->destroy()
destroy_conntrack()
ip_conntrack_put()
nf_conntrack_put()
Which one of these will properly destroy a connection entry and notify
the NAT subsystem as well? (I seem to be torn between skb->nfct->master->destroy()
and destroy_conntrack())
Thanks,
; Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> [root@prometeus linux]# iptables -t mangle -L
> iptables: libiptc/libip4tc.c:384: do_check: Assertion `h->info.valid_hooks
> == (1 << 0 | 1 << 3)' failed.
> Aborted
> [root@prome
Everyone,
Does anyone have any information, code, or locations where I could
get code for ICQ support in netfilter?
Thanks,
Brad Chapman
=
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
Alternate e-mail: [EMAIL PROTECTED
22 matches
Mail list logo
