From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 11:05:53 +1000
> I wrote:
>
> > So this doesn't change process_input_packet(), which treats the case
> > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> > 0x03 (PPP_UI) as indicating a packet with a PPP protoc
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>>
>> So this doesn't change process_input_packet(), which treats the case
>> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
>> 0x03 (PPP_UI) as indicating a packet with a PPP protocol numbe
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
I tested Paul's patch for last few days and I think everything seems
ok. The system is stable.
Regards
Bartek
-
To
Hi Paul:
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong s
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
> David Miller writes:
>
>> Here is Patrick McHardy's patch:
>
> So this d
I wrote:
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
I meant "the second byte is NOT 0x03", of course.
Paul.
-
To unsubscribe fr
David Miller writes:
> Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since
David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Sun, 15 Apr 2007 02:49:28 +1000
>
>
>>I didn't see the patch (the message that this is a reply to is the
>>first one that I have seen in this thread), so I can't comment on it.
>
>
> Here is Patrick McHardy's patch:
>
> [..
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 02:49:28 +1000
> I didn't see the patch (the message that this is a reply to is the
> first one that I have seen in this thread), so I can't comment on it.
Here is Patrick McHardy's patch:
diff --git a/drivers/net/ppp_async.c b/driv
David Miller writes:
> > It seems we fail to reserve enough headroom for the case
> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
> >
> > Can you try this patch please?
>
> Any confirmation of this fix yet?
Indeed, ppp_async doesn't handle that case correctly.
RFC 1662 says:
The Con
David Miller <[EMAIL PROTECTED]> wrote:
>
>> It seems we fail to reserve enough headroom for the case
>> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>>
>> Can you try this patch please?
>
> Any confirmation of this fix yet?
FWIW the fix definitely looks correct (the bug has been there for
ye
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> Bartek wrote:
> > Hopefully, this time it my bug report should be ok :):
> >
> > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a
Bartek wrote:
> Hopefully, this time it my bug report should be ok :):
>
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
> bf 44 cc ac 3b ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protoco
13 matches
Mail list logo
