netmon_wce - network tray monitor
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
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
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.
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
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
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
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.
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
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;
}
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
Ok no problem... see if i can slip it in tonight....oooerr missus.
By the way a quick hack was
to give the right output.
mike
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;
mike
#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.
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
yes, another reason to make non-polling the default.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.
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
Standards? Linux?mikeb wrote:Ah so the standard is to not have a standard...I remember similar piddling around with vattery and different machines and systems.
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!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
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
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
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
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
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 . 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.
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 . 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
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
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
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
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
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 -
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).
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 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
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
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
Sure. I don't like puppyisms myself, especially hard coding to /rootmikeb wrote:its not just a slax thing as me pups and related stuff tend to have less puppyisms to make them more generic anyway.
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
Good for youmikeb wrote:Been adrift for a while....
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.mikeb wrote:after the -k fix built cleanly and working happily... seems like a winner
cheers
mike
Puppy Linux Blog - contact me for access