Searched hist:36960 (Results 1 - 3 of 3) sorted by relevance

/freebsd-10.0-release/usr.sbin/ppp/
H A Dslcompress.hdiff 36960 Sat Jun 13 22:56:13 MDT 1998 brian o Pass our negotiated number of VJ slots into
sl_uncompress_tcp() and drop packets with
slot numbers that are out of range.
o Drop packets that want to use a slot that still
has an IP header length of 0 (ie, the requested
slot number is bogus again).

Without this code, if the other side mis-behaves (and
sends us garbage slot numbers), we happily ``adjust''
a memset(..., '\0', ...) TCP/IP header and promptly
cr*p all over the stack before returning.... quickly
followed by a SIGBUS.

Dodgy ISP used by, and help locating the problem from: jmz
Problem also seen by: Mourad de Riche <omnibus@image.dk>

There's still a link lockup after this happens, but my
bets are on the other side (who has already started sending
rubbish) being to blame.
H A Dslcompress.cdiff 36960 Sat Jun 13 22:56:13 MDT 1998 brian o Pass our negotiated number of VJ slots into
sl_uncompress_tcp() and drop packets with
slot numbers that are out of range.
o Drop packets that want to use a slot that still
has an IP header length of 0 (ie, the requested
slot number is bogus again).

Without this code, if the other side mis-behaves (and
sends us garbage slot numbers), we happily ``adjust''
a memset(..., '\0', ...) TCP/IP header and promptly
cr*p all over the stack before returning.... quickly
followed by a SIGBUS.

Dodgy ISP used by, and help locating the problem from: jmz
Problem also seen by: Mourad de Riche <omnibus@image.dk>

There's still a link lockup after this happens, but my
bets are on the other side (who has already started sending
rubbish) being to blame.
H A Dvjcomp.cdiff 36960 Sat Jun 13 22:56:13 MDT 1998 brian o Pass our negotiated number of VJ slots into
sl_uncompress_tcp() and drop packets with
slot numbers that are out of range.
o Drop packets that want to use a slot that still
has an IP header length of 0 (ie, the requested
slot number is bogus again).

Without this code, if the other side mis-behaves (and
sends us garbage slot numbers), we happily ``adjust''
a memset(..., '\0', ...) TCP/IP header and promptly
cr*p all over the stack before returning.... quickly
followed by a SIGBUS.

Dodgy ISP used by, and help locating the problem from: jmz
Problem also seen by: Mourad de Riche <omnibus@image.dk>

There's still a link lockup after this happens, but my
bets are on the other side (who has already started sending
rubbish) being to blame.

Completed in 55 milliseconds