> newnat has an own talk-conntrack-nat.patch. In the extra directory you can
> find the non-newnat variant.
Thanks, but where is the newnat version then? The only talk modules are
these in the extra dir:
talk-conntrack-nat.patch
talk-conntrack-nat.patch.config.in
talk-conntrack-nat.patch.config
On Mon, 8 Apr 2002, Takuya Satoh wrote:
> > newnat has an own talk-conntrack-nat.patch. In the extra directory you can
> > find the non-newnat variant.
>
> Thanks, but where is the newnat version then? The only talk modules are
> these in the extra dir:
You're right and I spread false informati
On Mon, Apr 08, 2002 at 05:49:36AM +0200, Nils Ohlmeier wrote:
> FCP is our own creation, because of the lack of an 'offical' protocol from
> the IETF. It was and probaly will never become an offical IETF protocl.
Well, it has been an IETF draft, hasn't it?
> The basic idea behind the FCPd is f
On Sun, Apr 07, 2002 at 03:48:26PM +0200, Henrik Nordstrom wrote:
> On Sunday 07 April 2002 12:07, Brian J. Murrell wrote:
>
> > > Dynamically inserting/removing rules seems like a big hack, but
> > > not like a solution.
> >
> > Why? I thought that userspace solutions were _always_ considered
>
On Sun, Apr 07, 2002 at 06:28:01PM -0400, Brian J. Murrell wrote:
> On Sun, Apr 07, 2002 at 03:33:23PM +0200, Henrik Nordstrom wrote:
> >
> > A firewall who gives no access is very effective, but not likely to
> > make you very famous as it also inhibits any communication to take
> > place.
>
On Monday 08 April 2002 05:36, Brian J. Murrell wrote:
> But even with it, I have to trust the client app that it will do
> good (and secure) with the hole in the firewall that I have
> allocated for it.
See my earlier message. The holes should be subject to your
firewalling policy.
> Oh. I s
On Monday 08 April 2002 05:45, Brian J. Murrell wrote:
> > Only within the limitations of what the UPnP device accepts.
>
> But that is the question. If apps are just asking for mappings on
> the UPnP device (i.e. listen TCP port 456) how can the device
> impose any limitiations. There is nothi
On Sun, Apr 07, 2002 at 10:48:58AM +0200, Mario 'BitKoenig' Holbe wrote:
> Hello,
>
> about half a week ago, I wrote the mail below to netfilter@, but
> got no answers until now and even there is no answer in the
> archive, so maybe you can help ne with this issue?
>
there is an answer, but in [
hrmmm, ok after trying out "tc" for the last week i've noticed it is
not even nearly as powerfull as netfilter.
is still have the same problem with dropping packets as i did before,
it seems to break some connections (i'm not dropping SYN packets, or
any ones which are in state NEW), only those
On Mon, Apr 08, 2002 at 11:28:00AM +0200, Harald Welte wrote:
> there is an answer, but in [EMAIL PROTECTED] archive :)
Yes, sorry - the netfilter website is a bit slow, so I refused to
download 'the wole mailinglist archive' until now, but since I've
done it, I found the answers :)
> > i use ip
On Mon, Apr 08, 2002 at 11:16:38AM +0200, Harald Welte wrote:
>
> I totally agree. Of course those 'orders' would need to go through some
> firewall-admin defined policy, before hitting netfilter/iptables.
If it is indeed possible to do this. How does the UPnP determine for
what purposes a cli
On Mon, Apr 08, 2002 at 11:56:29AM +0200, Henrik Nordstrom wrote:
>
> By the same way as you firewalling policy knows to allow the user to
> go out on port 80. You have a policy saying that users X & Y are
> allowed to punch such holes for port 456 under certain given
> conditions.
By definit
> By definition there are no "defined" ports. Because the UPnP
> device has to allocate ports out to a whole lan of clients
> wanting (for
> instance) a listener, the same port cannot be used by all
> listeners. From the previous definition of how Messenger uses
> UPnP, a broker on the .NET n
On Monday 08 April 2002 16:29, Brian J. Murrell wrote:
> On Mon, Apr 08, 2002 at 11:16:38AM +0200, Harald Welte wrote:
> > I totally agree. Of course those 'orders' would need to go through some
> > firewall-admin defined policy, before hitting netfilter/iptables.
>
> If it is indeed possible to
> Brian you always wrote about trusting your clients.
> If you do not
> trust your clients don't connect them to the internet.
> How do you know in detail what your clients send
> or receive over connections
> to port 80? I assume that nearly all readers of this mailing
> list would be
>
On Mon, Apr 08, 2002 at 03:14:59PM +0200, Nigel Kukard wrote:
> hrmmm, ok after trying out "tc" for the last week i've noticed it is
> not even nearly as powerfull as netfilter.
I think the LARTC mailinglist is more apropriate, since it is about
interaction between iproute2/tc and netfilter/ipt
For anyone interested in the UPnP daemon, I have a (semi) working one up for
download.
It is terribly unsecure, probably unstable, and will need alot of work.
That said, it does compile and run, and allows a MSN Messenger clinet to
both initiated and accept voice and video traffic from behind a
In article <[EMAIL PROTECTED]>,
Brian J. Murrell <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 07, 2002 at 11:13:58AM +0200, Andre Breiler wrote:
>I think I disagree. Security (access mitigation) as always been
>there, NAT as kinda "grown on", through a historical path of
>MASQUERADING in 2.2, and heck
On Monday 08 April 2002 16:29, Brian J. Murrell wrote:
> If it is indeed possible to do this. How does the UPnP determine
> for what purposes a client request is being made? If the answer is
> "well the client says what it is for" then again, that is useless.
There is multiple choices here.
a
On Monday 08 April 2002 18:03, Nils Ohlmeier wrote:
> Brian you always wrote about trusting your clients. If
> you do not trust your clients don't connect them to the internet.
> How do you know in detail what your clients send or
> receive over connections to port 80? I assume that nearly all
Sorry for the double post, but I noticed that my original message ended up
stuck to the end of one of the first UPnP threads, and figured it may be
missed there. I'm not really sure how many people read the archives vs. how
many are actually subscribed to the list, but I figured this might warran
>
> But this thread is about how we can provide UPnP port mapping within
> iptables/netfilter in a sensible manner, not how poor the reality of
> Internet security actually is when you do not trust your clients at
> all. I say providing UPnP with a adequate level of security for the
> scope
As i'm almost finished with my new match (superlimit). I ran into some
strange things. It seams that each time I add a new rule to a table the
entire table is reloaded. Because match->checkentry() for my new match is being
runned once for each existing rule in the table and once for the new rule
c
On Tue, Apr 09, 2002 at 01:04:30AM +0200, Henrik Nordstrom wrote:
>
> a) The NAT defice fully trusts the client and opens whatever the
> client requests it to without asking.
:-(
> b) Authentication, requiring the user to identify himself before
> allowing the request and you trust the user.
On Tuesday 09 April 2002 01:18, Henrik Nordstrom wrote:
> But this thread is about how we can provide UPnP port mapping within
> iptables/netfilter in a sensible manner, not how poor the reality of
> Internet security actually is when you do not trust your clients at
> all. I say providing UPnP wi
On Tuesday 09 April 2002 03:48, Brian J. Murrell wrote:
> I must be missing something here because we seem be going around
> and around on this issue. There are no "defined" ports that you
> can discern what gets opened and what doesn't. It sounds to me
> like all ports are ephemeral, which mak
On Tuesday 09 April 2002 03:48, Nils Ohlmeier wrote:
> If i understand the spec correct, a UPnP deamon have also to
> provide control over your ppp-deamon. The main aspect of the spec
> is configuring and controling your dialup connection and the
> posibility to configure port-forwarding is addit
2002-04-09 03:31:22+0200, Joakim Axelsson <[EMAIL PROTECTED]> ->
[snip problem]
I hate answering my own mails :-) But, I talked to Martin Josefsson and he
told me that my observatiosn was correct. So how did I solve this problem. I
think it can be nice for anyone else runing into this problem:
Ugg, third time :-) Wasn't think clearly. You need to put this reference
counter INSIDE the allocated memory. Since iptables will run checkentry() on
one peace of memory (the new one) and destroy() on another (the old one).
Set the reference counter to 1 after allocating the memory first time
chec
I made NAT/conntrack module for xdmcp
But I don't know how to distribute...
something like patch-o-matic..but I don't know..
I modified ip_conntrack.h
diff ip_conntrack.h ip_conntrack.h.orig
1,5d0
< /* modified by Hojae Lee
< * for xdmcp support
< * 2002. 03. 18
< */
<
98,1
I made NAT/conntrack module for xdmcp
But I don't know how to distribute...
something like patch-o-matic..but I don't know..
I modified ip_conntrack.h
diff ip_conntrack.h ip_conntrack.h.orig
1,5d0
< /* modified by Hojae Lee
< * for xdmcp support
< * 2002. 03. 18
<
On Tue, Apr 09, 2002 at 03:22:05PM +0900, XX wrote:
>
> I made NAT/conntrack module for xdmcp
>
> But I don't know how to distribute...
>
> something like patch-o-matic..but I don't know..
Please send me a unified diff (diff -Nru linux-clean linux-xdmcp) of the
whole kernel tree.
I'll
32 matches
Mail list logo
