find a
patch that fixes that.
Florian
---
Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED]
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index a05c342..fa0aec5 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
Hi,
-static int hash_item(unsigned long sid, unsigned char *addr)
+#if 8%PPPOE_HASH_BITS
+#error 8 must be a multiple of PPPOE_HASH_BITS
+#endif
Since PPPOE_HASH_BITS is 4 I would think this check will break the
build. :-)
Erm, I thought that 8 was 4*2, but maybe I didn't quite
Hi,
Erm, I'd say this not only produces different results than the old
version, but it also produces wrong results, in that it ignores quite
a bit of the data that's supposed to be hashed. If I didn't overlook
something, it only considers addr0x0f0f0f0f0f00 and sid0x0f0f, given
the
Hi,
Actually it might be simpler and more efficient to just make
PPPOE_HASH_SHIFT be 8.
SHIFT? SIZE? BITS?
You know what I meant :-)
PPPOE_HASH_BITS.
Actually, I wasn't sure, for SHIFT looks more similar to SIZE
than to BITS, plus numbers are somewhat same order of magnitude
for 4-bit hashes on the CPUs I tested.
Florian
---
Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED]
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 9e51fcc..954328c 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net
---
Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED]
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 954328c..9554924 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -669,8 +669,8 @@ static int pppoe_ioctl(struct socket *sock, unsigned int
cmd,
{
struct
Hi,
and the last one for now: Acquire the sock lock in pppoe_sendmsg()
before accessing the sock - and in particular avoid releasing the lock
even though it hasn't been acquired.
Florian
---
Signed-off-by: Florian Zumbiehl
Hi,
This patch doesn't apply becuase in the actual pppoe.c code:
[...]
So I'm having trouble figuring out what tree you generated
that patch against :-) Perhaps there was an earlier patch
I missed or something.
But I won't second guess and leave it to you to let me know
what I should
Hi,
Florian Zumbiehl wrote:
Hi,
+ * 251003 :Copied from pppoe.c version 0.6.9.
you might want to have a look at the patches to the PPPoE code that were
posted to netdev recently, as some of them seem to apply to code that's
left over from pppoe.c.
Do you mean this change
for 4-bit hashes on the CPUs I tested.
Florian
---
Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED]
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 9e51fcc..954328c 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net
---
Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED]
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 954328c..9554924 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -669,8 +669,8 @@ static int pppoe_ioctl(struct socket *sock, unsigned int
cmd,
{
struct
Hi,
and the last one for now: Acquire the sock lock in pppoe_sendmsg()
before accessing the sock - and in particular avoid releasing the lock
even though it hasn't been acquired.
Florian
---
Signed-off-by: Florian Zumbiehl
Hi,
Attached below is my take on how to address this problem.
This addresses any concerns you may have had about checking
po-pppoe_dev==NULL,
because accesses to this field are now synchronized with pppoe_hash_lock.
That indeed looks like a much cleaner solution, so I'd certainly prefer
Hi,
below is a patch that just removes dead code/initializers without any
effect (first access is an assignment) that I stumbled accross while
reading the source.
Florian
---
diff --git a/drivers/net/pppoe.c
Hi,
below you find a patch that (hopefully) fixes a race between an interface
going down and a connect() to a peer on that interface. Before,
connect() would determine that an interface is up, then the interface
could go down and all entries referring to that interface in the
item_hash_table
Hi,
below you find a patch that fixes a memory leak when a PPPoE socket is
release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
ever has been called on it.
This is somewhat of a security problem, too, since PPPoE sockets can be
created by any user, so any user can easily
Hi,
below you find the last patch for now. It (hopefully) fixes a race
between a socket being release()d and the interface it's using going
down. As pppoe_release() didn't lock the socket, and pppoe_flush_dev()
did the locking in the wrong place, pppoe_flush_dev() could set
po-pppoe_dev to NULL,
Hi,
In the current code SID 0 indicates that the socket is to be un-bound.
That are the semantics used by the kernel code, yes - but even pppd uses
different semantics (which can't quite work, of course ...).
Supporting unbinding of the socket was intended to permit the PPPoE
session to be
Hi,
This change can be made; the unbinding behavior can be removed and SID 0
can be made valid. I hope I was clear in my previous e-mail that I
didn't object to this.
Not quite. But now I think I got it ;-)
PPPoE connections are unstable. Ethernet frames get dropped. Things
die randomly.
Hi,
From the RFC:
5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet
When the Access Concentrator receives a PADR packet, it prepares to
begin a PPP session. It generates a unique SESSION_ID for the PPPoE
session and replies to the Host with a PADS packet. The
Hi,
From: Florian Zumbiehl [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 13:38:44 +0100
As noone seems to have an opinion on this: Here is a patch that does
work for me and that should solve the problem as far as that is easily
possible. It is based on the assumption that an interface's
Hi,
I noticed that the PPPoE code doesn't allow session id 0x to be used
for an actual session but rather considers 0 a special value denoting
that the socket is unbound. Now, when reading RFC 2516, I couldn't really
find anything that would forbid 0x as a session id. Only 0x is
+ * be injected into a session from interfaces other than the one
+ * specified by userspace. Florian Zumbiehl [EMAIL PROTECTED]
+ * (Oh, BTW, this one is YYMMDD, in case you were wondering ...)
* 220102 :Fix module use count on failure in pppoe_create, pppox_sk -acme
* 030700
Hi,
I'm experiencing a pretty strange problem with kernel PPPoE on tap
interfaces with a vanilla 2.6.20 kernel that prevents the PPP connection
from being established:
[...]
Well, I guess I have found the source of the problem: The PPPoE code seems
to match inbound packets to sockets based
Hi,
I'm experiencing a pretty strange problem with kernel PPPoE on tap
interfaces with a vanilla 2.6.20 kernel that prevents the PPP connection
from being established:
Every PPPoE session packet (that is, LCP, since it never gets to a stage
where any other session data is being exchanged) is
Hi,
This tells us that the kernel was indeed retransmitting but the
packet didn't make it out of the interface according to your
tcpdump.
Well, at least the tcp part of it, it seems, yep. The debugging I've
done so far also seems to confirm that the problem is somewhere beyond
the tcp code,
Hi,
meanwhile I gathered some information from /proc/net/tcp6 on this
problem - in case anyone is interested :-)
| 1144560959: 8: :1223
:1A0B 01 : 02:00097F82
10000 3188619 8 c1409260 89 10 20 2
Hi,
I've been regularly losing my IRC connections going over my PPP/PPPoE/ADSL
IPv6 connection with static addresses for quite some time now. I haven't
found any obvious correlation with PPP reconnects or anything else one
would expect to cause this - now, I've had a look at it using tcpdump
and
28 matches
Mail list logo
