Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 11 Dec 2017, 04:01
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Network
netmon_wce - network tray monitor
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 6 [77 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Author Message
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Mon 13 Jul 2015, 04:51    Post subject:  

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

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
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8660
Location: qld

PostPosted: Mon 13 Jul 2015, 07:12    Post subject:  

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.
iwconfig.png
 Description   they fluctuate quickly, hence slight differences
 Filesize   37.5 KB
 Viewed   411 Time(s)

iwconfig.png


_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Mon 13 Jul 2015, 12:41    Post subject:  

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
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8660
Location: qld

PostPosted: Mon 13 Jul 2015, 16:16    Post subject:  

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:
#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/programming-scripting/195773-get-wireless-statistics-c.html

_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Mon 13 Jul 2015, 16:51    Post subject:  

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

By the way a quick hack was

Code:
   //get wifi quality
         if(*pos) pos++;
         sscanf(pos, "%*d %d", &wiQpc);
      }
//      wiQpc = wiQ * 100;
//      wiQpc = wiQpc / 70;


to give the right output.

mike
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Mon 13 Jul 2015, 17:28    Post subject:  

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. Smile

Hope thats helpful...

mike
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8660
Location: qld

PostPosted: Mon 13 Jul 2015, 17:36    Post subject:  

#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
Back to top
View user's profile Send private message Visit poster's website 
rcrsn51


Joined: 05 Sep 2006
Posts: 11736
Location: Stratford, Ontario

PostPosted: Mon 13 Jul 2015, 18:58    Post subject:  

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.
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8660
Location: qld

PostPosted: Mon 13 Jul 2015, 22:10    Post subject:  

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
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Tue 14 Jul 2015, 02:53    Post subject:  

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
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8660
Location: qld

PostPosted: Tue 14 Jul 2015, 09:03    Post subject:  

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? Laughing

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

_________________
Puppy Linux Blog - contact me for access

Last edited by 01micko on Sat 18 Jul 2015, 06:47; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Tue 14 Jul 2015, 11:34    Post subject:  

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

mike
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Tue 14 Jul 2015, 12:06    Post subject:  

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
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8660
Location: qld

PostPosted: Fri 17 Jul 2015, 19:04    Post subject:  

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 Very Happy . 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/2948538/variable-timeouts-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
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 11077

PostPosted: Sat 18 Jul 2015, 04:16    Post subject:  

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 Very Happy

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
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 6 [77 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Network
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0855s ][ Queries: 14 (0.0194s) ][ GZIP on ]