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.