Any chance of bpf-like functionality for pppd for Solaris?
Richard L. Hamilton
as activity for the purpose of demand dialing or determining
inactivity. I'm thinking particularly of NTP packets, but I
can think of at least a couple of other cases (AFS, TCP SYN on SMTP port)
where that might be somewhat useful in certain situations.
Logan Shaw
> Sure be nice to be able to specify packets that didn't count
> as activity for the purpose of demand dialing or determining
> inactivity. I'm thinking particularly of NTP packets, but I
> can think of at least a couple of other cases (AFS, TCP SYN on SMTP port)
> where that might be somewhat useful in certain situations.
I don't know if pppd does that, but I think there is a way you
can trigger a shell script to run whenever the link comes up or
goes down. So, if you want to do a real hack, you could install
IP Filter and have those shell scripts changes its rules for
packets that are outbound on the PPP interface, i.e. have it drop
those packets when the link is down and have it pass the packets
when the link is up.
- Logan
Richard L. Hamilton
Logan Shaw <lshaw-...@austin.rr.com> writes:
> Richard L. Hamilton wrote:
>
>> Sure be nice to be able to specify packets that didn't count
>> as activity for the purpose of demand dialing or determining
>> inactivity. I'm thinking particularly of NTP packets, but I
>> can think of at least a couple of other cases (AFS, TCP SYN on SMTP port)
>> where that might be somewhat useful in certain situations.
>
> I don't know if pppd does that, but I think there is a way you
According to the man page of the freeware version (on which Sun's
current pppd is based), on NetBSD and Linux platforms it can do that
(if the kernel components were built with support for that), but not
on other versions.
> can trigger a shell script to run whenever the link comes up or
> goes down. So, if you want to do a real hack, you could install
> IP Filter and have those shell scripts changes its rules for
> packets that are outbound on the PPP interface, i.e. have it drop
> those packets when the link is down and have it pass the packets
> when the link is up.
Thanks - I've been doing that for a long time now. It handles preventing
demand dialing ok, but does nothing for altering what constitutes activity
for purposes of determining whether or not to keep the link up. I get
around that by having the link up script kick off something in background
that sleeps for 10 minutes and then blocks outbound NTP again, but that's
not as good as a true inactivity filter (which would let the NTP go on as
long as the connection was up but would keep it from causing the
connection to be kept up in and of itself). I suppose I could snoop
for outgoing non-NTP packets and if I didn't get any for a certain
interval, send a SIGHUP to pppd. But that's seriously ugly at best, IMO.
James Carlson
> Sure be nice to be able to specify packets that didn't count
> as activity for the purpose of demand dialing or determining
> inactivity. I'm thinking particularly of NTP packets, but I
> can think of at least a couple of other cases (AFS, TCP SYN on SMTP port)
> where that might be somewhat useful in certain situations.
Yes, it's quite feasible. It just hasn't been done yet. (Or, rather,
the project that implemented this never got through review and ended
up being mothballed. It would probably take some customer interest --
hint, hint -- to bring it back to life.)
--
James Carlson, IP Systems Group <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Richard L. Hamilton
James Carlson <james.d...@sun.com> writes:
> Richard.L...@mindwarp.smart.net (Richard L. Hamilton) writes:
>> Sure be nice to be able to specify packets that didn't count
>> as activity for the purpose of demand dialing or determining
>> inactivity. I'm thinking particularly of NTP packets, but I
>> can think of at least a couple of other cases (AFS, TCP SYN on SMTP port)
>> where that might be somewhat useful in certain situations.
>
> Yes, it's quite feasible. It just hasn't been done yet. (Or, rather,
> the project that implemented this never got through review and ended
> up being mothballed. It would probably take some customer interest --
> hint, hint -- to bring it back to life.)
Since I spend as little as possible personally, I doubt I have any
influence; maybe someone else out there does though. Another possibility:
how close does Sun's derivative remain to the freeware pppd distro? On
externals, they look fairly close except for interface name and the exact
name of the modules (almost as if those were changed so both could
co-exist). If someone offered patches to the freeware version (I'm not
saying I'm able to do this, I haven't looked at it closely enough to be
sure what might be involved), would those eventually get rolled into Sun's
version? If so, I might mention the notion on comp.protocols.ppp and see
whether anyone was interested.
One other wish list item while I'm at it (and also something that a
variant that no longer works, dp-4.0, had, I think): sure would be nice if
the address (or protocol) family, protocol, and if TCP or UDP (4/6), port
number (and perhaps if ICMP, the ICMP-type) that caused a demand
connection to be established were output in a message (which might be
logged, just like the other messages from pppd). Sometimes one wants to
actually control what might initiate a demand connection, and it's a whole
lot easier to know what to change if you know what caused it in the first
place.
James Carlson
> Since I spend as little as possible personally, I doubt I have any
> influence; maybe someone else out there does though. Another possibility:
> how close does Sun's derivative remain to the freeware pppd distro?
I work on both, and I try to keep feature parity where it makes sense.
> On
> externals, they look fairly close except for interface name and the exact
> name of the modules (almost as if those were changed so both could
> co-exist).
That was exactly the reason -- to allow you to run both if you wanted
to.
> If someone offered patches to the freeware version (I'm not
> saying I'm able to do this, I haven't looked at it closely enough to be
> sure what might be involved), would those eventually get rolled into Sun's
> version? If so, I might mention the notion on comp.protocols.ppp and see
> whether anyone was interested.
The problem is that it would get held up at the same point: the
changes would have to work right with all the rest of the software
used on Solaris, would have to go through normal testing and
documentation, and then get released.
As I said, it's not a matter of code. We have code that does this.
> One other wish list item while I'm at it (and also something that a
> variant that no longer works, dp-4.0, had, I think): sure would be nice if
> the address (or protocol) family, protocol, and if TCP or UDP (4/6), port
> number (and perhaps if ICMP, the ICMP-type) that caused a demand
> connection to be established were output in a message (which might be
> logged, just like the other messages from pppd).
The Solaris version already does that with the "demand" option.
You'll see something like this in syslog if you have "debug" enabled:
TCP 40 data S 10.0.0.1->10.0.0.2 is activity
> Sometimes one wants to
> actually control what might initiate a demand connection, and it's a whole
> lot easier to know what to change if you know what caused it in the first
> place.
Indeed. That's why it does it. :-/
Richard L. Hamilton
James Carlson <james.d...@sun.com> writes:
> Richard.L...@mindwarp.smart.net (Richard L. Hamilton) writes:
>> One other wish list item while I'm at it (and also something that a
>> variant that no longer works, dp-4.0, had, I think): sure would be nice if
>> the address (or protocol) family, protocol, and if TCP or UDP (4/6), port
>> number (and perhaps if ICMP, the ICMP-type) that caused a demand
>> connection to be established were output in a message (which might be
>> logged, just like the other messages from pppd).
>
> The Solaris version already does that with the "demand" option.
> You'll see something like this in syslog if you have "debug" enabled:
>
> TCP 40 data S 10.0.0.1->10.0.0.2 is activity
I had occasion to enable debug (ISP renumbered their IP addresses), and
it does indeed function as described.
Unfortunately, daemon.debug in syslogd is intolerable on an ongoing basis
due to the incredible volume of messages generated, not only by pppd but
by other programs as well.
Could that particular message be promoted to daemon.info? That would
put it up just high enough that the volume would no longer be a killer,
and I think one could really make just as good a case for that being
"info" as being mere debugging information.
James Carlson
> Unfortunately, daemon.debug in syslogd is intolerable on an ongoing basis
> due to the incredible volume of messages generated, not only by pppd but
> by other programs as well.
Indeed.
> Could that particular message be promoted to daemon.info? That would
> put it up just high enough that the volume would no longer be a killer,
> and I think one could really make just as good a case for that being
> "info" as being mere debugging information.
I'll file an RFE and see what I can do. I'm very sensitive about
spamming the log files, since it often ends up being a much bigger
complaint than failing to log at a high enough level. (If someone has
a link that is _intentionally_ going up and down all the time with a
very short timer, I don't think he'd be amused to see each intentional
flap suddenly come with a higher-priority log message for free.)
Obviously, something much more flexible is needed here. Syslog is a
pretty dull knife.
Richard L. Hamilton
James Carlson <james.d...@sun.com> writes:
> Richard.L...@mindwarp.smart.net (Richard L. Hamilton) writes:
>> Unfortunately, daemon.debug in syslogd is intolerable on an ongoing basis
>> due to the incredible volume of messages generated, not only by pppd but
>> by other programs as well.
>
> Indeed.
>
>> Could that particular message be promoted to daemon.info? That would
>> put it up just high enough that the volume would no longer be a killer,
>> and I think one could really make just as good a case for that being
>> "info" as being mere debugging information.
>
> I'll file an RFE and see what I can do. I'm very sensitive about
> spamming the log files, since it often ends up being a much bigger
> complaint than failing to log at a high enough level. (If someone has
> a link that is _intentionally_ going up and down all the time with a
> very short timer, I don't think he'd be amused to see each intentional
> flap suddenly come with a higher-priority log message for free.)
>
> Obviously, something much more flexible is needed here. Syslog is a
> pretty dull knife.
>
Thanks. Agree on all counts, however pppd is already putting out plenty
of per-session messages at daemon.notice (one notch higher than
daemon.info), so one more at daemon.info probably isn't going to kill
anyone. That's also why I suggested only bumping that one up from debug
to info - that's probably "good enough", and still allows those who want
to only log down to daemon.notice to ignore it. The worst volume seems
to be at the debug level, and perhaps that's not surprising - I suppose that
it's not really expected that people choose to collect messages at debug
level for an extended period of time.
I suppose "ideally" one would have a list of all the messages in the
program with some unique number assigned to each, and have the ability to
configure the desired level for each, overriding hard-coded defaults. But
that's probably more work than anyone wants to go to.
I've heard of versions of syslogd that can filter not only on facility and
level, but also on the name the program identifies itself by. That would
be a huge help. But given that Sun's syslogd accepts logging via doors
and probably does some other odd stuff too, I'm not sure that some random
freeware syslogd implementation would just drop in place of it.
James Carlson
> I've heard of versions of syslogd that can filter not only on facility and
> level, but also on the name the program identifies itself by. That would
> be a huge help.
Indeed. That's about what I had in mind.
> But given that Sun's syslogd accepts logging via doors
> and probably does some other odd stuff too, I'm not sure that some random
> freeware syslogd implementation would just drop in place of it.
Right.