Info on dialout connections - PPP

This is a discussion on Info on dialout connections - PPP ; I set up a "dialout server" using multiple pppd instances (one for every remote site) with the "demand" option. The installation works fine, but I'm looking for a way (if there's one) to have some infos about the connections: 1) ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Info on dialout connections

  1. Info on dialout connections

    I set up a "dialout server" using multiple pppd instances (one for every
    remote site) with the "demand" option.
    The installation works fine, but I'm looking for a way (if there's one) to
    have some infos about the connections:
    1) how can I tell what ppp connections are active at the moment?
    2) how can I know what is the idle timer for a particular active connection?
    3) I would like to know what type of packet triggered a connection. I there
    a way to log this information?

    I googled around some time but did not find an answer. Any suggestion, or
    redirection to documentation, is welcome.

    Thank you
    Lux



  2. Re: Info on dialout connections

    I forgot to mention the implementation details:
    Linux Fedora Core 3 , kernel 2.6.11-1.14_FC3 , ppp 2.4.2-6.4.FC3 .

    The pppd daemons are started with these settings:
    pppd lock modem crtscts asyncmap 00000000 192.168.1.254:192.168.1.1 user 001
    remotename 001 demand ktune idle 300 holdoff 30 /dev/ttyS0 115200 ipparam
    001 linkname 001 call 001 noauth debug
    pppd lock modem crtscts asyncmap 00000000 192.168.1.254:192.168.1.2 user 002
    remotename 002 demand ktune idle 300 holdoff 30 /dev/ttyS0 115200 ipparam
    002 linkname 002 call 002 noauth debug
    ....and so on...

    The modem is dialed via wvdial.



  3. Re: Info on dialout connections

    lux wrote:
    > I set up a "dialout server" using multiple pppd instances (one for every
    > remote site) with the "demand" option.
    > The installation works fine, but I'm looking for a way (if there's one) to
    > have some infos about the connections:
    > 1) how can I tell what ppp connections are active at the moment?


    Here's an example script which I think, when run from a command line,
    should show existing pppd connections for user nnn every 5 seconds for
    3 digit user names as shown in your second post.

    while [ 0 -lt 1 ]; do
    ps auxwww|egrep [r]oot|egrep [p]ppd|\
    sed 's/\(.*user\)\(....\)\(.*\)/user\2/g'
    sleep 5
    done

    > 2) how can I know what is the idle timer for a particular active connection?


    The timer is internal to pppd. I don't have a good answer to this
    question; there's no provision in pppd to publish, say, the time
    elapsed from the last activity on the link. If you are up to it then
    you can change the pppd source to find out. What you need seems to
    be in auth.c of the pppd source.

    > 3) I would like to know what type of packet triggered a connection. I there
    > a way to log this information?


    Well, for TCP it's always an IP packet with a SYN request. ;>

    Seriously, it depends on the meaning of "type of packet." The command
    "netstat -tenup" shows existing connections at the time it's executed,
    not for the time the connection is "triggered."

    > I googled around some time but did not find an answer. Any suggestion, or
    > redirection to documentation, is welcome.


    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The signal-to-noise ratio is too low in many [news] groups to make
    * them good candidates for archiving.
    * --- Mike Moraes, Answers to FAQs about Usenet */

  4. Re: Info on dialout connections

    "Clifford Kite" ha scritto nel messaggio
    news:njkn8d.035.ln@corncob.inetport.tld...
    > lux wrote:
    > > I set up a "dialout server" using multiple pppd instances (one for every
    > > remote site) with the "demand" option.
    > > The installation works fine, but I'm looking for a way (if there's one)

    to
    > > have some infos about the connections:
    > > 1) how can I tell what ppp connections are active at the moment?

    >
    > Here's an example script which I think, when run from a command line,
    > should show existing pppd connections for user nnn every 5 seconds for
    > 3 digit user names as shown in your second post.
    >
    > while [ 0 -lt 1 ]; do
    > ps auxwww|egrep [r]oot|egrep [p]ppd|\
    > sed 's/\(.*user\)\(....\)\(.*\)/user\2/g'
    > sleep 5
    > done
    >


    Thank you Clifford, but I'm usign the demand option. This means that the
    pppds are run at boot time and they remain passive (do not dial the remote
    site) until there is some 'interesting traffic' to forward (the interesting
    traffic is defined with the active-filter option).
    So with a script as you suggest, if I undestand well, I always get the same
    results, because all the pppds are always there, in the output of ps auxwww.
    And the pppd command line shown by ps auxwww does not change if the pppd is
    connected to the remote site or not.
    This leads me to another question: is the demand option the right way to
    have a host automatically dial a remote site when there is traffic to send,
    or should I use another method/service to spawn a pppd when it is needed?

    P.S. O.T.: why do you "egrep [r]oot" instead of simply "egrep root"?

    > > 2) how can I know what is the idle timer for a particular active

    connection?
    >
    > The timer is internal to pppd. I don't have a good answer to this
    > question; there's no provision in pppd to publish, say, the time
    > elapsed from the last activity on the link. If you are up to it then
    > you can change the pppd source to find out. What you need seems to
    > be in auth.c of the pppd source.


    I only have very very basic programming knowledge, but if someone more
    skilled tells me that it can be similar to what the pppstats does to collect
    its counters, I could try to do some copy and paste.

    >
    > > 3) I would like to know what type of packet triggered a connection. I

    there
    > > a way to log this information?

    >
    > Well, for TCP it's always an IP packet with a SYN request. ;>
    >
    > Seriously, it depends on the meaning of "type of packet." The command
    > "netstat -tenup" shows existing connections at the time it's executed,
    > not for the time the connection is "triggered."


    Sorry , we are not agreeing on the meaning of the word "connection". In this
    context I was not talking about TCP connections. I intended the connection
    my pppd establishes with the remote peer, dialing with wvdial. Since this
    operation is done when there is some "interesting traffic" to be forwarded,
    I would like to know what this traffic is (IP addressed, protocol, ports
    should be both useful and sufficient).
    This need comes from the fact that when I set up a router that automatically
    dials out a remote site, some user always calls me saying "the router is
    dialing the remote site, but I did not do anything to make it do so". So I
    can trace what was that triggered the dial-out connection.

    Thank you

    Lux



  5. Re: Info on dialout connections

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Lux wrote:
    > "Clifford Kite" ha scritto nel messaggio

    [snip]
    >> ps auxwww|egrep [r]oot|egrep [p]ppd|\

    [snip]
    > P.S. O.T.: why do you "egrep [r]oot" instead of simply "egrep root"?

    [snip]

    Because, the egrep will be listed in the process list returned by ps,
    and the matching performed by 'egrep root' would match the process
    listing line containing "egrep root", thus resulting in a false positive.

    OTOH, with 'egrep [r]oot', the egrep command won't match the /literal/
    process listing line "egrep [r]oot", because the first character after
    the space is a '[' not a 'r' as the egrep needs. Thus, no false positive
    from the ps listing the egrep along with the other processes.

    - --

    Lew Pitcher, IT Specialist, Enterprise Data Systems
    Enterprise Technology Solutions, TD Bank Financial Group

    (Opinions expressed here are my own, not my employer's)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (MingW32)

    iD8DBQFCsF+XagVFX4UWr64RAnQKAJ9nZ2ffvz2Vdny9EOeXcA NgRkRbhQCg1B6Z
    9bTfbzqfALG9dVrWT8HgEdw=
    =yKNV
    -----END PGP SIGNATURE-----

  6. Re: Info on dialout connections

    Lux wrote:
    > "Clifford Kite" ha scritto nel messaggio
    > news:njkn8d.035.ln@corncob.inetport.tld...
    >> lux wrote:
    >> > I set up a "dialout server" using multiple pppd instances (one for every
    >> > remote site) with the "demand" option.
    >> > The installation works fine, but I'm looking for a way (if there's one)

    > to
    >> > have some infos about the connections:
    >> > 1) how can I tell what ppp connections are active at the moment?

    >>



    >> Here's an example script which I think, when run from a command line,
    >> should show existing pppd connections for user nnn every 5 seconds for
    >> 3 digit user names as shown in your second post.
    >>
    >> while [ 0 -lt 1 ]; do
    >> ps auxwww|egrep [r]oot|egrep [p]ppd|\
    >> sed 's/\(.*user\)\(....\)\(.*\)/user\2/g'
    >> sleep 5
    >> done
    >>


    > Thank you Clifford, but I'm usign the demand option. This means that the
    > pppds are run at boot time and they remain passive (do not dial the remote
    > site) until there is some 'interesting traffic' to forward (the interesting
    > traffic is defined with the active-filter option).


    You're absolutely right, I overlooked that.

    > So with a script as you suggest, if I undestand well, I always get the same
    > results, because all the pppds are always there, in the output of ps auxwww.
    > And the pppd command line shown by ps auxwww does not change if the pppd is
    > connected to the remote site or not.
    > This leads me to another question: is the demand option the right way to
    > have a host automatically dial a remote site when there is traffic to send,
    > or should I use another method/service to spawn a pppd when it is needed?


    The demand option is standard for dialing out "as needed" for traffic
    outbound via the PPP interface routing. I don't know of another way
    to do that.

    > P.S. O.T.: why do you "egrep [r]oot" instead of simply "egrep root"?


    Lew Pitcher's answer to this is correct.

    >> > 2) how can I know what is the idle timer for a particular active

    > connection?
    >>
    >> The timer is internal to pppd. I don't have a good answer to this
    >> question; there's no provision in pppd to publish, say, the time
    >> elapsed from the last activity on the link. If you are up to it then
    >> you can change the pppd source to find out. What you need seems to
    >> be in auth.c of the pppd source.


    > I only have very very basic programming knowledge, but if someone more
    > skilled tells me that it can be similar to what the pppstats does to collect
    > its counters, I could try to do some copy and paste.


    My knowledge regarding C programming is at level similar to yours.
    I do think it would require more than cut-and-paste to present the
    timer values in a manner appropriate for you.

    >> > 3) I would like to know what type of packet triggered a connection. I

    > there
    >> > a way to log this information?

    >>
    >> Well, for TCP it's always an IP packet with a SYN request. ;>
    >>
    >> Seriously, it depends on the meaning of "type of packet." The command
    >> "netstat -tenup" shows existing connections at the time it's executed,
    >> not for the time the connection is "triggered."


    > Sorry , we are not agreeing on the meaning of the word "connection". In this
    > context I was not talking about TCP connections. I intended the connection
    > my pppd establishes with the remote peer, dialing with wvdial. Since this
    > operation is done when there is some "interesting traffic" to be forwarded,
    > I would like to know what this traffic is (IP addressed, protocol, ports
    > should be both useful and sufficient).


    Right, I didn't read that the way it was intended.

    > This need comes from the fact that when I set up a router that automatically
    > dials out a remote site, some user always calls me saying "the router is
    > dialing the remote site, but I did not do anything to make it do so". So I
    > can trace what was that triggered the dial-out connection.


    I can only say it seems to me that the most common thing activating a
    demand dial-out would be a DNS lookup. You might find the cause, or
    causes, of unwanted dial-ups by running tcpdump on the PPP interface
    of a "router" that someone often complains about and direct it's
    output to a log file. The person affected could then note the time
    of an unwanted dial-out and send you the log, or just the appropriate
    section of it. (This is ugly and may not work for you but it's the
    only half-way reasonable thing that comes to mind.)

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

  7. Re: Info on dialout connections

    "Lux" writes:

    >"Clifford Kite" ha scritto nel messaggio
    >news:njkn8d.035.ln@corncob.inetport.tld...
    >> lux wrote:
    >> > I set up a "dialout server" using multiple pppd instances (one for every
    >> > remote site) with the "demand" option.
    >> > The installation works fine, but I'm looking for a way (if there's one)

    >to
    >> > have some infos about the connections:
    >> > 1) how can I tell what ppp connections are active at the moment?

    >>
    >> Here's an example script which I think, when run from a command line,
    >> should show existing pppd connections for user nnn every 5 seconds for
    >> 3 digit user names as shown in your second post.
    >>
    >> while [ 0 -lt 1 ]; do
    >> ps auxwww|egrep [r]oot|egrep [p]ppd|\
    >> sed 's/\(.*user\)\(....\)\(.*\)/user\2/g'
    >> sleep 5
    >> done
    >>


    >Thank you Clifford, but I'm usign the demand option. This means that the
    >pppds are run at boot time and they remain passive (do not dial the remote
    >site) until there is some 'interesting traffic' to forward (the interesting
    >traffic is defined with the active-filter option).


    Use /etc/ppp/ip-up and ip-down to write the connection to a file and remove
    it from the file (or even touch and remove a file.
    touch /name/of/directory/pppup-$5
    in ip-up
    and
    rm /name/of/directory/pppup-$5
    in ip-down


    >I only have very very basic programming knowledge, but if someone more
    >skilled tells me that it can be similar to what the pppstats does to collect
    >its counters, I could try to do some copy and paste.


    The idle time changes constantly. You do NOT want pppd to be reporting
    every change in the idle timer. You would destroy your pppd as it would be
    using all its time to do that.
    You would have to have pppd catch some signal, and when that signal is
    caught, to write out the current value of the timer to some file.




    >Sorry , we are not agreeing on the meaning of the word "connection". In this
    >context I was not talking about TCP connections. I intended the connection
    >my pppd establishes with the remote peer, dialing with wvdial. Since this
    >operation is done when there is some "interesting traffic" to be forwarded,
    >I would like to know what this traffic is (IP addressed, protocol, ports
    >should be both useful and sufficient).
    >This need comes from the fact that when I set up a router that automatically
    >dials out a remote site, some user always calls me saying "the router is
    >dialing the remote site, but I did not do anything to make it do so". So I
    >can trace what was that triggered the dial-out connection.


    You would have to rewrite pppd to do this. Good luck.

  8. Re: Info on dialout connections

    "Unruh" writes:

    > Use /etc/ppp/ip-up and ip-down to write the connection to a file and

    remove
    > it from the file (or even touch and remove a file.
    > touch /name/of/directory/pppup-$5
    > in ip-up
    > and
    > rm /name/of/directory/pppup-$5
    > in ip-down


    Thank you, I'll do so. I was wondering if there is a way to ask ppp directly
    what it was doing, but now I definitely think there is no such feature, so
    I'll adopt your solution.

    > >I only have very very basic programming knowledge, but if someone more
    > >skilled tells me that it can be similar to what the pppstats does to

    collect
    > >its counters, I could try to do some copy and paste.

    >
    > The idle time changes constantly. You do NOT want pppd to be reporting
    > every change in the idle timer. You would destroy your pppd as it would be
    > using all its time to do that.
    > You would have to have pppd catch some signal, and when that signal is
    > caught, to write out the current value of the timer to some file.


    Yes, I do NOT want pppd to be reporting every change in the idle timer. I
    thought about something similar to pppstats: when someone wants statistics
    about the compression rates achieved, he runs pppstats which by way of ioctl
    (from what I can undestand of C) is notified of the data it needs. These
    data are already maintained by the ppp layer, but are notified to some user
    only when it asks it. Since the ppp layer already stores the idle timer in a
    variable, and (from what I can undestand of the code) there is ready
    available a ioctl that could be used to retrieve that value, I thought it
    could be possible to write some utility that displays it.

    > >Sorry , we are not agreeing on the meaning of the word "connection". In

    this
    > >context I was not talking about TCP connections. I intended the

    connection
    > >my pppd establishes with the remote peer, dialing with wvdial. Since this
    > >operation is done when there is some "interesting traffic" to be

    forwarded,
    > >I would like to know what this traffic is (IP addressed, protocol, ports
    > >should be both useful and sufficient).
    > >This need comes from the fact that when I set up a router that

    automatically
    > >dials out a remote site, some user always calls me saying "the router is
    > >dialing the remote site, but I did not do anything to make it do so". So

    I
    > >can trace what was that triggered the dial-out connection.

    >
    > You would have to rewrite pppd to do this. Good luck.


    For sure I'm not able to do this task (and it would seem to me a loss of
    time and resources since the ppp package already behaves well) but may I ask
    you why I would have to do so? There is an option, kdebug, that makes the
    ppp layer to dump every packet to syslog. I supposed there could be a way to
    (or something could be done to) make it dump only the particular first
    packet that triggers a dialing call. But maybe the call is performed by the
    userspace pppd, which actually does not know about the packets that are to
    be forwarded?



  9. Re: Info on dialout connections

    "Lux" writes:

    >"Unruh" writes:


    >> Use /etc/ppp/ip-up and ip-down to write the connection to a file and

    >remove
    >> it from the file (or even touch and remove a file.
    >> touch /name/of/directory/pppup-$5
    >> in ip-up
    >> and
    >> rm /name/of/directory/pppup-$5
    >> in ip-down


    >Thank you, I'll do so. I was wondering if there is a way to ask ppp directly
    >what it was doing, but now I definitely think there is no such feature, so
    >I'll adopt your solution.


    >> >I only have very very basic programming knowledge, but if someone more
    >> >skilled tells me that it can be similar to what the pppstats does to

    >collect
    >> >its counters, I could try to do some copy and paste.

    >>
    >> The idle time changes constantly. You do NOT want pppd to be reporting
    >> every change in the idle timer. You would destroy your pppd as it would be
    >> using all its time to do that.
    >> You would have to have pppd catch some signal, and when that signal is
    >> caught, to write out the current value of the timer to some file.


    >Yes, I do NOT want pppd to be reporting every change in the idle timer. I
    >thought about something similar to pppstats: when someone wants statistics
    >about the compression rates achieved, he runs pppstats which by way of ioctl
    >(from what I can undestand of C) is notified of the data it needs. These
    >data are already maintained by the ppp layer, but are notified to some user
    >only when it asks it. Since the ppp layer already stores the idle timer in a
    >variable, and (from what I can undestand of the code) there is ready
    >available a ioctl that could be used to retrieve that value, I thought it
    >could be possible to write some utility that displays it.


    >> >Sorry , we are not agreeing on the meaning of the word "connection". In

    >this
    >> >context I was not talking about TCP connections. I intended the

    >connection
    >> >my pppd establishes with the remote peer, dialing with wvdial. Since this
    >> >operation is done when there is some "interesting traffic" to be

    >forwarded,
    >> >I would like to know what this traffic is (IP addressed, protocol, ports
    >> >should be both useful and sufficient).
    >> >This need comes from the fact that when I set up a router that

    >automatically
    >> >dials out a remote site, some user always calls me saying "the router is
    >> >dialing the remote site, but I did not do anything to make it do so". So

    >I
    >> >can trace what was that triggered the dial-out connection.

    >>
    >> You would have to rewrite pppd to do this. Good luck.


    >For sure I'm not able to do this task (and it would seem to me a loss of
    >time and resources since the ppp package already behaves well) but may I ask
    >you why I would have to do so? There is an option, kdebug, that makes the
    >ppp layer to dump every packet to syslog. I supposed there could be a way to


    No. kdebug is defunct in 2.4.2 pppd. And this is horrible. it is like the
    idle timer option-- far too much data.

    >(or something could be done to) make it dump only the particular first
    >packet that triggers a dialing call. But maybe the call is performed by the


    Yes. You would have to rewrite pppd to do this. good luck.


    >userspace pppd, which actually does not know about the packets that are to
    >be forwarded?


    Unless I am very mistaken, pppd does not have anything now to do this. You
    would have to rewrite pppd to do this. Good luck.
    Is someone else going to rewrite pppd do do this for you? If you paid
    enough sure. Otherwise highly doubtful.




  10. Re: Info on dialout connections

    Unruh wrote:

    > Use /etc/ppp/ip-up and ip-down to write the connection to a file and remove
    > it from the file (or even touch and remove a file.
    > touch /name/of/directory/pppup-$5
    > in ip-up
    > and
    > rm /name/of/directory/pppup-$5
    > in ip-down


    That will only provide the remote IP address for the PPP connection.
    The OP's second post showed those, and even if they are renegotiated
    it's my impression that he wants more. I suspect he really wants
    enough information to reconfigure the active-filter option to prevent
    unwanted dial-outs.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The wealth of a nation is created by the productive labor of its
    * citizens. */

  11. Re: Info on dialout connections

    "Clifford Kite" wrote:
    > Unruh wrote:
    >
    > > Use /etc/ppp/ip-up and ip-down to write the connection to a file and

    remove
    > > it from the file (or even touch and remove a file.
    > > touch /name/of/directory/pppup-$5
    > > in ip-up
    > > and
    > > rm /name/of/directory/pppup-$5
    > > in ip-down

    >
    > That will only provide the remote IP address for the PPP connection.
    > The OP's second post showed those, and even if they are renegotiated
    > it's my impression that he wants more. I suspect he really wants
    > enough information to reconfigure the active-filter option to prevent
    > unwanted dial-outs.


    Right. Being able to tell which remote sites are connected is better than
    nothing, but I would like to also know why they were dialed. I'm
    experimenting with some code, if I come to something usable, I'll post it.



  12. Re: Info on dialout connections

    After having a look at the source code I wrote a program, pppidle, that
    reports the idle timer for an interface, and a patch for pppd that makes it
    report some infos about the packet that triggered a pppd instance in
    dial-on-demand mode to dial a remote site.
    Beware: I never had been a programmer. The code is for sure horrible, buggy,
    faulty and not portable. But it still seem to work for me, and maybe someone
    more skilled in coding than me can correct or improve it. I publish it here
    just because I think it does something userful, that for instance is done by
    the ppp implementation of the networking devices I know (from high-end Cisco
    routers down to entry level devices).

    The pppidle program, is only a modification of the pppstats code. One thing
    to note: when pppd is used in dial-on-demand mode, the idle timer always
    grows, independently of the interface being connected to the remote site or
    not. So on passive (not connected) interfaces, you observe high values in
    the idle timer, more then the currently configured idle option.

    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    #if defined(__linux__) && defined(__powerpc__) \
    && (__GLIBC__ == 2 && __GLIBC_MINOR__ == 0)
    /* kludge alert! */
    #undef __GLIBC__
    #endif
    #include /* *BSD, Linux, NeXT, Ultrix etc. */
    #ifndef __linux__
    #include
    #include
    #include
    #else
    /* Linux */
    #if __GLIBC__ >= 2
    #include /* glibc 2 conflicts with linux/types.h */
    #include
    #else
    #include
    #include
    #endif
    #include
    #include
    #endif /* __linux__ */


    int hflag; /* print header */
    int vflag; /* verbose header */
    int interval, count;
    int infinite;
    int unit;
    int s; /* socket or /dev/ppp file descriptor */
    int signalled; /* set if alarm goes off "early" */
    char *progname;
    char *interface;

    #if defined(SUNOS4) || defined(ULTRIX) || defined(NeXT)
    extern int optind;
    extern char *optarg;
    #endif

    /*
    * If PPP_DRV_NAME is not defined, use the legacy "ppp" as the
    * device name.
    */
    #if !defined(PPP_DRV_NAME)
    #define PPP_DRV_NAME "ppp"
    #endif /* !defined(PPP_DRV_NAME) */

    static void usage __P((void));
    static void catchalarm __P((int));
    static void get_ppp_idle __P((struct ppp_idle *));
    static void intpr __P((void));

    int main __P((int, char *argv[]));

    static void
    usage()
    {
    fprintf(stderr, "Usage: %s [-H] [-v] [-c count] [-w wait]
    [interface]\n",
    progname);
    exit(1);
    }

    /*
    * Called if an interval expires before intpr has completed a loop.
    * Sets a flag to not wait for the alarm.
    */
    static void
    catchalarm(arg)
    int arg;
    {
    signalled = 1;
    }

    /************************************************** ******************
    *
    * get_idle_time - return how long the link has been idle.
    */
    int
    get_idle_time(u, ip)
    int u;
    struct ppp_idle *ip;
    {
    return ioctl(s, PPPIOCGIDLE, ip) >= 0;
    }

    /*
    * Print a running summary of interface statistics.
    * Repeat display every interval seconds, showing statistics
    * collected over that interval. Assumes that interval is non-zero.
    * First line printed is cumulative.
    */
    static void
    intpr()
    {
    register int line = 0;
    sigset_t oldmask, mask;
    char *bunit;
    time_t itime;
    struct ppp_idle idle;
    int res;
    int fdppp;
    int ifnum = atoi(interface + strlen(interface) - 1);

    while (1) {
    fdppp = open("/dev/ppp", O_RDONLY | O_NONBLOCK);
    if (ioctl(fdppp, PPPIOCATTACH, &ifnum) < 0) {
    if (errno == ENXIO) {
    close(fdppp);
    printf("Non existent interface unit %d\n", ifnum);
    return ; /* doesn't still exist */
    }
    printf("Couldn't attach to interface unit %d\n", ifnum);
    }

    res = ioctl(fdppp, PPPIOCGIDLE, &idle);

    (void)signal(SIGALRM, catchalarm);
    signalled = 0;
    (void)alarm(interval);

    if (res >= 0 ) {
    itime = MIN(idle.xmit_idle, idle.recv_idle);
    printf("%i\n",itime);
    } else {
    printf("Error in getting idle time\n");
    }

    fflush(stdout);
    line++;

    count--;
    if (!infinite && !count)
    break;

    sigemptyset(&mask);
    sigaddset(&mask, SIGALRM);
    sigprocmask(SIG_BLOCK, &mask, &oldmask);
    if (!signalled) {
    sigemptyset(&mask);
    sigsuspend(&mask);
    }
    sigprocmask(SIG_SETMASK, &oldmask, NULL);
    signalled = 0;
    (void)alarm(interval);
    }
    }

    int
    main(argc, argv)
    int argc;
    char *argv[];
    {
    int c;

    interface = PPP_DRV_NAME "0";
    if ((progname = strrchr(argv[0], '/')) == NULL)
    progname = argv[0];
    else
    ++progname;

    while ((c = getopt(argc, argv, "vHc:w:")) != -1) {
    switch (c) {
    case 'v':
    ++vflag;
    break;
    case 'H':
    ++hflag;
    break;
    case 'c':
    count = atoi(optarg);
    if (count <= 0)
    usage();
    break;
    case 'w':
    interval = atoi(optarg);
    if (interval <= 0)
    usage();
    break;
    default:
    usage();
    }
    }
    argc -= optind;
    argv += optind;

    if (!interval && count)
    interval = 5;
    if (interval && !count)
    infinite = 1;
    if (!interval && !count)
    count = 1;

    if (argc > 1)
    usage();
    if (argc > 0)
    interface = argv[0];

    if (sscanf(interface, PPP_DRV_NAME "%d", &unit) != 1) {
    fprintf(stderr, "%s: invalid interface '%s' specified\n",
    progname, interface);
    }

    {
    struct ifreq ifr;

    s = socket(AF_INET, SOCK_DGRAM, 0);
    if (s < 0) {
    fprintf(stderr, "%s: ", progname);
    perror("couldn't create IP socket");
    exit(1);
    }

    #ifdef __linux__
    #undef ifr_name
    #define ifr_name ifr_ifrn.ifrn_name
    #endif
    strncpy(ifr.ifr_name, interface, sizeof(ifr.ifr_name));
    if (ioctl(s, SIOCGIFFLAGS, (caddr_t)&ifr) < 0) {
    fprintf(stderr, "%s: nonexistent interface '%s' specified\n",
    progname, interface);
    exit(1);
    }
    }

    intpr();
    exit(0);
    }






    The pppd patch to report some infos about the packet that triggered the
    dialup connections. It extends the demand_rexmit function, which retransmits
    the packets that where waiting for a connection to come up. The first packet
    in the queue is the one that triggers the connection. It reports the info in
    syslog, and sets an environment variable, PACKET, that can be used in the
    ip-up script. The code is not portable for sure; it's likely to also be
    buggy; it's also limited to IPv4.

    --- demand.c.orig 2005-06-18 23:04:28.000000000 +0200
    +++ demand.c 2005-06-19 15:25:35.000000000 +0200
    @@ -314,6 +314,48 @@
    prev = NULL;
    pkt = pend_q;
    pend_q = NULL;
    +
    + unsigned char * punta = pkt->data+4; /* begin of IP header */
    + char * pstring;
    + pstring = (char *) malloc( 128 ); /* beware: if more reporting
    options are added, extend the buffer accordingly */
    + if (pstring != NULL) {
    + char * pstr2 = pstring;
    + if(*punta>>4 == 4) { /* IPv4 */
    + int ihl;
    + ihl = *punta & 0xf;
    + unsigned char pcol;
    + pcol = *(punta+9);
    + pstr2 += sprintf(pstr2, "SRC=%d.%d.%d.%d DST=%d.%d.%d.%d
    PROTO=%d", *(punta+12), *(punta+13), *(punta+14), *(punta+15), *(punta+16),
    *(punta+17), *(punta+18), *(punta+19), pcol);
    + switch (pcol) {
    + case 17: /* UDP */
    + punta += ihl*4; /* UDP header */
    + pstr2 += sprintf(pstr2, " SPORT=%d DPORT=%d", *(punta)*256
    + *(punta+1), *(punta+2)*256 + *(punta+3));
    + break;
    + case 6: /* TCP */
    + punta += ihl*4; /* TCP header */
    + int optio;
    + optio = *(punta+13) & 0x3f;
    + if( optio & 0x2 ) pstr2 += sprintf(pstr2, " SYN");
    + if( optio & 0x10 ) pstr2 += sprintf(pstr2, " ACK");
    + if( optio & 0x1 ) pstr2 += sprintf(pstr2, " FIN");
    + if( optio & 0x4 ) pstr2 += sprintf(pstr2, " RST");
    + if( optio & 0x8 ) pstr2 += sprintf(pstr2, " PSH");
    + if( optio & 0x20 ) pstr2 += sprintf(pstr2, " URG");
    + pstr2 += sprintf(pstr2, " SPORT=%d DPORT=%d", *(punta)*256
    + *(punta+1), *(punta+2)*256 + *(punta+3));
    + break;
    + case 1: /* ICMP */
    + punta += ihl*4; /* ICMP header */
    + pstr2 += sprintf(pstr2, " TYPE=%d CODE=%d", *(punta),
    *(punta+1));
    + break;
    + default:
    + break;
    + }
    + }
    + notice("Dumped Triggering packet %s", pstring);
    + script_setenv("PACKET", pstring, 0);
    + free(pstring);
    + }
    +
    for (; pkt != NULL; pkt = nextpkt) {
    nextpkt = pkt->next;
    if (PPP_PROTOCOL(pkt->data) == proto) {



  13. Re: Info on dialout connections


    "Unruh" writes:
    > "Lux" writes:
    >
    > >"Unruh" writes:
    > >>
    > >> You would have to rewrite pppd to do this. Good luck.

    >
    > >For sure I'm not able to do this task (and it would seem to me a loss of
    > >time and resources since the ppp package already behaves well) but may I

    ask
    > >you why I would have to do so? There is an option, kdebug, that makes the
    > >ppp layer to dump every packet to syslog. I supposed there could be a way

    to
    >
    > No. kdebug is defunct in 2.4.2 pppd. And this is horrible. it is like the
    > idle timer option-- far too much data.


    As you can see in my previous posting, the data is already there, it is
    sufficient to ask the ppp layer.

    > >(or something could be done to) make it dump only the particular first
    > >packet that triggers a dialing call. But maybe the call is performed by

    the
    >
    > Yes. You would have to rewrite pppd to do this. good luck.


    Still wondering why I should have to rewrite pppd to accomplish this task.
    As you can see in my previous posting, I only had to add some few lines of
    code to what already is functioning. If I did not write the (poor) packet
    decoder, the lines needed to do it would have been 3-4.

    > >userspace pppd, which actually does not know about the packets that are

    to
    > >be forwarded?

    >
    > Unless I am very mistaken, pppd does not have anything now to do this. You
    > would have to rewrite pppd to do this. Good luck.
    > Is someone else going to rewrite pppd do do this for you? If you paid
    > enough sure. Otherwise highly doubtful.


    For sure, I would be happy to pay someone a reasonable price to implement
    correctly the features I was looking for. For sure, I would not pay someone
    to rewrite pppd when writing a few dozens of lines of code would be
    sufficient.
    Please note that I asked for these features because they seem useful to me,
    though not strictly vital for ppp operations. Because it seems stupid to me
    to reinvent the wheel every time, I asked first if someone knows of an
    existing way to do what I was looking for.






  14. Re: Info on dialout connections

    Corrected version which opens /dev/ppp only once (hey, I advised that the
    code is buggy)

    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    #if defined(__linux__) && defined(__powerpc__) \
    && (__GLIBC__ == 2 && __GLIBC_MINOR__ == 0)
    /* kludge alert! */
    #undef __GLIBC__
    #endif
    #include /* *BSD, Linux, NeXT, Ultrix etc. */
    #ifndef __linux__
    #include
    #include
    #include
    #else
    /* Linux */
    #if __GLIBC__ >= 2
    #include /* glibc 2 conflicts with linux/types.h */
    #include
    #else
    #include
    #include
    #endif
    #include
    #include
    #endif /* __linux__ */


    int interval, count;
    int infinite;
    int unit;
    int s; /* socket or /dev/ppp file descriptor */
    int signalled; /* set if alarm goes off "early" */
    char *progname;
    char *interface;

    #if defined(SUNOS4) || defined(ULTRIX) || defined(NeXT)
    extern int optind;
    extern char *optarg;
    #endif

    /*
    * If PPP_DRV_NAME is not defined, use the legacy "ppp" as the
    * device name.
    */
    #if !defined(PPP_DRV_NAME)
    #define PPP_DRV_NAME "ppp"
    #endif /* !defined(PPP_DRV_NAME) */

    static void usage __P((void));
    static void catchalarm __P((int));
    static void get_ppp_idle __P((struct ppp_idle *));
    static void intpr __P((void));

    int main __P((int, char *argv[]));

    static void
    usage()
    {
    fprintf(stderr, "Usage: %s [-c count] [-w wait] [interface]\n",
    progname);
    exit(1);
    }

    /*
    * Called if an interval expires before intpr has completed a loop.
    * Sets a flag to not wait for the alarm.
    */
    static void
    catchalarm(arg)
    int arg;
    {
    signalled = 1;
    }

    /*
    * Print a running summary of interface statistics.
    * Repeat display every interval seconds, showing statistics
    * collected over that interval. Assumes that interval is non-zero.
    * First line printed is cumulative.
    */
    static void
    intpr()
    {
    register int line = 0;
    sigset_t oldmask, mask;
    char *bunit;
    time_t itime;
    struct ppp_idle idle;
    int res;
    int fdppp;
    fdppp = open("/dev/ppp", O_RDONLY | O_NOCTTY);
    if (fdppp == -1) {
    printf("can't open( /dev/ppp )\n");
    exit(1);
    }


    int ifnum = atoi(interface + strlen(interface) - 1);
    if (ioctl(fdppp, PPPIOCATTACH, &ifnum) < 0) {
    if (errno == ENXIO) {
    close(fdppp);
    printf("Non existent interface unit %d\n", ifnum);
    return ; /* doesn't still exist */
    }
    printf("Couldn't attach to interface unit %d\n", ifnum);
    }

    while (1) {

    res = ioctl(fdppp, PPPIOCGIDLE, &idle);

    (void)signal(SIGALRM, catchalarm);
    signalled = 0;
    (void)alarm(interval);

    if (res >= 0 ) {
    itime = MIN(idle.xmit_idle, idle.recv_idle);
    printf("%i\n",itime);
    } else {
    printf("Error in getting idle time\n");
    }

    fflush(stdout);
    line++;

    count--;
    if (!infinite && !count)
    break;

    sigemptyset(&mask);
    sigaddset(&mask, SIGALRM);
    sigprocmask(SIG_BLOCK, &mask, &oldmask);
    if (!signalled) {
    sigemptyset(&mask);
    sigsuspend(&mask);
    }
    sigprocmask(SIG_SETMASK, &oldmask, NULL);
    signalled = 0;
    (void)alarm(interval);
    }

    close(fdppp);
    }

    int
    main(argc, argv)
    int argc;
    char *argv[];
    {
    int c;

    interface = PPP_DRV_NAME "0";
    if ((progname = strrchr(argv[0], '/')) == NULL)
    progname = argv[0];
    else
    ++progname;

    while ((c = getopt(argc, argv, "c:w:")) != -1) {
    switch (c) {
    case 'c':
    count = atoi(optarg);
    if (count <= 0)
    usage();
    break;
    case 'w':
    interval = atoi(optarg);
    if (interval <= 0)
    usage();
    break;
    default:
    usage();
    }
    }
    argc -= optind;
    argv += optind;

    if (!interval && count)
    interval = 5;
    if (interval && !count)
    infinite = 1;
    if (!interval && !count)
    count = 1;

    if (argc > 1)
    usage();
    if (argc > 0)
    interface = argv[0];

    if (sscanf(interface, PPP_DRV_NAME "%d", &unit) != 1) {
    fprintf(stderr, "%s: invalid interface '%s' specified\n",
    progname, interface);
    }

    {
    struct ifreq ifr;

    s = socket(AF_INET, SOCK_DGRAM, 0);
    if (s < 0) {
    fprintf(stderr, "%s: ", progname);
    perror("couldn't create IP socket");
    exit(1);
    }

    #ifdef __linux__
    #undef ifr_name
    #define ifr_name ifr_ifrn.ifrn_name
    #endif
    strncpy(ifr.ifr_name, interface, sizeof(ifr.ifr_name));
    if (ioctl(s, SIOCGIFFLAGS, (caddr_t)&ifr) < 0) {
    fprintf(stderr, "%s: nonexistent interface '%s' specified\n",
    progname, interface);
    exit(1);
    }
    }

    intpr();
    exit(0);
    }



+ Reply to Thread