*BSD News Article 30642


Return to BSD News archive

Xref: sserve comp.os.386bsd.bugs:2228 comp.protocols.ppp:4202
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!mimbres.cs.unm.edu!ncar!newsxfer.itd.umich.edu!europa.eng.gtefsd.com!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!rutgers!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.os.386bsd.bugs,comp.protocols.ppp
Subject: Re: priority queuing bug in *BSD ppp (if_ppp.c)
Keywords: ppp BSD
Message-ID: <Cpqyzy.Kot@twwells.com>
Date: 13 May 94 15:28:26 GMT
References: <1994May7.004353.695@fasterix.frmug.fr.net> <1994May10.130723.28188@zen.void.oz.au>
Organization: None, Mt. Laurel, NJ
Lines: 21

In article <1994May10.130723.28188@zen.void.oz.au>,
Simon J. Gerraty <sjg@zen.void.oz.au> wrote:
: pb@fasterix.frmug.fr.net (Pierre Beyssac) writes:
: > Mail copy to the FreeBSD/NetBSD mailing-lists and Paul Mackerras
: >(paulus@cs.anu.edu.au)
: >         if (INTERACTIVE(ntohs(p & 0xffff)) || INTERACTIVE(ntohs(p >> 16)))
:
: I suspect that
:
:       if (INTERACTIVE(ntohs(p) & 0xffff) || INTERACTIVE(ntohs(p) >> 16))
:
: is more likely to resolve the ntohs() problem without changing the
: meaning of the code.  ntohs(p >> 16) and ntohs(p) >> 16 can
: produce _very_ different results.

P, at that point, is an integer with two halves, the source port
and the destination port. If I read the code right, ntohs operates
on short values only. So, the code is supposed to extract two
bytes from p, run ntohs on it to get the right byte order, and
then pass that result to INTERACTIVE. The original proposed fix
is correct.