netmon_wce - network tray monitor

Configuration wizards, scanners, remote desktop, etc.
Message
Author
User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#16 Post by mikeb »

Ah slick stuff.... I did hear a rumour /var/log was under threat in these 'ere parts ;)

will test soon as...

mike

edit

quick test patched and built and working ok... lan fine..message ok.. will test wifi later.
Will also peek at lamewifi source and see if I can shed some light on the difference.
Noticed you moved the icons...perhaps its own folder in pixmaps would be neat.... eg /usr/share/pixmaps/netmon

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#17 Post by 01micko »

Ok, looking forth to the wireless test.

While you are there, give iwconfig and cat /proc/net/wireless a run to see if we can't find your bug.
Attachments
iwconfig.png
they fluctuate quickly, hence slight differences
(37.5 KiB) Downloaded 579 times
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#18 Post by mikeb »

Ok did the wireless test......

The clue...the results from iwconfig and cat give a percentage readout and NOT the n/70 that yours show.
This was lucid and standard lucid kernel by the way.

So it appears to be to do with the way the kernel and iwconfig present the information has changed...or that's my assumption.

Well I noticed the /70 factor adjustment in the sources so perhaps something a builder could adjust depending on the destination system.

mike

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#19 Post by 01micko »

Thanks Mike. Ah. so that explains that.

What I noticed is that Patriots version doesn't really use <ioctl.h>, <linux/wireless.h> and friends so those headers are redundant. However, I did mod the program (not ready yet) to use these headers.

If you want to compile and run the following this *should* output the quality of your wireless, however I suspect it won't make a difference. Check and see if you don't mind.

Code: Select all

#include <sys/types.h>
#include <sys/socket.h>
#include <linux/wireless.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

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

    int sockfd;
    struct iw_statistics stats;
    struct iwreq req;

    memset(&stats, 0, sizeof(stats));
    memset(&req, 0, sizeof(req));
    sprintf(req.ifr_name, "wlan0"); // for debug, hardcode the iface
    req.u.data.pointer = &stats;
    req.u.data.length = sizeof(stats);
#ifdef CLEAR_UPDATED
    req.u.data.flags = 1;
#endif


    if((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
    {
        perror("socket failed");
        exit(EXIT_FAILURE);
    }

    if(ioctl(sockfd, SIOCGIWSTATS, &req) == -1)
    {
        perror("ioctl SIOCGIWSTATS failed");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    close(sockfd);

    printf("qual: %d\n",
        (int)((char)stats.qual.qual));

return 0;
}
That cast in the 'printf' is important as the kernel has its own type called __u8, which essentially is just an unsigned char, so we cast to char then int so we can work with it.

I still don't understand the pre-processor call, and until I do it stays I suppose. However I'm thinking it's irrelevant in the context of this program because we don't need any member of any type named 'flags'.

Just be aware to hard code your iface if it isn't wlan0.

ref: http://www.linuxforums.org/forum/progra ... ics-c.html
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#20 Post by mikeb »

Ok no problem... see if i can slip it in tonight....oooerr missus.

By the way a quick hack was

Code: Select all

	//get wifi quality
			if(*pos) pos++;
			sscanf(pos, "%*d %d", &wiQpc);
		}
//		wiQpc = wiQ * 100;
//		wiQpc = wiQpc / 70;
to give the right output.

mike

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#21 Post by mikeb »

Ok built and tested

needed
#include <sys/ioctl.h>
#include <sys/socket.h>

and one for close() ..not sure which...again might be system variations...

The resultant output agreed with lame wifi this time. :)

Hope thats helpful...

mike

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#22 Post by 01micko »

#include <unistd.h>

maybe my newer sys/socket.h drags the others in.

Ok, so you get same output all the time, so I wont bother adding that method but think of some other way so we don't have to alter the code.
Puppy Linux Blog - contact me for access

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#23 Post by rcrsn51 »

Be aware that not all Linux WiFi drivers report their signal strength in a consistent manner. For example, the popular rtl8188eu driver always reports its strength as zero, both in iwconfig and /proc/net/wireless.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#24 Post by 01micko »

rcrsn51 wrote:Be aware that not all Linux WiFi drivers report their signal strength in a consistent manner. For example, the popular rtl8188eu driver always reports its strength as zero, both in iwconfig and /proc/net/wireless.
yes, another reason to make non-polling the default.

Well, after a bit of a headache I found out how wireless-tools (in libiw) finds the '70' that seems to be the default for a lot of wireless chip drivers including most of the ones I own. Now that I know that I can use the previously posted routine in the code and cache that value, if it exists. This creates another dependency however it doesn't add much to the binary - <libiw.h> and a ld needs -liw on the linker line.

If it doesn't exist we assume 100 (probably Mike's case, and Patriot's original case) and if we get stupid values like zero we don't do any division. If stupid values like over 100% show up just pop a message in the tooltip like 'wireless stats don't work, revert to standard' - so yes, will be going with non-polling as default and probably enable polling as a menu entry.
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#25 Post by mikeb »

Ah so the standard is to not have a standard...I remember similar piddling around with vattery and different machines and systems.

Well at least you have something to chew on....like your left ankle in this case...

thanks for the efforts on this one...

mike

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#26 Post by 01micko »

mikeb wrote:Ah so the standard is to not have a standard...I remember similar piddling around with vattery and different machines and systems.
Standards? Linux? :lol:
mikeb wrote:Well at least you have something to chew on....like your left ankle in this case...

