ash table limited to 64K is not a good
thing.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@v
's also not actually used yet.
Well if my patch is too complex then sure we can look at coming up
with a simpler fix but I think we need something that does not let
you add unlimited entries to af_netlink.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP K
On Fri, Apr 24, 2015 at 01:30:00PM +0800, Herbert Xu wrote:
> Now we just need to figre out whether we're still OK with RFC4543.
Looks like we're OK here too as the diagram in section 3.5 says
that the IV should be included in the AAD.
So we're all good!
Thanks,
--
Email: Her
the IV in the authentication tag.
In fact after reviewing the two relevant RFCs (4106/4309) it seems
that we are correct after all since they explicitly exclude the IV
from the AAD.
Now we just need to figre out whether we're still OK with RFC4543.
Sorry for the false alarm.
Cheers,
--
Email: He
OMEM on insertion.
As allowing >100% utilisation is potentially dangerous, the name
contains the word insecure.
Note that the cap is not a hard limit. This is done for performance
reasons as enforcing a hard limit will result in use of atomic ops
that are heavier than the ones we currently use.
ion, such that users notice that they
> use a broken version.
If we are going to do a warning I think the place to do it would
be in xfrm_algo.c. We could add an insecure/warning flag and if
then print a warning if said algorithm is used.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondo
section 2). But really it's quite obvious. If you
don't authenticate the IV, then I can easily inject random crap
into your network by changing the IV.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
on
or not.
AFAIK GCM itself is implemented correctly. It's only the IPsec
wrapper around it (rfc4106 in particular) that's broken.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from thi
hrough
our implementation or by one that is identical to us.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a m
e RFC correctly. The existing templates will be
retained so that current users aren't broken by the fix.
Once the kernel side is complete we could then get the user-space
implementors to update their tools to request for the new v2
templates.
Comments?
Cheers,
--
Email: Herbert Xu
Home
if walk is not empty
>
> Signed-off-by: Li RongQing
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
by list_move_tail()
>
> Fixes: 12a169e7d8f(ipsec: Put dumpers on the dump list)
> Cc: Herbert Xu
> Signed-off-by: Li RongQing
This is not a bug fix but an optimisation. The walker entries are
all marked as dead and will be skipped by the loop.
However, I don't see anything wr
gt; Fixes: ccd57b1bd324 ("rhashtable: Add immediate rehash during insertion")
> Signed-off-by: Thomas Graf
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this lis
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
crypto/testmgr.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 18b7d49..d463978 100644
--- a/crypto/testmgr.c
+++ b/crypto
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
net/mac80211/aes_ccm.c |3 +--
net/mac80211/aes_gcm.c |3 +--
net/mac80211/aes_gmac.c |2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/mac80211
blkcipher in addition to aead.
Signed-off-by: Herbert Xu
---
net/mac802154/llsec.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index dcf7395..3ccf1e9 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -17,8
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
crypto/tcrypt.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 22cdd61..2bff613 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
All implementers of AEAD should include crypto/internal/aead.h
instead of include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
arch/arm64/crypto/aes-ce-ccm-glue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c
b/arch/arm64/crypto
All users of AEAD should include crypto/aead.h instead of
include/linux/crypto.h.
Signed-off-by: Herbert Xu
---
crypto/algif_aead.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 00a6fe1..53702e9 100644
--- a/crypto/algif_aead.c
+++ b
to push the last two patches
through my tree as the new AEAD interface would depend on them.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev&quo
-EBUSY.
>
> Fixes: ccd57b1bd324 ("rhashtable: Add immediate rehash during insertion")
> Signed-off-by: Thomas Graf
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscri
gt; Fixes: ccd57b1bd324 ("rhashtable: Add immediate rehash during insertion")
> Signed-off-by: Thomas Graf
Good catch. But I think this call should happen in
rhashtable_insert_rehash since it's on the slow-path.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.or
On Thu, Apr 16, 2015 at 07:40:30PM -0700, Alexei Starovoitov wrote:
> On Fri, Apr 17, 2015 at 10:15:01AM +0800, Herbert Xu wrote:
> > > seems the cleaner fix will be to push skb->mac_len instead?
> >
> > No skb->mac_len is the same as skb2->dev->hard_
On Thu, Apr 16, 2015 at 06:34:02PM -0700, Alexei Starovoitov wrote:
> On Fri, Apr 17, 2015 at 09:02:16AM +0800, Herbert Xu wrote:
> > @@ -105,7 +105,7 @@ static void ri_tasklet(unsigned long dev)
> > if (from & AT_EGRESS) {
> >
on the hard header length
of ifb. This assumes that the original packet actually has enough
header for that so checks have been added to that effect.
Signed-off-by: Herbert Xu
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 34f846b..1256d26 100644
--- a/drivers/net/ifb.c
+++ b/drivers
You should read Dave's other email where he gives you an obvious
solution. If you have to modify the skb then you don't have to
worry about the original fragments.
But if you only read the skb then don't linearise it completely
and keep the original fragments.
Cheers,
dodgy :)
---8<---
This patch reverts commit b8fb4e0648a2ab3734140342002f68fb0c7d1602
because the secmark must be preserved even when a packet crosses
namespace boundaries. The reason is that security labels apply to
the system as a whole and is not per-namespace.
Signed-off-by: Herbert Xu
diff
cross a namespace boundary.
But I will send a patch.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
o instead of directly manipulating the content of the skb you
would so so through helpers and the helpers can then try to do
sensible things with the fragments.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To
s
in frag_list and then process the overall skb as a unit in netfilter.
On output we simply fragment according to the original frag_list.
The only thing to watch out for is to eliminate anything in the
middle that tries to linearise the skb.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apa
ion
device rendering such hints incorrect.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vge
On Wed, Apr 15, 2015 at 05:41:26PM +0200, Nicolas Dichtel wrote:
> Le 15/04/2015 15:57, Herbert Xu a écrit :
> >On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
> [snip]
> >Subject: skbuff: Do not scrub skb mark within the same name space
On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
>
> Yes this is better. I'm currently auditing all the other bits
> that are cleared to see if there is anything else that we should
> preserve for tunneling.
OK the only other thing that we may wish to preserve is se
On Wed, Apr 15, 2015 at 12:28:46PM +0200, Nicolas Dichtel wrote:
>
> Here is the thread about the mark:
> http://thread.gmane.org/gmane.linux.network/246876/focus=274528
Thanks but I don't see any justification for breaking the mark
feature.
Cheers,
--
Email: Herbert Xu
H
On Wed, Apr 15, 2015 at 12:20:42PM +0200, Nicolas Dichtel wrote:
> Le 15/04/2015 12:01, Herbert Xu a écrit :
> >The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
> >harmonize cleanup done on skb on rx path") broke anyone trying to
> >use netfilter marki
On Wed, Apr 15, 2015 at 06:01:07PM +0800, Herbert Xu wrote:
> The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
> harmonize cleanup done on skb on rx path") broke anyone trying to
> use netfilter marking across IPv4 tunnels. As the commit message
> did not give
th), I can only assume that it was a typo.
This patch reverts that change.
Signed-off-by: Herbert Xu
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 88c386c..709e711 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -54,7 +54,8 @@ int iptunnel_x
inate other variables?
This is all very puzzling since the patch in question shouldn't
change an RX load at all.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gon
On Fri, Feb 15, 2008 at 12:05:32AM -0800, David Stevens wrote:
>
> For the future, maybe we should rename that, or reverse
> the sense of it (in v4 as well). :-)
Yeah it really should be called local_mayfrag.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
ocal_df test when forward-porting this
patch so it actually makes things worse by never fragmenting at
all.
Thanks to David Stevens for testing and reporting this bug.
Bill Fink pointed out that the local_df setting is also the wrong
way around.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]
n ip6_fragment
I managed to reverse the local_df test when forward-porting this
patch so it actually makes things worse by never fragmenting at
all.
Thanks to David Stevens for testing and reporting this bug.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at
it
work for the IPsec host case.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pub
y much what I've got (but I'm on 32-bit still).
Does every packet from A trigger the crash?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.a
ut that is fine for the purpose that this variable
serves. All it does is to make sure that extant flow objects get
killed at some point after the increment. There is absolutely no
requirement that the killing be immediate or synchronised.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email
tp://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
be really helpful in tracking it down.
Could you show me the exact policies/SAs of the tunnel involved
in the crash?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://go
h one out of A and B is running 2.6.24?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the
pe < 0 in there, but
I think you'll probably be able to explain it much better than I can
looking in from the outside so if you have a patch... :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana
But the encap_type argument is reused to
indicate async resumption. That is, if we enter with encap_type < 0,
it means that we're resuming a previous operation and seq.input has
therefore been set by the previous xfrm_input call.
Cheers,
--
Visit Openswan at http://www.openswan.org
the input sequence number which
is big-endian. This patch fixes it by giving the input sequence number
its own member in the xfrm_skb_cb structure.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL
umstances change and there is not really a good way to affect a socket
> after it was created.
You don't need to change the socket if you just call skb_gso_segment
when necessary.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED
e GSO.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
On Sat, Feb 02, 2008 at 11:53:29PM +0200, Ilpo Järvinen wrote:
>
> Once again, one of this kind tries to creep in.
>
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Heh, Adrian got there first :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
On Sat, Feb 02, 2008 at 11:16:35PM +0200, Adrian Bunk wrote:
> A bug every C programmer makes at some point in time...
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Good catch!
Acked-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswa
from my 64-bit machines.
How long have you been using IPComp in the past and what was the
last kernel version which was stable with IPComp?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~
;
> Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
Acked-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.
by entering IPPROTO_IP (== 0) instead of
IPPROTO_IPIP (== 4). This broke the reception of incompressible
packets.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home
reading from a stale ipch pointer which
doesn't work very well.
This patch moves the reading up so that we get the correct nexthdr
value.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PRO
AG]: Fix inet_diag_lock_handler error path
[EMAIL PROTECTED]
that Arnaldo posted recently.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~
identified by its name and the ICV length.
For the purposes of matching algorithms in xfrm_tmpl structures, combined
mode algorithms are occupy the same name space as encryption algorithms.
This is in line with how they are negotiated using IKE.
Signed-off-by: Herbert Xu <[EMAIL PROTEC
[IPSEC]: Allow async algorithms
Now that ESP uses authenc we can turn on the support for async algorithms
in IPsec.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
net/xfrm/xfrm_algo.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c
[IPSEC]: Use crypto_aead and authenc in ESP
This patch converts ESP to use the crypto_aead interface and in particular
the authenc algorithm. This lays the foundations for future support of
combined mode algorithms.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
include/net/esp.h
Hi Dave:
I've rebased the IPsec AEAD/async patches for the current net-2.6.25
tree.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herb
the update of skb->truesize to prevent this.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.a
o!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
append_data
and ip_append_page.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubke
e the same page gets away with no charge
at all.
This bug was exposed by the UDP accounting patch.
This patch also fixes a similar bug in ip_append_page spotted by you :)
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
just "hdr_len" rather than "gso_hdr_len"?
Sounds fine to me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
T
nothing to do with GSO as you
also need it for SG with large MTUs.
I think this is more flexible than the Xen approach where this is
essentially hard-coded to 64 bytes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: htt
be used ESP.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev&
ing anywhere at all.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe
for the dump message MAY be discontinued in future versions
of PF_KEY. Key management applications MUST NOT depend on this
message for basic operation.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor
ucts. It also runs on BSD so we cannot rip pfkey away; adding a
> layer to work with both pfkey and netlink would be doable, but just a
> lot of work.
Sure racoon uses pfkey but the question is does it use pfkey dumping?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert X
enswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMA
ere, since there is a
> cooked interface for UDP output that counts the common use, at least.
Fair enough. How about moving this code back into icmp.c and just
add a new count call in raw.c? The push pending function is used on
the UDP fast path so the leaner it is the better.
Thanks,
--
Vi
r since neither is portable. So we
should discourage people from using af_key wherever possible.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~
Having it there means that we count raw socket ICMP packets
too. But we don't do that for any other protocol, e.g., raw UDP packets
don't get counted.
So was the inclusion of raw ICMP packets intentional?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
that comes with it should be borne by the company and not the
community.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To u
gso_type |= SKB_GSO_DODGY;
>skb_shinfo(skb)->gso_segs = 0;
> + skb_set_transport_header(skb, hdr->gso_hdr_len);
Why do we need this? When receiving GSO packets from an untrusted
source the network stack will fill in the transport header offset
after verifying that the headers are san
much non-existing.
Make sure you haven't switched between SLAB/SLUB while testing this.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pub
[EMAIL PROTECTED] wrote:
>
> Any ideas?
Please provide a packet dump on both sides (or at least the sender
side).
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert
Matti Linnanvuori <[EMAIL PROTECTED]> wrote:
>
> -3) Do not forget that once you return 0 from your hard_start_xmit
> +3) A hard_start_xmit method must not modify the shared parts of the SKB.
Only if it's cloned.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email:
we have an IGMP6 event triggering the change
in the master's mc_list.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To
vinen
> > on the reader's screen.
>
> Did you actually see this? I'd expect to see that as well but no, From is
> correctly decoded by my ISO-8859-1'ish MUA, aha, seems that I still have
> something to do to deal with the Signed-off line.
Yeah I did see that. Other
penswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mess
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
one handling because they can always
run after another handler (e.g., AF_PACKET) which may have cloned the
packet.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.
-
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [E
sues without asking us to contribute. After all we haven't made
that commitment to you or your customers.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.a
, and then do a route lookup, at which point rp_filter
can eat your packet, and only after that do we perform the output
IPsec lookup.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP
looking
> at this rt_cache_get_next() and this patch only, it's looks like the
> third candidate after seq->private and rtable...
Perhaps we could introduce a sparse attribute for it?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} &
After
> this patch it seems possible...
Since rcu_derference(r) is always the same as r this patch cannot
change the value returned.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
P
at this is safe with respect to the rest of the bonding
driver it's fine by me.
BTW you only need read_lock since set_multicast_list always gets called
with BH off.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gon
> soon. So, IMHO, probably the first version of this patch is more
> reliable. (Or alternatively additional check is needed before return.)
No, while the value of r->u.dst.rt_next can change between two readings,
the value of r cannot.
Cheers,
--
Visit Openswan at http://www.openswan.org/
s calling from a timer context,
> > which couldn't sleep. It wasn't about the lock.
>
> Exactly, I was just about to post the same.
In other words, changing read_lock on bond->lock to read_lock_bh doesn't
affect this one bit.
Cheers,
--
Visit Openswan at http://www.openswa
> that could not be taken reliably in soft-irq context. Michael Chan
> fixed this here:
Sure, but where do you call that function while holding the bond lock?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://g
way is a plus. However, if you really want this to
happen it would help if you had attached a patch :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~
t to read_lock_bh somehow undoes the benefit of moving
softirq code into process context. It does not since the point of the
move is to be able to take the RTNL, which you can still do as long as
you do it before you disable BH.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
oint. The point is to move the majority of the code
into process context so that you can take the RTNL. Once you have taken
the RTNL you can disable BH all you want and I don't care one bit.
In any case, fixing a known dead-lock is important.
Cheers,
--
Visit Openswan at http://www.openswan.o
nice to react gracefully.
This patch ensures that the skb has enough data for an IP header and
that the header length field is valid.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]
701 - 800 of 2505 matches
Mail list logo
