I'm programming in C with Anjuta a small application with libusb library.
libusb has need the write rights for some purpose.
This argoment was already dealt in this topic: "Get access to USB device on Linux (libusb-1.0)?".
Maybe the topic solution work fine (I'm not tried yet) but i would like my application access to all usb device and not to the specific one.
i've tried to set a suid bit at a libusb-1.0.so file which have a root owner but libusbopen function, for example, answer "libusb requires write access to USB device nodes" again.
I don't wont to build the entire anjuta project as root user but so far this is the only solution for this libusb-1.0 issue.
Is there a solution for get write access to inode of a general usb device (for example hot plug pendrive) without modify udev behavior?
I have found a workaround. Maybe it's not good but it seems to work well.
I have added a permission rules file (020_permissions.rules) in the udev configuration directory (/etc/udev/rules.d) where the unique rule is which Unix group should own all the USB device nodes.
The file content is:
SUBSYSTEM=="usb", GROUP=="group to belong my user"
I hope this helps you if you have a similar libusb issue.
Related
I can find nothing on how to do this. I am programming an Intel Edison in C and an Android phone in Java. I want to pair the Edison from the Android phone. I would think simple pairing (sspmode 1) would work but I get an error message on the phone about a wrong pin where no pin was requested. With sspmode 0 I get asked for a password but have no idea what it is as it is randomly generated in my NoInputNoOutput Edison. We have everything else working. If we pair from Edison manually, the rest of the code can connect and send bluetooth messages back and forth from the Edison to the phone. But pairing from Edison to any random phone that walks by is not acceptable. I think it is called Bluejacking.
I have seen some posts about using simple-agent but frankly what I understand is that BlueZ security changed so much between 4 and 5 that most all that I see doesn't work. I also see that the switch from 4 to 5 broke a lot of systems so I don't feel alone. I would try it but simple-agent is not on Edison and I have not found a procedure to install it. And as I don't know if the little I can find applies to version 5 as it all references version 4 I am feeling a little lost.
Can anyone point me in the right direction to something that will work on BlueZ 5? I am on 5.18.
The solution presented on the last post of this article does work
http://www.linuxquestions.org/questions/linux-wireless-networking-41/setting-up-bluez-with-a-passkey-pin-to-be-used-as-headset-for-iphone-816003/
Edit simple-agent, put it somewhere, make it executable, put the missing files in the same directory and run it. It must stay running for it to be active.
In my case, the missing file was bluezutils.py.
Run hciconfig hci0 sspmode 0 first
Pl use Bluz5.30.
Initially it was really difficult to bring up bluetooth using Bluez 5. It seems it was okay with Bluez 4.I have tried different versions of Bluez 5 on my LFS build. Even up to Bluez 5.28 it was not satisfactory. Now it is Bluz5.30, with this, LFS doc and lot of trail, I could manage. I feel Bluez is one of the most badly documented user unfriendly software. I also feel it is very buggy. It can hang machines forcing to hard boot the system. I have seen bluetooth forcing the Android phone also to reboot. So it is important to get the latest version of the software. But to make the bluetooth speaker work Pulseaudio was needed. It is better to get the latest version; here also LFS doc was fine.
So the process of connecting speaker was using bluetoothctl is as follows;
>> power on
>> scan on
>> pairable on
>> pair <device>
>> agent on
>> default-agent
Now the actual sound. Here pactl and pacmd are useful.
paplay -d can test the devices.
using pacmd with command 'list-sinks' can show the devices.
pacmd ->list-modules can show the modules loaded.
How to change automatically the audio output to bluetooth speaker when it is connected?
For me in one machine it was working fine, with an identical LFS in another machine it was not working. Finally it was identified as a
missing module module-device-manager with arg do_routing=1.
Once it was loaded everything was fine. This particular module was not shown in the pulse configurations. So I have to find that and load,
pacmd
load-module module-device-manager do_routing=1
One can add a line in the default configuration file available in /etc/pulse.or one can add it in the user configuration file also.Now to make the new bluetooth speaker being used to play sound. For that issue the command 'move-sink-input ' using pacmd. You can find the sink names my issuing the command 'list-sinks'.
If your speaker is not connecting, it may be that it is already connected elsewhere. If it is not so, remove-device; scan on; pair; and connect using bluetoothctl. I was worrying how to make file transfer using bluetooth (Bluez5). Actually very little information is available in LFS documention or in general in the NET. This very true and unfortunate about Bluez in general. They do not provide any real user doc or nothing is available in net. So the steps are as follows:
You need to install OBEX library. Then you build Bluez5 (if it not done already). It will install obexd. After installation you can find obexd in $PREFIX/libexec/bluetooth/obexd.This is where you find bluetoothd also. One generally makes a link for bluetoothd in /usr/sbin. A similar link can be made for obexd also. Once you start bluetoothd and obexd you can find object transfer profiles in bluetoothctl->show.If you need a phone to push objects to the computer, you need to run obexd with options '-a' and '-r '. if '-a' is not given phone will fail to send the file. Now how to push a file from Computer to Phone. For this you need obexctl, I do not think it is a finished tool, and it will not be installed while we build Bluez 5. I have seen it in the source tree and copied to /usr/bin/. It should be used to connect the Phone and when the connection is established one can 'send ' and you have to accept the request in the phone.
Starting obexd as a deamon was a problem. When obexd was tried on a text terminal (init 3) it was not possible to start since it needs a dbus session which in turn needs X display. It means one need to login an X seession before you start obexd. If you dissable X while building DBUS (--without-x) then Window Managers will not work. But there is solution with 'dus-run-session < command> [args]'. That means you can start a service obexd (like bluetoothd) in the system start-up. So just by switching on the Computer ( if pairing, trusting etc... was done earlier) one can push files from Phone to computer.
>> connect <device>
Second time onwards just connection is fine. Probably you can trust the device.
>> trust <device>
I'm trying to sideload Lollipop onto my Nexus 5 from the OTA zip file.
At this point, the adb recognizes the device after I plug in the USB cable, and spits out the serial number.
As I understand the instructions for sideloading, once I get to this point, I just need to reboot into recovery mode, (which works as expected) and then bypass the red exclamation point icon using "volume up and power" simultaneously. That works too.
At the point where the screen on the Nexus 5 says, "Now send the package you want to apply to the device with 'adb sideload <filename>' I type "adb sideload + the OTA image file name", which I renamed for convenience". The file is in the platform-tools folder.
At which point the command window reports: error: device not found
So... the device is seen by the adb, but somehow is no longer found after the device reboots in recovery mode.
I've replaced all the usb drivers, enabled usb debugging and developer mode on the Nexus device. I've tried this in windows 7 and also in Linux (both from the android sdk tool kit and from an installation of Eclipse). I'm unable to get the adb to talk to the Nexus 5.
I read the android-windows usb inf file, and there is no section specifically for the Nexus 5, but I added a line under the "generic android" section with USB\VID_18D1&PID_D001 as has been suggested elsewhere for people who couldn't get the OS to see their nexus at all. My issue is not that the OS can't see it... and the adb sees it, too, until I try to sideload the OTA file in Recovery Mode.
Anyone else having this issue, or better yet... any ideas on how to solve it?
Thanks
It turns out that I had not enabled USB debugging before I tried to do this using Linux Ubuntu / Eclipse / Android SDK. So my problem was really a windows USB driver problem, I guess (though I can't be sure, since windows did see the device until I tried to transfer the file. Maybe that message was really conveying a permissions problem, too...)
I rebooted into Ubuntu and tried again and was able to transfer the update file. The only hitch I encountered at that point was to issue the sideload command as root. I didn't do that the first time I tried it, and got a message about lacking permissions.
I suspect the posted reply with a link to a universal USB inf file would have worked, but, though I'm grateful for the tip, I can't testify to that, since I managed to transfer the file without Windows.
Thanks to all who looked at this and especially to Alex P., for posting a possible solution. FW
IW, I'm glad to have finally been able to do this, but for anyone struggling to get Lollipop ahead of the OTA update... well, it's nice, but hardly worth a lot of effort.
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.
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.
I am working at an OS independent file manager, in C. I managed to copy files, links and directories, but I am not sure how to copy devices. I would appreciate any help.
To create a device file, use the mknod(2) syscall. The struct stat structure will give you the major and minor device numbers for an existing device in st_rdev.
Having said that, there is little value in "copying" a device because a device doesn't contain anything useful. The major and minor numbers are specific to the OS on which they exist.
It's not really a useful feature, IMHO. tar(1) needs to be able to do it as part of backing up a system, and setup programs need to be able to create them for you when setting up your system, but few people need to deal directly with device files these days.
Also, modern Linux systems are going to dynamic device files, created on the fly. You plug in a device and the device files appear; you unplug it and they disappear. There is really no use in being able to copy these dynamic files.
dd is your friend (man dd)
dd if=/dev/sda1 of=/some_file_or_equally_sized_partition bs=8192
if you want to copy the device-file itself, do this:
cp -p device-filename new-filename
e.g.:
cp -p /dev/sda1 /tmp/sda1
those are both equivalent device files, and can be used to access the device.
If you're want to do this from C, use mknod() .. see "man 2 mknod"
This might be useful
cp -dpR devices /destination_directory
cp -dpR console /mnt/dev
You don't. Just filter them out of the view such that it can't be done.
Use the stat function to determine the file type.
Check if you've the udev package, if you do, chances are that devices are generated on the fly, from the package description:
udev - rule-based device node and kernel event manager
udev is a collection of tools and a daemon to manage events received from the
kernel and deal with them in user-space. Primarily this involves creating and
removing device nodes in /dev when hardware is discovered or removed from the
system.
Events are received via kernel netlink messaged and processed according to
rules in /etc/udev/rules.d and /lib/udev/rules.d, altering the name of the
device node, creating additional symlinks or calling other tools and programs
including those to load kernel modules and initialise the device.