network stats and events: portable solution for ppp interface

Hi!

I'm trying to do some kind of network monitoring on embedded Linux.

Context:
Embedded Linux, likely with busybox.
Several hardware targets : so the aim is to get a solution as portable as possible (may be an illusion ) : the only common base may be the linux kernel itself.
The devices will have Ethernet and ppp/GPRS interfaces, at least.

First need:
Get stats about network interfaces, especially RX/TX bytes: so I planned to use ipconfig or /proc/net/dev to get those.
I use pppd to mount a GPRS connection through serial port.
(example of use: pppd /dev/ttyS0 115200 modem debug novj usepeerdns lock refuse-chap updetach connect chat'chat options ...' )
I need to get RX/TX stats for this connection.
In my case, when ppp link goes down, the interface totally disappears from "interface tools" like ifconfig -a, /proc/net/dev
However, I need to have RX/TX values for ppp link when interface goes down.

Second need (optional):
I would be happy to have events on network interface status (IP and/or link status)
Ex: knowing that the Ethernet cable is disconnected might be nice for me.



What I have already tried / look for:

- ip-down script for ppp: when the script is called, the interface is already down, RX/TX stats are not accessible from ifconfig or /proc/net/dev
Is there this kind of script registration for interface events other than ppp ?

- netlink socket, using RTMGRP_IPV4_IFADDR | RTMGRP_LINK messages.
For now, I don't see bearers stats (RX/TX) in RTMGRP_IPV4_IFADDR msgs (it makes sense for me), and when ppp interface goes down I've got some confusing msg sequence : NEWADDR ->DELADDR->NEWADDR
I get bearers stats (RX/TX) in some RTMGRP_LINK msgs, but it seems that RTMGRP_LINK messages are really dependant on interface driver.
In deed, ppp interface seems to behave strangely about information given in netlink msg: IFLA_OPERSTATE for instance don't follow http://www.mjmwired.net/kernel/Docum...operstates.txt description, whereas msg related to eth on several devices are way more intelligible.
So, for know, I don't feel confident about my use of netlink sockets.

I hope all of this makes sense.

Thank you by advance for reading this

30 days w/ no replies -- perhaps some clarification would help.

"on embedded Linux" -- Does that mean that the monitoring s/w is running on an embedded Linux box, or that the targets are embedded Linux boxes, or both.

How much control do you have over what is installed on your embedded Linux?

What is your goal here? -- Are you perhaps trying to build a network monitoring appliance?

Hello archtoad6 and thank you for your answer.

I'm trying to do a piece of code than would monitor network interfaces.
The first need is to get RX/TX stats for the network interfaces.
Dealing with ppp interface is mandatory.
Asynchronous events about interfaces (like "Cable unplugged") might be cool but it's not mandatory.

The code will run on embedded Linux targets and will monitor network interfaces present on the device.
(I'm not sure to understand your question "Does that mean that the monitoring s/w is running on an embedded Linux box, or that the targets are embedded Linux boxes, or both."
Sorry if I missed the point.
)

The code should have minimum dependencies on non-standard Linux features as Linux targets may come from different manufacturers with different configurations.
However, I may have some control on what is installed on the target, like asking for activation of some options in busybox for instance (busybox is likely to be present on all "my" target boxes).

For now, I use "-demand" option of pppd daemon.
This makes pppd creating the ppp interface before the ppp connexion is really up and the ppp interface is still registered even if the ppp connexion goes down.
RX/TX stats seem to be accumulated correctly, even after ppp connexion up/down cycles.
As a consequence, I can use ifconfig information for all my interfaces and I left the interface events aside.
But I don't feel to have the same control on that ppp interface that for the other interfaces.

In fact, I was trying to see if I was missing some interesting solution (I thought netlink socket would be that solution) ...