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
@@ -1632,8 +163
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 ord
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 addr&0x0f0f0f0f0f00 and sid&0x0f0f, given
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
orian
---
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,
{
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 Zum
imes faster 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/
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 sh
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 tha
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.
Florian
-
To unsubscribe from this list: send the line "unsubscribe netd
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 Zum
imes faster 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/
orian
---
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,
{
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 pref
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,
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 all
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 would
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 b/drivers/net/pp
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 rando
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 b
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
> From: Florian Zumbiehl <[EMAIL PROTECTED]>
> Date: Sun, 4 Mar 2007 02:55:16 +0100
>
> > Below you find a slightly changed version of the patch
>
> I already applied your first patch, so if you have any
> fixes to submit please provide them as relative pat
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
reser
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 i
packets can't
+ * 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
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 deli
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 i
30 matches
Mail list logo