thanks for the efforts on this one...

mike
Okie .. chewed thru the ankle and here is tha latest src package. I'll be away for some days so giving it a soak test on my lappy with the stats running - see if leaks much!

Notes;

- the patch is still there and _might_ apply cleanly as I haven't updated it.

- the default is non-polling mode (wireless) - change that in the right click menu. Wired mode shouldn't show any differently.

- uses the routine (roughly) posted earlier and links to libiw - you may well need shared libiw (re slax - if it uses slackware's static iw)

- don't know if headers are ok - let me know and I will put in some pre-processes

- slowed the polling slightly as in the context of the program it's not possible to change that value on the fly (which would have been nice for wireless - maybe that needs a cli option)

Have fun :wink:

attachment deleted
Last edited by 01micko on Sat 18 Jul 2015, 10:47, edited 1 time in total.
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#27 Post by mikeb »

Nice one...will give it a spin later hopefully.

mike

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#28 Post by mikeb »

Ok did not patch or fiddle and it built cleanly on thee slax using its static libiw.

Running as expected...if wifi polling enabled it gives the correct value.

So you are handling the wifi quality readings ok then... so would polling on as default actually be an ok option if its working as desired?

Enjoy your break

mike

edit...patch was stretched too far so made the changes manually...its evolving anyway so no worries.
By the way dhcpcd -k %s seems universal..I found some that did not use --release

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#29 Post by 01micko »

Hi Mike and those interested,

Well after the 3 days ran htop -p `pidof netmon_wce` and all was sweet. 1.3% mem usage which was the same when I left so, pretty much no leakage :D . My lappy is running 64 bit OS and is only harbouring 1 GB shared RAM.

So now I've integrated the wireless stuffs and added the ability to start it from a symlink if you want to default to wireless polling. The menu entry is still there. AND.. I found out how to change the 'interval' on the fly! A very handy feature so that we don't choke the thing when using polling. The default I'm using is 2 seconds, but I reckon 5 seconds is plenty much. See - ptomato's post http://stackoverflow.com/questions/2948 ... ts-in-glib
(BTW - replaced the deprecated gtk_timeout_add with g_timeout_add a few iterations ago).

Before I publicise though, I'm going to add back a feature that was half pie there before: monitoring of multiple interfaces. It won't be fully supported by the icon, however, it will be in the tooltip, and also in the right click menu.

For example, you may have eth0, wlan0 and usb0 all connected and active at once. It would be nice to connect and disconnect each one eh? And also have the tooltip for each one too eh? For this I'll ditch using the 'connection manager' (which could be any number of progs in puppyland) and access dhcpcd (and options) directly for each iface.

Then I'll let this out in the wild, maybe even binary packaged, for further evaluation.

Cheers!

EDIT: no - too ambitious, not enough time. I like it how it is anyway so I'm glad I removed the half pie support. If you plug something else and get an IP it updates anyway, so that's enough.
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#30 Post by mikeb »

Nice one....

well only time I would think of multiple instances would probably involve internet sharing so readings etc would be a little pointless...ie you only want to know what the internet traffic is.

Sounds like a winner and long overdue integrated wifi monitoring.

I also think less manic polling is fine...after all you only want a general idea of signal quality unless you are jogging or something :D

Direct dchpcp handling seemed fine and made sense and as mentioned is more generic..... plus its basically a monitor rather than a full blown network control center... oh the potential power muh haw haw...


mike

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#31 Post by 01micko »

New version is out, pets included. See main post

New features as described in the past couple of posts are added (not multiple interfaces - too much trouble). I didn't go with dhcpcd directly however, the patch is updated and that does deal with dhcpcd directly.


-------


@mikeb

Here is one line for your slax installs, and may even install with installpkg, even though it doesn't produce a legit slackware package -

Code: Select all

sh patch_me.sh yes please && make && sh package non-pup
See the 'package' script for more details.

See the extras dir for hints on getting the tx and rx stats saving at shutdown. That is basically what is in puppy's rc.shutdown script and has been for several years (circa 2010).
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#32 Post by mikeb »

Well much appreciated...

its not just a slax thing as me pups and related stuff tend to have less puppyisms to make them more generic anyway.

Plus puppyisms vary somewhat as you well know so I aim for the 'work for anything' approach when possible.

Well will be testing out if I can drag myself away from this rather nice escape we are at up a river where the world cannot find us though the mosquitoes seem to find us regardless... :)

mike

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#33 Post by 01micko »

mikeb wrote:its not just a slax thing as me pups and related stuff tend to have less puppyisms to make them more generic anyway.
Sure. I don't like puppyisms myself, especially hard coding to /root :twisted:

BTW, I think I forgot to switch dhcpcd -k (from --release). You should be able to edit the patch ok - but no guarantees.

Thanks for your testing and suggestions - been a valuable contrib. :)
Puppy Linux Blog - contact me for access

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#34 Post by mikeb »

Been adrift for a while....

after the -k fix built cleanly and working happily... seems like a winner :)

cheers

mike

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#35 Post by 01micko »

mikeb wrote:Been adrift for a while....
Good for you :)
mikeb wrote:after the -k fix built cleanly and working happily... seems like a winner :)

cheers

mike
Good. I'll probably edit the source at some point and bring out a more or less 'final' version, pending any bug reports. I'm pretty happy with it. Been running on my lappy ever since the last mention and ram/cpu is consistent so no evidence of any leakage.
Puppy Linux Blog - contact me for access

Post Reply