Hi Folks,
I have a 3com gigE nic and have used the sk98lin driver for quite a while.
I recently switched to the skge driver, and now I'm hitting a BUG in an
iptables rule that previously did not happen with sk98lin but does happen
with skge:
the BUG is ipv4/netfilter/ipt_TCPMSS.c:190
on this cod
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo)
Date: Tue, 16 Aug 2005 02:24:14 -0300
> Please consider pulling from:
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
>
> Please let me know about anything you may want reworked.
Looks good, pulled.
-
To u
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Please let me know about anything you may want reworked.
Best Regards,
- Arnaldo
tree 7f65f8f8a8cf5b2f66089c9c039f2b032d964bab
parent f3835475
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 16 Aug 2005 12:02:31 +1000
> I have a suggestion as to where fclone_ref
> should be though. I'd put it outside sk_buff. So when you
> allocate sk_buff * 2 for fast clones, make that
> sk_buff * 2 + atomic_t. Then you will only have to carry
> it a
On Mon, Aug 15, 2005 at 05:10:41PM -0700, David S. Miller wrote:
>
> So what do folks think we should do? I'm inclined to put
> this in first, as-is, then if we can get the skb->users
> variant functional we can add that in as a follow-on
> patch.
Fine by me. I have a suggestion as to where fcl
Em Mon, Aug 15, 2005 at 09:51:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> Hi Stephen,
>
> Please consider applying.
>
> One thing I think we should address is to show the name of the
> protocol in listings where sockets of more than one protocol type are
> being displayed, but th
Hi Stephen,
Please consider applying.
One thing I think we should address is to show the name of the
protocol in listings where sockets of more than one protocol type are
being displayed, but this patch is a good start, I guess.
Best Regards,
- Arnaldo
d
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 15:45:00 -0700 (PDT)
> Ok, this scheme doesn't work as-is.
FWIW the fclone_ref version works perfectly fine, and
I'm running this right now. I'm including it below
against current net-2.6.14 for reference.
So what do folks think
Ok, this scheme doesn't work as-is.
We never run the __kfree_skb() actions on the parent
SKB if the child drops the parent SKB users count to zero.
This means we don't release the DST and other objects
referenced in the parent SKB. We also never release the
SKB memory in this case either.
-
To
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 16:43:57 +0200
> Dave, I found another problem in the earlier patch of mine,
> when we free the clone portion and the parent is still alive
> we used to set UNAVAIL in the else branch but at this point
> the skb could have been gone alre
> It does help 16 bits :-) Better than nothing.
16bits is so poor that any "secure" algorithms using it would
just give a false sense of security.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Mon, Aug 15, 2005 at 01:43:23PM -0700, David S. Miller wrote:
> But that's still going to be 48-bits less protection than
> TCP gives you. TCP has a sequence number (32-bits) and
> a timestamp (another 32-bits) as well as the saddr/daddr/
> sport/dport 48-bit tuple.
I hate it as well hehe. A
From: bert hubert <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 22:38:44 +0200
> Yes it does. Nameservers also need to send outgoing packets. The DNS
> 'keyspace' for response spoofing is a sad 16 bits, there are two bytes
> available in the DNS packet. By randomising the source port, another 16 bits
Dave,
Thanks for the prompt reply, much appreciated.
On Mon, Aug 15, 2005 at 01:25:10PM -0700, David S. Miller wrote:
> UDP does not have the same kind of vulnerability from port
> number guessing. In fact, UDP is extremely vulnerable for
Yes it does. Nameservers also need to send outgoing pa
From: bert hubert <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 22:16:49 +0200
> Currently socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) delivers the exact same
> source port each time I run it, 32776. The second invocation, without
> closing the first socket, generates 32777.
>
> This strikes me as being
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 16:05:49 +0200
> It was intentional, but I agree the other way around would be more
> consistent. If you want to send a patch, go ahead, otherwise I'll
> put it on my cleanup-list. Not allowing user sockets for unregistered
> protoco
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Mon, 15 Aug 2005 13:43:39 +0400
> On Mon, Aug 15, 2005 at 11:06:27AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
> > Evgeniy Polyakov wrote:
> > >it's not Dave's bug, all this changes force compiler to scream, which
> > >thrusts forward.
>
Description: Use schedule_timeout_interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
---
drivers/net/8139cp.c |3 -
drivers/net/hp100.c | 48 ++--
Description: Use schedule_timeout_{,un}interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size. Also use
human-time conversion functions instead of hard-coded division to avoid
rounding issues.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
---
net/core/p
On 8/12/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Dimitris Michailidis <[EMAIL PROTECTED]>
> Date: Fri, 12 Aug 2005 10:00:12 -0700
>
> > On 8/12/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> > > This would mean that every time we wish to change the data structures
> > > and interfa
* David S. Miller <[EMAIL PROTECTED]> 2005-08-14 17:56
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 15 Aug 2005 10:42:44 +1000
>
> > Well I don't think I understand the new skb->user solution yet :)
> >
> > For a start, skb->users will prevent the skb->data area from being
> > freed as wel
Thomas Graf wrote:
> You don't undo the allocations of __netlink_create if the
> kmalloc for nlk->groups fails. So my question is if this is
> intended and you really want to rely on the caller to invoke
> sock_release() to free the sk again or whether it might be
> worth to follow the rule of leav
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-14 15:30
> Thomas Graf wrote:
> > * Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:36
> >
> >>[NETLINK]: Support dynamic number of multicast groups per netlink family
> >>
> >>Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
> >>
> >>- if ((err
On Mon, Aug 15, 2005 at 11:06:27AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >it's not Dave's bug, all this changes force compiler to scream, which
> >thrusts forward.
>
> I don't get any compiler warnings with gcc-4.0.1 on x86 and amd64,
> so could you please
Evgeniy Polyakov wrote:
it's not Dave's bug, all this changes force compiler to scream, which thrusts
forward.
I don't get any compiler warnings with gcc-4.0.1 on x86 and amd64,
so could you please be more specific?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the b
On Mon, Aug 15, 2005 at 10:16:19AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >>+ nlk->groups[0] = (nlk->groups[0] & ~0xUL) |
> >>nladdr->nl_groups; netlink_table_ungrab();
> >
> >
> >I have some doubt about 64bit platforms.
>
> We want to replace the
Evgeniy Polyakov wrote:
+ nlk->groups[0] = (nlk->groups[0] & ~0xUL) | nladdr->nl_groups;
netlink_table_ungrab();
I have some doubt about 64bit platforms.
We want to replace the lower 32 bit. What are the doubts you're haveing?
return 0;
@@ -590,7 +619,7 @@ static int netli
On Mon, Aug 15, 2005 at 09:45:22AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> David S. Miller wrote:
> >I applied patches 1 -> 7, but I had to stop after that.
> >
> >This patch here will break netlink on my workstation :-)
> >
> >These "u32" tricks with nlk->groups[0] will not work on
>
David S. Miller wrote:
I applied patches 1 -> 7, but I had to stop after that.
This patch here will break netlink on my workstation :-)
These "u32" tricks with nlk->groups[0] will not work on
big-endian 64-bit. If unsigned long is 64-bit, you end
up accessing bits 32-63 of nlk->groups[0] in so
29 matches
Mail list logo
