From: Dave Jones <[EMAIL PROTECTED]>
Date: Sun, 2 Apr 2006 23:31:34 -0500
> This breaks SELinux compilation.
> security/selinux/xfrm.c: In function 'selinux_socket_getpeer_dgram':
> security/selinux/xfrm.c:284: error: 'struct sec_path' has no member named 'x'
> security/selinux/xfrm.c: In function
On Monday 03 Apr 2006 3:18 am, Roland Dreier wrote:
> - Please try to use software to post your patches so that they end up
>nicely threaded via In-Reply-To: headers. And also try to plan
>ahead enough so that you don't end up things like "[PATCH 1.2/9]".
>Finally, please try to give
Thanks, Andi.
We are working on reducing this space to get rid of as many pages as possible.
We'll also work on making some of the pages dyanamic.
-Amit
On Sunday 02 Apr 2006 6:11 pm, Andi Kleen wrote:
> > +/* 128 Meg of memory */
> > +DPRINTK(1, INFO, "ioremap from %lx a size of
On Sun, Apr 02, 2006 at 08:14:06PM +, Linux Kernel wrote:
> commit e695633e21ffb6a443a8c2f8b3f095c7f1a48eb0
> tree 52a679683a11eb42ec5888309a82ec5811a21e03
> parent 15901dc93fa4253bfb3661644ecad67c2e83213c
> author Herbert Xu <[EMAIL PROTECTED]> Sat, 01 Apr 2006 16:52:46 -0800
> committer
jamal <[EMAIL PROTECTED]> writes:
> Ok, its a little more than grat arp (which i assumed it was). However,
> the cause-fatale given in section 4 for why you wanna broadcast does
> sound very lame. To quote: You do this in case "two disjoint network
> links are joined".
It isn't quite a gratuitous
On Mon, Apr 03, 2006 at 01:11:46AM +0200, Patrick McHardy wrote:
> Thomas Zeitlhofer wrote:
> > On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote:
> >
> >>>Doing the same on 2.6.15.x shows:
> >>>
> >>> 1) on tap1: fragmented packets
> >>> 2) on br0: the defragmented packet (connect
Thomas Zeitlhofer wrote:
> On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote:
>
>>>Doing the same on 2.6.15.x shows:
>>>
>>> 1) on tap1: fragmented packets
>>> 2) on br0: the defragmented packet (connection tracking)
>>> 3) on eth1: fragmented packets
>>
>>Are you sure this is cor
On Sun, Apr 02, 2006 at 09:19:30PM +0200, Patrick McHardy wrote:
> Thomas Zeitlhofer wrote:
> > I have set up a bridge with two ports:
> >
> > # brctl show br0
> > bridge name bridge id STP enabled interfaces
> > br0 8000.21f23d58 no eth1
>
On Sun, Apr 02, 2006 at 11:49:16PM +0200, Patrick McHardy wrote:
>
> [NETFILTER]: Fix fragmentation issues with bridge netfilter
>
> The conntrack code doesn't do re-fragmentation of defragmented packets
> anymore but relies on fragmentation in the IP layer. Purely bridged
> packets don't pass thr
Herbert Xu wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> 1) on tap1: fragmented packets
>> 2) on br0: the defragmented packet (connection tracking)
>> 3) on eth1: no packet!?
>
>
> Please show us the exact tcpdump result on br0.
I already sent him this patch for testing.
[NETFILTER]: F
Just a couple of very general comments:
- The kernel style is to avoid "//" comments like
> +//reset abyte_cnt and dummy_byte_cnt
please replace all of this with comments like
/* single-line comment */
or
/*
* multi-line comments
* look like t
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> 1) on tap1: fragmented packets
> 2) on br0: the defragmented packet (connection tracking)
> 3) on eth1: no packet!?
Please show us the exact tcpdump result on br0.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Thanks a lot for the reply Herbert.
> Is there a way to tell netkey to frag packets like klips
> ignoring the DF bit?
Thinking about this again, there is actually a bug in our various tunneling
implementations when the user chooses to disable PMTU disc
On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote:
> >
> > Sam, I am now seeing this error (not a WARNING like the previous ones were):
> >
> > drivers/net/typhoon.c:137: error: version causes a section type conflict
> >
> > but I don't see a real problem in the driver source file.
>
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
> host I got this result:
>
> PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
> 1480 bytes from 172.16.1.52: icmp_seq=1 ttl=62 time=74.1 ms
>
On Sun, Apr 02, 2006 at 05:17:07PM +0200, Ivo van Doorn wrote:
> I may have missed an announcement on this, but has the wireless-dev
> tree containing the recent dscape stack + drivers already been published?
> It seems the dscape stack including the drivers for it have been removed
> from the wir
Hi,
> Does this mean that we have abandoned the dscape code? No. I think we
> need the capabilities provided by the dscape code as well. I just don't
> think we can make progress as quickly with the dscape code as we can
> this way.
>
> So what happens to dscape? I will publish a wireless-dev
> +/* 128 Meg of memory */
> +DPRINTK(1, INFO, "ioremap from %lx a size of %lx\n", mem_base,
> +mem_len);
> +mem_ptr = ioremap(mem_base, NetXen_PCI_MAPSIZE_BYTES);
Eating 128MB of ioremap space will make lots of 32bit systems unhappy.
If you car
On Saturday 01 April 2006 15:50, Linsys Contractor Amit S. Kale wrote:
Not a full review, just what I noticed from a quick read.
> +static int
> +netxen_loopback_test(struct net_device *netdev, int fint, void *ptr)
[... lots of self test code snipped ...]
Isn't that a bit too much self test inf
Hi Dave:
This patch moves the sending of ICMP messages when there are no IPv4/IPv6
tunnels present to tunnel4/tunnel6 respectively. Please note that for now
if xfrm4_tunnel/xfrm6_tunnel is loaded then no ICMP messages will ever be
sent. This is similar to how we handle AH/ESP/IPCOMP.
This move
20 matches
Mail list logo
