Subject: Re: PPP stupidity (again)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-i386
Date: 08/24/1999 12:30:46 
[not an i386 issue, reply set to  tech-net]

Der Mouse writes:

>The other is that high-priority data packets lock out LCP (and
>presumably IPCP) packets.  This, I would say, should be fixed.
>
>> [I]f someone decides to flood a PPP link with high-priority packets,
>> the link will be totally unusable.
>
>This is a risk in any case.  Perhaps high-priority packets shouldn't be
>allowed to use up more than (say) 75% of the line, unless there's no
>non-high-priority traffic?
>
>But on the other hand, is this really something that belongs in ppp?

If our PPP is going to try and do TOS-sensitive queueing, then, yes,
our PPP needs to avoid starvation for LCP and avoid DOS attacks that
exploit TOS.
uble started somewhere around >May i guess. The 1.4 release was very stable. BTW: RND is disabled. >Any ideas ? Well, this works for me.... I played around with this. It isn't just amanda; going to another machine and doing "rsh nbsd-box /sbin/dump -0 -f- /fs > /dev/null" will trigger the reboot. However, fs seems to be a certain size before it reboots; so, / on my machine will be dumpable, but not /usr (OTOH, / is dumped uncompressed, while /usr is compressed). If I run a kernel without apm support compiled in, then things seem fine. I've been dumping over the network all afternoon w/o problems. Whereas, this morning with my usual 1.4/1.4.1 kernel (w and w/o rnd), the rsh line above is a guaranteed take down. The main problem I had was coordinating the start of a dump, and getting a ktrace before the machine rebooted. I've also send-pr'ed it (whoo hoo! my first!). WL