Richard L. Hamilton writes:
> Still no filtering functionality (for what should _not_ bring up the
> connection or keep it active)?
No. There was a project to do that around 6 or 7 years ago, but the
engineer involved left Sun, and there's been little or no feature work
since. The changes I'm making are just bug fixes.
The original (approved) project recording PPP-related filtering
functionality was "PPP Filtering" (PSARC 2001/120), and the RFE is CR
4417975.
> Once again, I'd cite NTP as a fantastic example of something even a
> sporadically connected system could benefit from running, _if_ that
> didn't cause it to be connected all the time.
Yes, agreed. It's a pain.
> Unless pfhooks can be used somehow, I gather this requires bpf. ISTR
> a student project that was going to work on bpf for OpenSolaris, no
> recollection if it got anywhere. Also seen other mentions of things that
> could either use bpf, or were doing something to try to avoid the need for
> it.
It's also been discussed during the review of pfhooks, IPQoS, and many
other packet-filtering-related cases in the past. It's an interesting
problem, because you generally want at least two special filter
actions, besides the usual pass/drop/icmp/rst mechanisms:
- "this packet does not cause a demand dial"
Normally, all packets sent on a demand-dial interface cause the
link to be brought up. It needs to be possible to specify that a
given packet shouldn't cause the link to be brought up, but if the
packet is present, it represents activity for the link. (E.g.,
sending batched file transfers might be in this bucket. You don't
want the link to come down while transferring data, but you might
not want to bring the link up just to do that alone.)
- "this packet does not count as activity"
Normally, all data packets sent on a PPP link (whether demand or
not) are counted as activity and all control packets are ignored.
This is used for the optional idle timer that brings down a link.
It needs to be possible to specify that some data packets are not
worth keeping a link up. (E.g., ping messages and periodic SNMP
queries and SMB noise are in this category.)
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
