, an skb_over_panic() was observed with via-velocity.
This removes the module parameter as it does not work in it's
current state, and should be implemented via NETIF_F_RXALL if needed.
Suggested-by: Francois Romieu <rom...@fr.zoreil.com>
Signed-off-by: Timo Teräs <timo.te...@iki.fi>
Frag needed should be sent only if the inner header asked
to not fragment. Currently fragmentation is broken if the
tunnel has df set. The tunnel's df needs to be still checked
to update internally the pmtu cache.
This got broken in commit 23a3647bc4f93bac and this fixes
the pmtu check back to
it, and this commit fixes
the ipv4 df check back to the way it was.
Fixes: 23a3647bc4f93bac (ip_tunnels: Use skb-len to PMTU check.)
Cc: Pravin B Shelar pshe...@nicira.com
Signed-off-by: Timo Teräs timo.te...@iki.fi
---
Should go to -stable queues (3.12.y and newer).
v2: revised commit message wording
Change xfrm_policy and xfrm_state walking algorithm from O(n^2) to O(n).
This is achieved adding the entries to one more list which is used
solely for walking the entries.
This also fixes some races where the dump can have duplicate or missing
entries when the SPD/SADB is modified during an
Change xfrm_policy and xfrm_state walking algorithm from O(n^2) to O(n).
This is achieved adding the entries to one more list which is used
solely for walking the entries.
This also fixes some races where the dump can have duplicate or missing
entries when the SPD/SADB is modified during an
Change xfrm_policy and xfrm_state walking algorithm from O(n^2) to O(n).
This is achieved adding the entries to one more list which is used
solely for walking the entries.
This also fixes some races where the dump can have duplicate or missing
entries when the SPD/SADB is modified during an
David Miller wrote:
Doing anything other than life support bug fixes for AF_KEY is
inappropriate.
Yes. I thought my patch would qualify as life support bug fix.
Currently racoon fails to work if there are too many SPDs or SAs
because the kernel cannot handle the dump request properly. And
this
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 10:11:17 +0200
I thought my patch would qualify as life support bug fix.
Currently racoon fails to work if there are too many SPDs or SAs
because the kernel cannot handle the dump request properly. And this
is
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 11:20:42 +0200
Where as the pfkey bug fix is non-intrusive and helps all
legacy applications still using af_key by _fixing a bug in
kernel_.
It's not a bug. You're fixing a speed issue, not a crash
or a case
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 11:38:13 +0200
The af_key issue is that in big dumps you get only first X
entries. The rest of the entries are dropped because the
socket receive buffer goes full. You get data corruption:
missing entries.
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 12:01:17 +0200
David Miller wrote:
This is an inherent aspect of AF_KEY (and what it was
derived from, BSD routing sockets).
Yes, this is the way BSD does it.
It has to provide dumps atomically, and if there
Herbert Xu wrote:
On Thu, Jan 17, 2008 at 07:54:32AM +0200, Timo Teräs wrote:
Racoon doesn't use pfkey dumping as far as I know.
ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
make it use netlink; it relies heavily all around the code to pfkey
structs. It also runs
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 13:00:09 +0200
IMHO, it's a lot better then losing 50% of entries and the end
of sequence message on big dumps. SPD and SADB are not that
volatile; in most of the cases the dump would be as good as an
atomic one.
Herbert Xu wrote:
On Thu, Jan 17, 2008 at 07:42:30AM -0500, jamal wrote:
Looking at the pfkey RFC one more time, heres a funny quote:
The dump message is used for debugging
purposes only and is not intended for production use.
In fact it goes much further:
Support for the dump
Herbert Xu wrote:
On Thu, Jan 17, 2008 at 03:31:14PM +0200, Timo Teräs wrote:
I guess the idea was that application should know about the SAs it
created. Though a SA dump needs to be done if you want to check
for existing entries (created by other processes, or if you are
recovering from
jamal wrote:
On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
I tried to address all these problems, and added the xfrm_policy
and xfrm_state structure to a new linked list that is used solely
for dumping. This way the dumps can be done in O(n) and have an
iterator point to them. I also
jamal wrote:
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
No. I'm not creating second copies of the SADB/SPD entries. The entries
are just added to one more list.
Ah, sorry - yes, that sounds reasonable.
So what happens if i delete an entry; does it get removed from the list
Herbert Xu wrote:
jamal [EMAIL PROTECTED] wrote:
There are two issues that are inter-mingled in there. The most important
is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 08:27:14 +0200
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable. Though netlink is definitely
more robust and extensive.
The RFCs say
Hi all,
The problem with IPsec SP/SA dumping is that they don't work well with large
SPD/SADB:s. In netlink the dumping code is O(n^2) and can miss some
entries/dump duplicates if the DB is changed between the recv() calls to read
the dump entries. This is due to the entry index counting done
From: Timo Teras [EMAIL PROTECTED]
mac_header update in ipgre_recv() was incorrectly changed to
skb_reset_mac_header() when it was introduced.
Signed-off-by: Timo Teras [EMAIL PROTECTED]
---
This replaces my earlier patch titled ip_gre: use skb-{mac,
network}_header consistently. Apparently I
From: Timo Teras [EMAIL PROTECTED]
Make both send and receive paths use consistently skb-*_header:
mac_header = outer IPv4 header
network_header = encapsulated packet (e.g. inner IPv4 header)
Signed-off-by: Timo Teras [EMAIL PROTECTED]
---
Currently in send path:
network_header = outer
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
Signed-off-by: Timo Teras [EMAIL PROTECTED]
---
This is useful for
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
This is required to implement properly NHRP over GRE tunnel.
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
This is required to implement properly NHRP over GRE tunnel.
Hi,
Alexey Kuznetsov wrote:
The only dubious case is when next hop is set using routing tables.
But code in ipgre_tunnel_xmit() is ready to accept this situation,
it checks for zero destination address and fixes it when it is able to.
Nevertheless, it does not work.
Another thoughts?
Could
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
Signed-off-by: Timo Teras [EMAIL PROTECTED]
---
This is useful for
When GRE tunnel is in NBMA mode, this patch allows an application to use
a PF_PACKET socket to:
- send a packet to specific NBMA address with sendto()
- use recvfrom() to receive packet and check which NBMA address it came from
This is required to implement properly NHRP over GRE tunnel.
28 matches
Mail list logo
