I am writing a C program to calculate current bandwidth usage on a data link. I also need the bandwidth of the link.
For wireless links, iwconfig prints the wireless link characteristics which are stored in /proc/net/wireless. However how about data rate of the wireless link? Is it also stored somewhere in the (another)file?
Also for ethernet links, Are there similar files where all the link details are stored?
You should use libnl to query interface information. Don't rely on files under /proc or scrape the output of iw or iwconfig, since their output format might change any time.
If you are curious about the details, check out the source code of iw. It's easy to understand (I used it myself to understand how to query nl80211 for interface info).
So, I solved my problem by reading the tx_bytes and rx_bytes in the statistics directory of each interface. My function is called every 10 seconds. so, I save the current value of tx/rx_bytes in memory and when my function is called the next time, i use the current value and previous value to calculate the data rate.
Related
While I know how to use MIX_OpenAudio.... I wanted to know the use of MIX_OpenAudioDevice function
It takes several arguments... Device name is one of them
So, I want to know that how can we know what the device name is
It says we can use a function i.e. SDL_GetAudioDeviceName()
But how would we know which audio device to choose on every system....
Or is this function only for working with specific audio systems such as realtek or something?
So from how I understand it, MIX_OpenAudio() is already using MIX_OpenAudioDevice(), just using a NULL value for the device parameter (which then defaults to whatever the system uses for sound). The only reason you would need to specify an actual device in that function is if you are expecting your audio data to be in a specific format. Therefore you should already know what it is.
From the docs: (link)
If you aren't particularly concerned with the specifics of the audio device, and your data isn't in a specific format, the values you use here can just be reasonable defaults.
This function allows you to select specific audio hardware on the system with the device parameter. If you specify NULL, SDL_mixer will choose the best default it can on your behalf (which, in many cases, is exactly what you want anyhow). SDL_mixer does not offer a mechanism to determine device names to open, but you can use SDL_GetNumAudioDevices() to get a count of available devices and then SDL_GetAudioDeviceName() in a loop to obtain a list. If you do this, be sure to call SDL_Init(SDL_INIT_AUDIO) first to initialize SDL's audio system!
As the doc says there, SDL_GetNumAudioDevices() will allow you to loop through SDL_GetAudioDeviceName() to see if it exists on the machine.
This would allow you more control over your audio and can save CPU time from converting the data to the exact device. You also must have that device already opened as well.
Also a link to the SDL2 docs.
Hope this helps explain that function.
Is it possible to SET the interface statistics in Linux after it's been brought up? I'm dealing with rrdtool (mrtg) that gets upset by a daily ifdown and ifup which brings the interface counters back to zero. Ideally I would like to continue counting from where I left and setting the interface values to what they were before the interface went down seems to be the easiest path.
I checked writing to /sys/class/net/ax0/statistics/rx_packets but that gives a Permission Denied error.
netstat, ifup, ifconfig and friends don't seem to support changing these values either.
Anything else I can try?
You can't set the kernel counters, no - but do you really need to?
MRTG will usually graph a rate, based on the difference between samples. So your MRTG/RRD will store packets-per-second values every cycle (usually 5min but maybe 1min). When your device resets the counters, then MRTG will see the value apparently go backwards - which will be discounted as out of range, so one failed sample. But, the next sample will work, and a new rate be given.
If you're getting a big spike in the MRTG graph at the point of the reset, this will be due to an incorrect 'counter rollover' detection. You can prevent this by either setting the MRTG AbsMax setting (to prevent this high value from being valid) or (better) by using SNMPv2 counters (where a reset is more obvious).
If you set your RRD file to have a large enough heartbeat and XFF, then this one missing sample will be interpolated, and so your graphs (which, remember, show the rate rather than the total) will continue to look fine.
Should you need the total, it can be derived by sum(rate x interval) which is automatically done by the Routers2 frontend for MRTG/RRD.
Using uClinux we have one of two flash devices installed, a 1GB flash or a 2GB flash.
The only way I can think of solving this is to somehow get the device ID - which is down the in the device driver code, for me that is in:
drivers/mtd/devices/m25p80.c
I have been using the command mtdinfo (which comes from mtdutils binaries, derived from mtdinfo.c/h). There is various information stored in here about the flash partitions including flash type 'nor' eraseblock size '65536', etc. But nothing that I can identify the chip with.
Its not very clear to me how I can get information from "driver-land" into "user-land". I am looking at trying to extend the mtdinfo command to print more information but there are many layers...
What is the best way to achieve this?
At the moment, I have found no easy way to do this without code changes. However I have found an easy code change (probably a bit of a hack) that allows me to get the information I need:
In the relevant file (in my case drivers/mtd/devices/m25p80.c) you can call one of the following:
dev_err("...");
dev_alert("...");
dev_warn("...");
dev_notice("...");
_dev_info("...");
Which are defined in include/Linux/device.h, so they are part of the Linux driver interface so you can use them from any driver.
I found that the dev_err() and devalert() both get printed out "on screen" during run time. However all of these device messages can be found in /var/log/messages. Since I added messages in the format: dev_notice("JEDEC id %06x\n", jedecid);, I could find the device ID with the following command:
cat /var/log/messages | grep -i jedec
Obviously using dev_err() ordev_alert() is not quite right! - but dev_notice() or even _dev_info() seem more appropriate.
Not yet marking this as the answer since it requires code changes - still hoping for a better solution if anyone knows of one...
Update
Although the above "solution" works, its a bit crappy - certainly will do the job and good enough for mucking around. But I decided that if I am making code changes I may as well do it properly. So I have now implemented changes to add an interface in sysfs such that you can get the flash id with the following command:
cat /sys/class/m25p80/m25p80_dev0/device_id
The main function calls required for this are (in this order):
alloc_chrdev_region(...)
class_create(...)
device_create(...)
sysfs_create_group(...)
This should give enough of a hint for anyone wanting to do the same, though I can expand on that answer if anyone wants it.
I need to build a small size tcpdump for the embedded project that I am working on. Since the memory size of my embedded device is limited, I need to strip all the unwanted functionality in the TCPDUMP while building it. My target is make the tcpdump executable size less that 300KB. After using "strip tcpdump option" and disabling package options in the configure, I have reached 750KB. To achieve this, I want to remove all the protocol decoding capability of tcpdump. I want the tcpdump to have no more that hex dump capability. I have a below initial list of unwanted protocols that has to be removed.
print-802_11.c
print-802_15_4.c
print-ah.c
print-ahcp.c
print-aodv.c
print-aoe.c
print-ap1394.c
print-atalk.c
print-atm.c
print-babel.c
print-bootp.C
print-bt.c
print-calm-fast.c
print-carp.c
print-cdp.c
print-cfm.c
print-chdlc.c
print-cip.c
print-cnfp.c
print-dccp.c
print-decnet.c
print-dtp.c
print-dvmrp.c
print-eap.c
print-egp.c
print-eigrp.c
print-enc.c
print-esp.c
print-fddi.c
print-forces.c
print-ipx.c
print-isakmp.c
print-isoclns.c
print-juniper.c
print-krb.c
print-lane.c
print-m3ua.c
print-sip.c
print-sl.c
print-sll.c
print-sunatm.c
print-zephyr.c
print-usb.c
print-vjc.c
print-vqp.c
print-timed.c
print-tipc.c
print-token.c
I started to remove these from Makefile.in and removing the function calls manually in the source code. But then I realized this approach is not scalable.
Is there a better way to do this ? Someway by using configure options?
I am new to this. So please explain.
Is there a better way to do this ? Someway by using configure options?
No, there are no such configure options. You'll have to do it the non-scalable way.
"I want to remove all the protocol decoding capability of tcpdump. I
want the tcpdump to have no more that hex dump capability. [...] Is
there a better way to do this ?"
I think there is, but with a very different approach.
If all you want from tcpdump is:
the capability of specifying an interface,
put this interface on promiscuous mode or not, or monitor mode if it's a Wi-Fi interface,
apply a capture filter,
and then spit the output in a file or as hex to stdout,
...you'd be better write your own from scratch, using libpcap (which is what tcpdump uses BTW).
This should be no more than 100-400 lines of C code depending on the options you want to have, you'll have a very, very small executable, and no more dependencies than tcpdump which require libpcap anyway. All the complexity is in the dissection, once you remove all that, what you have is basically... a pcap loop.
It's not that hard, and looks to me as far less work than your approach - and also more interesting work.
There's a tutorial to start with (30-60 minutes read):
http://www.tcpdump.org/pcap.html
...at the end of this tutorial, you'll already have the core of your program.
And you can find loads of info (and ask questions) in the related SO tags:
https://stackoverflow.com/tags/libpcap/info
https://stackoverflow.com/tags/pcap/info
...and have about 70 well-written man pages documenting the full pcap API (you'll end up using maybe 10-20 of these).
I need a way to get the current "loudness" of a microphone via PulseAudio (via bash). And I mean the volume of the sound that is picked up by the mircophone.
I want to replicate a volume meter, like you see it in pavucontrol.
search on github for the raspberry-vu project as it can help you with this. i changed src/impulse.c to use the device alsa_input.pci-0000_00_1b.0.analog-stereo, you may need to change this for your setup.
i then linked the GNU GSL lib to analyze the FFT array returned by im_getSnapshot() using gsl_stats_sd() and gsl_stats_mean() both of which return a double. you can then react to the value returned.