I cross-compiled NET-SNMP 5.7.1 from sources to a PowerPC using ELDK-3.1.
When I try to load the snmpd daemon in my embedded board, I see the message:
# snmpd -f -Lo
pcilib: Cannot open /proc/bus/pci
pcilib: Cannot find any working access method.
Of course my PPC board has no PCI, and I wonder why is netsnmp looking for it.
In more than one place I see this same message (sourceforge, mail-archive, google-groups), but ir has no answer at all. Another variant, with a little but unhelpful responses at (archlinuxarm).
Can anybody please help me?
I'm assuming you're on a Linux target.
Net-SNMP's changelog lists "[PATCH 3057093]: allow linux to use libpci for creating useful ifDescr strings".
The configure script will search for an available libpci, and, having found one, will define
HAVE_PCI_LOOKUP_NAME and HAVE_PCI_PCI_H. To disable this code: after configuring, you can change those defines in include/net-snmp/net-snmp-config.h, then rebuild. The affected code is in agent/mibgroup/if-mib/data_access/interface_linux.c.
There's also a patch in this bug report: http://sourceforge.net/p/net-snmp/bugs/2449/
I resolved the issue using the stock snmpd that comes with the Raspbian.
In /etc/snmp/snmpd.conf file I isolated the issue to the following line
agentAddress udp:161,udp6:[::1]:161
Instead of listening on all interfaces, if I specify the the ip address of the eth0 interface i.e.:
agentAddress udp:10.0.1.5:161,udp6:[::1]:161
Then snmpd starts fine.
My speculation is that the stock snmpd tries to enumerate all possible interfaces including the pci ones.
Related
I'd like to get the raw multitouch data from my touchpad in order to.
I've tried using libevdev but my success was limited and I couldn't do what I wanted. I found out about libinput which might be more abstracted, and found out how to use it to automatically get the gestures (for example using libinput-debug-events) but I find them limited and would like to get the raw input (with each finger's movement).
Is there any way to do this with libinput, or not?
I couldn't find any helpful documentation: I found this one but couldn't find any example or route to follow. Actually, I think that I could make myself a way through my problems if I understood how to use these functions, but it's far from clear, and I'm getting in a lot of trouble installing libinput itself (for example, commands like libinput debug-gui aren't recognized by my system).
Any help is appreciated.
Don't know if this helps or not, but on my distro (Ubuntu) I installed libinput-tools.
sudo libinput debug-gui
Also gives me an error:
debug-gui is not a libinput command or not installed.
However,
sudo libinput debug-events
will print out events in the terminal just fine.
My main reference is http://lxr.free-electrons.com/source/include/uapi/linux/nl80211.h
Let's say I want to call NL80211_CMD_TRIGGER_SCAN documentation says trigger a new scan with the given parameters NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the probe requests at CCK rate or not.
I am looking at some source I found online, but it does not work and I would
So how do I know what to put into message?
I am using libnl to comunicate with kernel
I found some answers online that put a little light on this, but it's still a dark alley to me. Here are some:
Using nl80211.h to scan access points
how to use the libnl library to trigger nl80211 commands?
I ran into the same issues working from a Python perspective. From personal experience, the iw source code sucks. You'd be better off doing
strace -e trace=network -f -x -s 4096 iw ...
I built a simple parser and copying and pasting the output, I was able to figure out what nl80211 command and attributes along with values were being sent and then see what the response was.
I'm working on an embedded Linux system that has a specific I2C platform driver and I'm writing a custom I2C driver. Everything works fine, but I have a problem with their dependencies.
As my custom driver uses the default I2C functions, once I compile it, the make command automatically updates the modules.dep file saying that my driver depends on i2c-core to run, but that is not enough. In order to i2c-core to be configured I need to load i2c-omap first (the platform's driver) and only then my driver works properly.
Unfortunately, I can't find any dummy function to call and thus trick the make into adding another dependency when it generates my driver. Also, I would prefer an automated solution instead of modifying modules.dep with something like sed -i 's/RE1/RE2/' modules.dep.
So, is there any way to explicitly add a dependency to a module when I compile it?
Thanks!
I found an answer here: http://www.xml.com/ldd/chapter/book/ch11.html
I solved my problem calling
request_module("i2c-omap");
Anyway, this does not exactly update the dependencies file as I first intended. If anyone knows a way to do that, please add a comment here!
how to get harddrive serial number(not the volume # wich change at each reinstall of windows) in C or asm, without wmi (cause wmi required admin right). Any clue would be helpfull cause right now i found nothing on web in C without wmi, in dayss of searching... Thank you.
EDIT : For windows system
Please try my open source tool, DiskId32, which also has the source code at http://www.winsim.com/diskid32/diskid32.html . I only have an Win32 version at this time. Maybe some day I will add a Win64 version.
Hard drive serial number and other information about the harddrive like firmware version, etc. can only be obtained using SMART as far as I know and that requires special ioctls to the the block device node (/dev/sda or /dev/sdb) which is usually not available to a regular user.
I know there is a tool called smartctl which does exactly this:
sudo smartctl -i /dev/sda
Similar tools exist (hdparm, lshw, etc.) as well.
As far as trying to figure it out this info without being a privileged user, it might be possible only if it is exposed via /proc or /sys which I highly doubt is being done in the current SATA block device drivers.
Im using ARMv7 as a target machine. I have compiled the Linux source 2.6.34.13 for target.
Target is connected with Host(Linux Development machine) through serial port using minicom.
Target is loaded with new kernel and KGDB is enabled in command prompt.
$ echo ttyAMA0 > /sys/module/kgdboc/parameters/kgdboc
$ echo g > /proc/sysrq-trigger
Entering KGDB... message is displayed and waits for commands.
In Host side,
$arm-none-linux-gnueabi-gdb vmlinux
gdb > set remotebaud 115200
gdb > set debug remote 1
gdb > target remote /dev/ttyS0
After this, some command communication takes place by default.
qSupported is sent from Host to Target. But qSuppoted is not supported by target so $#00 is returned. similarly ?, HC-1 commands were sent but receives proper response.
But qOffsets command not receiving any response from target.
I suspect vmlinux. Because if I give list in gdb, its not showing 10 lines of code instead it says
arch/arm/kernel/head.S : No such file or directory.
Note :: Kernel compilation done in server. so no source is available in development machine. But arm-gdb looks for head.S it seems.
I am not sure what mistake im doing. I need symbols to be loaded for entire kernel. Guide me in this regards.
That kgdb is looking for head.S is not an error. If you look here you will see that there is a head.S file in the source tree. It's an assembler file that's all. There are several source files written in assembler for this platform.
It is normal, because some instructions especially boot sequences and other "low-level" functionalities are written in assembler because it is easier.
As written in the comments already, gdb needs the sources to browse them while debugging. In the debug-sections, which contain the debug-symbols and are generated when running gcc with -g, there are "only" references to the source-file and line and column, amongst others. See here for more information and further links about debug-symbols with gcc.
That kgdb is looking for head.S is a good sign that you're doing things right. If you have the sources available (and it can be as simple as untarring the tarball of the right version) just run kgdb inside this source-tree or use the -d argument to add source-search-path, being on your development machine of course.
Finally Host to Target communication established just bcos of line delay. There is no relationship between kernel source in development machine and time-out issues.
For the time-out kind of issue for some of the commands say qOffset and qSupported is solved by using GtkTerm instead of minicom as the serial port communication tool.
Difference is "line delay" option in GtkTerm. so when this is configured to ~250, there is no timeout message thereafter. simply connection established and waits at default break point. If anyone knows how to give this "line delay" in minicom will be more helpful to everyone.
yes ofcourse, we need source code for list command to execute. but without those source also, we can debug i.e si, bt can be executed with the help of vmlinux and system.map.
Note:: set debug remote 1 is not necessary. This gives detailed display of host to command communications. For more detailed view, set debug serial 1.