Pawel Foremski writes:
> For example because MPPE is optional and some sessions may be encrypted and
> some not. As I mentioned, we cannot influence the ISP in topic.
>
> More generally, I wanted to present an example of a layer-2 encapsulation
> that Linux does not know or (as in this case)
David Miller writes:
> From: [EMAIL PROTECTED] (Stephen J. Bevan)
> Date: Thu, 19 Oct 2006 19:18:41 -0700
>
> > Pawel Foremski writes:
> > > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE
> > > traffic, for example.
> >
>
Pawel Foremski writes:
> Consider such an example: our task is to bridge two LANs managed by a
> third-party ISP over a wireless link, with the highest performance possible
> for such medium. The ISP has its clients on one LAN and a PPPoE
> concentrator on the second one. Because the ISP doesn
Pawel Foremski writes:
> First, ccrypts task is to secure Ethernet, not IP.
Understood, but the vast majority of traffic running over Ethernet
that a user cares about is IP and so IPsec does the job. Obviously
IPsec cannot handle non-IP traffic but the question is what non-IP
traffic do users wa
Dawid Ciezarkiewicz writes:
> You're right. I'll add such documentation. For now - short version: as a
> company dealing with wifi regularly we often come to a problem - using wifi
> bridges with strengths like price, "CE included", easy integration, good
> bandwidth, distance etc. - that th
Dawid Ciezarkiewicz writes:
> I'd be thankful for your opinions about that idea. Please forgive me any
> nuances that I didn't know about.
* I suggest extending the documentation with some motivating examples
of why someone would want to use this rather than IPsec for IP
and/or in what scen
Caitlin Bestler writes:
> More to the point, on what basis would the application be rejecting a
> connection request based solely on the SYN?
Perhaps not the reason that Martin is interested in but ...
Say you are writing a transparent proxy i.e. when a TCP connection is
made through the box, r
David Miller writes:
> Essentially, if you use ports as part of your selector,
> then it is impossible to handle anything other than the
> first fragment of a fragmented frame because the subsequent
> fragments will not have the ports which you need in order
> to match.
If you have port/proto
Alexey Kuznetsov writes:
> Probably, you are not aware that "standard IPsec tunnel device",
> if it is created:
>
> 1. Probably, will not accept fragmented frames, because IPsec cannot
>handle them
IPsec can handle them, though not particularly smoothly if the IPsec
tunnel is only suppos
>
>
> What I great idea. Now I just have to get every host I want to
> interoperate with to support a nonstandard configuration. The scary
> part is that if I motivate it with "Linux is too stupid to handle
> standard tunnel-mode IPsec" I might actually get away with it.
>
>
Linux
H. Peter Anvin writes:
> Fair enough. However, that does beg a question: is there any sane way
> to create the pseudo-device model on top of the current model, as a
> convenience layer? That way you could get the best of both.
I assume you were using tunnel-mode IPsec and depending on exact
Balazs Scheidler writes:
> I would like to easily match a set of dynamically created interfaces
> from my packet filter rules. The attached patch forms the basis of my
> implementation and I would like to know whether something like this is
> mergeable to mainline.
[snip]
> The implementation:
12 matches
Mail list logo
