Hi,

On Fri, 7 Mar 2014 14:56:25 Patrik Flykt wrote:
> On Fri, 2014-03-07 at 15:18 +1000, Aaron McCarthy wrote:
> > The previous data counters used unsigned 32 bit types. This is
> > probably adequate for most of the data fields, but for the bytes
> > received and bytes transmitted it means that the counters wrap after
> > 4GB of data. Change to use the 64 bit interface to retrieve the data
> > from the kernel and to use 64 bit types in both the storage and DBus
> > API. This changes the type signature of the DBus interface and expects
> > applications to cope. This changes the binary format of the data
> > files. The record size are now larger and the magic number changed.
> > Both connmand will convert from the old format to the new format.
> > stats-tool has a new -x option to convert the data files.
> 
> I noticed that the stats handling seems to be mostly broken in upstream.
> ConnMan gets IFLA_STATS on a newlink, but at that point we do not yet
> have a service. A service pointer would be needed to send the statistics
> via its notifier. So the stats are not updated at that point.
> 
> ConnMan also gets IFLA_STATS on a dellink, but either the service is
> disconnected or then the technology is disabled, which disconnects the
> service and notifier, and will not re-connect it after that (it only
> does that on service creation). So the stats are not updated at that
> point either.

These two points would cause transferred bytes to not be accounted around 
connect/disconnect? Counters would otherwise be expected to work, if not 
exactly byte accurate.

> What might happen is that one is using an obsolete wext WiFi driver,
> which generates spurious IFLA_WIRELESS events, which cause a
> process_newlink which then perhaps updates the stats. Or, if the WiFi
> goes out of range, it may be that the dellink comes before a service
> disconnect and adds some amount of stats to be written to file.
> 
> Now, a question: do you see any rx, tx values in the stats file(s)? Are
> they even remotely correct? I don't see a single value different than
> zero on my machine. Can you check what the situation is on your
> device(s)?

I get values for both rx and tx bytes. There have been reports of weird values 
which is what originally made me aware of the 32 bit data issue. I will need 
to more accurately measure the transmitted bytes vs the counter values.

> So, if this is the case that stats in practise don't work at all, we can
> very well drop the conversion code and take your patch #1 instead. I
> spotted a couple of places where variables initialization was mixed in
> with the code and in the tools/ function names were missing 'static'.
> Please run this through a compiler, you are perhaps cross-compiling and
> giving the cross-compiler very much different options than expected?
> 'C99' or such seems to have been disabled IIRC.

I've been developing this patch against and older version of Connman. I have 
been testing against Connman 1.21, I will double check this.

-- 
Aaron McCarthy
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman

Reply via email to