On Friday, 20 October 2006 21:53, Jay Vosburgh wrote:
> Dawid Ciezarkiewicz <[EMAIL PROTECTED]> wrote:
>
> >On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote:
> >> It would seem to me that extending an existing mode would be more
> >> desirable than ad
On Thursday, 19 October 2006 05:57, Stephen J. Bevan wrote:
> And if the packets come out of order i.e. you get a packet with a new
> key followed by a packet with the old key?
As IV from invalid frames are saved ccrypt will synchronize anyway, but I was
wrong in one aspect - in current implement
On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote:
> It would seem to me that extending an existing mode would be more
> desirable than adding yet another mode to worry about. I don't even
> like the fact that there are as many as there are, but I understand why
> they are there.
Ack. I
On Wednesday, 18 October 2006 11:15, Dawid Ciezarkiewicz wrote:
> > * Given your desire not to change the size of the payload you have no
> > space for MAC. This makes it easier (but by no means easy) to alter
> > the payload in such a way that it is still decryp
On Wednesday, 18 October 2006 12:16, David Miller wrote:
> From: Dawid Ciezarkiewicz <[EMAIL PROTECTED]>
> Date: Wed, 18 Oct 2006 11:51:46 +0200
>
> > I've tried to put ccrypt handlers as close to hardware xmit and recv as
> > possible so local reorder doesn&
On Wednesday, 18 October 2006 05:25, David Miller wrote:
> From: [EMAIL PROTECTED] (Stephen J. Bevan)
> Date: Tue, 17 Oct 2006 20:21:46 -0700
>
> > * You write "frames will be delivered in order, so on the other side
> > IV can be always in sync."
>
> In fact, in addition to your comments, Linu
On Wednesday, 18 October 2006 05:21, you wrote:
> 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 ex
On Monday, 16 October 2006 23:30, Andy Gospodarek wrote:
> On Mon, Oct 16, 2006 at 09:07:57PM +0200, Dawid Ciezarkiewicz wrote:
> > >
> > > Before getting into the technical bits of the patch, what's the
> > > reason for wanting to do this, and why is this
On Monday, 16 October 2006 20:50, you wrote:
>
> Dawid Ciezarkiewicz <[EMAIL PROTECTED]> wrote:
> [...]
> >+weighted-rr or 7
> >+
> >+Weighted round-robin bonding. In this mode bonding
> >+interface will use weights assigned to
On Monday, 16 October 2006 20:21, Dawid Ciezarkiewicz wrote:
> This patch is little thinner then the previous one.
I'm sorry for that. I've just ... nevermind. Here goes the patch.
Should I post patch for ifenslave here, too?
diff -Nur linux-2.6.17.orig/Documentation/networkin
This patch is little thinner then the previous one.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday, 15 October 2006 23:35, you wrote:
> > Hi,
> > I'd be thankful for your opinions about that idea. Please forgive me any
> > nuances that I didn't know about.
>
> This limits the system to only talking to one other system on the same
> link. I guess you could have per-MAC keys and asso
tx
+$ echo -n "null" > /sys/class/net/eth0/ccrypt_rx
+
+Note that key lenght must be valid for selected algorithm.
+
+== Authors
+The main idea author is Pawel Foremski <[EMAIL PROTECTED]>.
+Implementation details and implementation itself was written by
+Dawid Ciezarkiewicz <[EMAIL PR
On Thursday, 6 July 2006 13:15, Ingo Oeser wrote:
> First of all:
> You should not implemented "--vlan-target".
> Always return EBT_CONTINUE. That saves a lot of (duplicated) code
> (you can express the same using some more rules) while keeping
> the same flexibility leve
14 matches
Mail list logo
