Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*More\s+IPSEC\s+trouble\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*More\s+IPSEC\s+trouble\s*$/: 26 ]

Total 26 documents matching your query.

1. More IPSEC trouble (score: 1): Author: <hno@xxxxxxxxxxxxxxx>; Date: Thu, 10 Mar 2005 12:45:29 +0000 (GMT); Unfortunately I've found another IPSEC kernel bug (2.6.10): Running IPSEC in IPv4 tunnel mode - obviously the packets grow in size when encrypted and when I send a packet that grows to > MTU size whe; /archives/netdev/2005-03/msg00651.html (9,485 bytes)
2. Re: More IPSEC trouble (score: 1): Author: eve.iribarne@xxxxxxxxxxxxxxxxxxxxx>; Date: Thu, 10 Mar 2005 16:01:25 +0100; When the stack check the mtu for this packet, it doesn't know the size of the overhead. So the total length of the packet don't include the size of the esp or ah header. The same bug appears when you; /archives/netdev/2005-03/msg00657.html (11,524 bytes)
3. Re: More IPSEC trouble (score: 1): Author: aka Dino) BOIE" <util@xxxxxxxxxxxxxxx>; Date: Thu, 10 Mar 2005 16:32:01 +0000 (GMT); On Thu, 10 Mar 2005, Nicolas DICHTEL wrote: When the stack check the mtu for this packet, it doesn't know the size of the overhead. So the total length of the packet don't include the size of the esp; /archives/netdev/2005-03/msg00662.html (9,060 bytes)
4. Re: More IPSEC trouble (score: 1): Author: nhorman@xxxxxxxxxx; Date: Thu, 10 Mar 2005 18:15:54 +0100; Steve Hill wrote: Unfortunately I've found another IPSEC kernel bug (2.6.10): Increasing the packet size by 1 byte would obviously require fragmentation of the encrypted packet and causes the machine; /archives/netdev/2005-03/msg00663.html (8,703 bytes)
5. Re: More IPSEC trouble (score: 1): Author: r <shemminger@xxxxxxxx>; Date: Fri, 11 Mar 2005 12:17:46 +1100; What does CTRL-SCROLLLOCK or SysRq tell us? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PG; /archives/netdev/2005-03/msg00701.html (9,273 bytes)
6. ipv4 interaction weirdness (score: 1): Author: کژ <yoshfuji@xxxxxxxxxxxxxx>; Date: Fri, 11 Mar 2005 15:05:28 +0000 (GMT); On Fri, 11 Mar 2005, Herbert Xu wrote: What does CTRL-SCROLLLOCK or SysRq tell us? The kernel locks up solid - no SysRq, capslock/numlock lights don't toggle when hitting the keys - completely dead.; /archives/netdev/2005-03/msg00774.html (10,413 bytes)
7. arded frame has VLAN-header (score: 1): Author: xxxxx>; Date: Sat, 12 Mar 2005 01:00:37 +0100; Steve Hill wrote: This was a configuration mistake on my part and admittedly it shouldn't work properly - however, it triggered a kernel bug: sending a packet with the DF flag set which will grow to; /archives/netdev/2005-03/msg00782.html (11,539 bytes)
8. ader (score: 1): Author: xxx>; Date: Sat, 12 Mar 2005 01:11:37 +0100; Patrick McHardy wrote: Steve Hill wrote: This was a configuration mistake on my part and admittedly it shouldn't work properly - however, it triggered a kernel bug: sending a packet with the DF flag; /archives/netdev/2005-03/msg00783.html (11,823 bytes)
9. uble (score: 1): Author: xxx>; Date: Sat, 12 Mar 2005 01:13:23 +0100; Patrick McHardy wrote: Patrick McHardy wrote: Steve Hill wrote: This was a configuration mistake on my part and admittedly it shouldn't work properly - however, it triggered a kernel bug: sending a p; /archives/netdev/2005-03/msg00784.html (13,068 bytes)
10. more broken than in 2.6.10 (score: 1): Author: dy <kaber@xxxxxxxxx>; Date: Sat, 12 Mar 2005 12:35:15 +1100; Good catch. However let's try to avoid spreading lock/unlock calls around if possible. Since tunnel_check_size only looks at the state to determine whether it's tunnel mode, it doesn't need to hold t; /archives/netdev/2005-03/msg00788.html (9,931 bytes)
11. 6.10 (score: 1): Author: xxxxxxx>; Date: Sat, 12 Mar 2005 03:35:46 +0100; Herbert Xu wrote: Good catch. However let's try to avoid spreading lock/unlock calls around if possible. Since tunnel_check_size only looks at the state to determine whether it's tunnel mode, it does; /archives/netdev/2005-03/msg00789.html (9,288 bytes)
12. d route element to xfrm_dst (score: 1): Author: enberg@xxxxxxxxx>; Date: Mon, 14 Mar 2005 12:12:27 +0000 (GMT); On Sat, 12 Mar 2005, Herbert Xu wrote: Since tunnel_check_size only looks at the state to determine whether it's tunnel mode, it doesn't need to hold the lock at all. Signed-off-by: Herbert Xu <herbe; /archives/netdev/2005-03/msg00828.html (9,356 bytes)
13. TCP_DEBUG disabled in tcp.h (score: 1): Author: avid S. Miller" <davem@xxxxxxxxxxxxx>; Date: Mon, 14 Mar 2005 21:39:15 -0800; I've applied Herbert's patch, thanks guys.; /archives/netdev/2005-03/msg00887.html (9,331 bytes)
14. More IPSEC trouble (score: 1): Author: Steve Hill <steve@xxxxxxxxxxxxxxxxxxx>; Date: Thu, 10 Mar 2005 12:45:29 +0000 (GMT); Unfortunately I've found another IPSEC kernel bug (2.6.10): Running IPSEC in IPv4 tunnel mode - obviously the packets grow in size when encrypted and when I send a packet that grows to > MTU size whe; /archives/netdev/2005-03/msg02574.html (9,701 bytes)
15. Re: More IPSEC trouble (score: 1): Author: Nicolas DICHTEL <nicolas.dichtel@xxxxxxxxx>; Date: Thu, 10 Mar 2005 16:01:25 +0100; When the stack check the mtu for this packet, it doesn't know the size of the overhead. So the total length of the packet don't include the size of the esp or ah header. The same bug appears when you; /archives/netdev/2005-03/msg02580.html (11,762 bytes)
16. Re: More IPSEC trouble (score: 1): Author: Steve Hill <steve@xxxxxxxxxxxxxxxxxxx>; Date: Thu, 10 Mar 2005 16:32:01 +0000 (GMT); When the stack check the mtu for this packet, it doesn't know the size of the overhead. So the total length of the packet don't include the size of the esp or ah header. The same bug appears when yo; /archives/netdev/2005-03/msg02585.html (9,104 bytes)
17. Re: More IPSEC trouble (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Thu, 10 Mar 2005 18:15:54 +0100; Unfortunately I've found another IPSEC kernel bug (2.6.10): Increasing the packet size by 1 byte would obviously require fragmentation of the encrypted packet and causes the machine to lock up. Doesn; /archives/netdev/2005-03/msg02586.html (8,769 bytes)
18. Re: More IPSEC trouble (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 11 Mar 2005 12:17:46 +1100; What does CTRL-SCROLLLOCK or SysRq tell us? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PG; /archives/netdev/2005-03/msg02624.html (9,359 bytes)
19. Re: More IPSEC trouble (score: 1): Author: Steve Hill <steve@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 11 Mar 2005 15:05:28 +0000 (GMT); What does CTRL-SCROLLLOCK or SysRq tell us? The kernel locks up solid - no SysRq, capslock/numlock lights don't toggle when hitting the keys - completely dead. I've managed to work out what causes i; /archives/netdev/2005-03/msg02697.html (10,711 bytes)
20. Re: More IPSEC trouble (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Sat, 12 Mar 2005 01:00:37 +0100; Steve Hill wrote: This was a configuration mistake on my part and admittedly it shouldn't work properly - however, it triggered a kernel bug: sending a packet with the DF flag set which will grow to; /archives/netdev/2005-03/msg02705.html (11,701 bytes)

Current List: 1 - 20
Page: [1] [2]