hci_le_create_conn(device,htobs(0x0010),htobs(0x0010),0,0,
peeraddr,0,15,15,0,3200,1,1,0,1000);
I get errno = 5 form above, and it means that the command has not been received and is not being processed in the host controller.
Could someone tell me where is wrong?
I want to connect my bluetooth smart device with my linux computer, but it not works.
Here is the fucntion hci_le_create_conn's params below.
int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
uint8_t initiator_filter, uint8_t peer_bdaddr_type,
bdaddr_t peer_bdaddr, uint8_t own_bdaddr_type,
uint16_t min_interval, uint16_t max_interval,
uint16_t latency, uint16_t supervision_timeout,
uint16_t min_ce_length, uint16_t max_ce_length,
uint16_t *handle, int to)
Use the bluetooth daemon to reset your hardware:
sudo bluetoothctl
power off
power on
I believe BlueZ is in the process of phasing out tools like hciconfig and hcitool. More information can be found here.
I should run sudo hciconfig hci0 down and sudo hciconfig hci0 up before run the function.
Anyway, I successfully connected to my BLE device!
Related
I have this router DIR 605L and I would like to test some firmwares that I have but without actually flashing device. Basicly Im in Bootloader CLI
<RealTek>?
----------------- COMMAND MODE HELP ------------------
HELP (?) : Print this help message
SIG: SIG <type><sig>
SIGR: Display signature and flag
LOADADDR: <Load Address>
J: Jump to <TargetAddress>
FLR: FLR <dst><src><length>
FLW <dst_ROM_offset><src_RAM_addr><length_Byte> <SPI cnt#>: Write offset-data to SPI from RAM
MDIOR: MDIOR <phyid> <reg>
MDIOW: MDIOW <phyid> <reg> <data>
PHYR: PHYR <PHYID><reg>
PHYW: PHYW <PHYID><reg><data>
PORT1: port 1 patch for FT2
<RealTek>
Does anyone know how to copy firmware to RAM and boot it using CLI ?
Here is explanation what mean what on RealTek CLI,
and to flash firmware here is what I did
Press 'Esc' key at boot to interrupt
Enter 'IPCONFIG'
Upload image by TFTP
> $ atftp -p -l fw.bin 192.168.1.6
I'm working on a small OS X app that connects to an FTDI device. I've configured my project according to the answer in this question (I've added the .dylib file as a framework, and I added the ftd2xx.h, WinTypes.h, and ftd2xx.cfg files to my project).
I'm currently able to detect if/when the FTDI device is connected over USB:
DWORD deviceCount = 0;
FT_STATUS ftdiPortStatus = FT_ListDevices(&deviceCount, NULL, FT_LIST_NUMBER_ONLY)
if (ftdiPortStatus == FT_OK) {
// The debugger tells me the deviceCount is now 1
...
}
However, if I try to open a connection to the device using either of the following techniques:
ftdiPortStatus = FT_OpenEx("FT232R USB UART",FT_OPEN_BY_DESCRIPTION,deviceHandle);
// OR
ftdiPortStatus = FT_Open(0, deviceHandle);
the returned ftdiPortStatus is always 3 (FT_DEVICE_NOT_OPENED).
The answer here indicates that the problem might be a new driver that Apple added in OSX 10.9, however, if I attempt to unload that kext:
sudo kextunload -b com.apple.driver.AppleUSBFTDI
the OS indicates that no such kext was found. I'm on OSX 10.10, so maybe Apple repented of their ways and removed that driver from Yosemite(?) Either way, I'm still not able to connect... Does anyone have any idea what might be preventing the connection or have ideas for how I might track down the problem (the returned FT_STATUS isn't very helpful...)?
UPDATE:
The answer, below, solved the problem for me. If you are unsure as to whether you might have a second, non-Apple VCP driver installed, you can find the other drivers by running the following command in a terminal:
kextstat | grep FTDI
which will output something like this:
154 0 0xffffff7f831ee000 0x8000 0x8000 com.FTDI.driver.FTDIUSBSerialDriver (2.2.18) <96 16 5 4 3 1>
155 0 0xffffff7f831f6000 0x7000 0x7000 com.apple.driver.AppleUSBFTDI (1.0.1b12) <96 16 5 4 3>
No, that driver is still there on Yosemite. Running
sudo kextunload -b com.apple.driver.AppleUSBFTDI
still removes the relevant kext and frees the device for access via the D2XX library on this Yosemite system I just tested. The kext may be missing if you haven't yet connected your FTDI device to the system.
It may also be blocked by another virtual comm port driver. If you've installed FTDI's virtual comm port driver, that will also take control of the port and block the D2XX library from connecting. Certain Arduino dev kits also use virtual comm port drivers for the FTDI chips they use, so they may have installed their own driver. Check for that.
Finally, the device name of "FT232R USB UART" that I use in my example code may not be the name of your device. There are many FTDI variants, and you'd need to make sure you're using the name of your specific type of device. This can be obtained from the FT_ListDevices() command with the FT_LIST_BY_INDEX|FT_OPEN_BY_DESCRIPTION options. If you use the wrong device name, FT_OpenEx() can fail.
Our users are using ssh shell to run all CVS actitivies. Is it possible to block them from physically logging to the CVS server? For example, they use the following command to checkout files:
cvs -z3 -d:ext:username#cvsserver:/cvsroot/projects checkout -d project1 .
Since they are part of the group having the permissions to read/write CVS repository file system on the server, they could SSH login to the repo server and delete physical files. Can I block them? I have tried to sshd_config with DeneyUsers, or set /etc/passwd with NOLOGON shell, but they all block CVS commands too.
Thanks
Yes, it is possible. I'm using a custom shell that executes cvs only.
Here's the code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char** argv)
{
if (getenv("CVSROOT") == NULL)
setenv("CVSROOT", "/home/cvs", 0);
execl("/usr/bin/cvs", "cvs", "server", NULL);
printf("No Permission.\n");
}
You could install rssh and set this as the user's login shell.
http://www.pizzashack.org/rssh/
rssh has a list of commands (including cvs) that you can restrict users to. If they try and ssh directly into the machine they will be denied and receive a message like this:
This account is restricted by rssh.
Allowed commands: cvs
If you believe this is in error, please contact your system administrator.
I wrote this simple console program (writeTxt.exe):
#include "stdafx.h"
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
char *fileName = "test.txt";
ofstream outStream(fileName, ios::out);
outStream << "This is a very simple test." << endl;
return 0;
}
Then I run it on the console of Windows Server 2008 using runas command (I logged-in as a different user from User1):
runas /user:User1 writeTxt.exe
But the program doesn't produce the file test.txt. If I log-in to the server as User1 and run the program, it works correctly. Do I have to set something for this to run correctly?
I believe that runas always launches programs with their working directory set to C:\Windows\System32 (or moral equivalent) rather than whatever your current working directory is when you invoke runas.
If User1 has permissions to write to that directory, that's where the file will be. If they don't have such a permission, then the program will fail.
I'm currently wring a Cocoa application which needs to execute some (console) applications which are optimized for 32 and 64 bit. Because of this I would like to detect what CPU architecture the application is running on so I can start the correct console application.
So in short: how do I detect if the application is running on a 64 bit OS?
Edit: I know about the Mach-O fat binaries, that was not my question. I need to know this so I can start another non bundled (console) application. One that is optimized for x86 and one for x64.
There is a super-easy way. Compile two versions of the executable, one for 32-bit and one for 64-bit and combine them with lipo. That way, the right version will always get executed.
gcc -lobjc somefile.m -o somefile -m32 -march=i686
gcc -lobjc somefile.m -o somefile2 -m64 -march=x86_64
lipo -create -arch i686 somefile -arch x86_64 somefile2 -output somefileUniversal
Edit: or just compile a universal binary in the first place with gcc -arch i686 -arch x86_64
In response to OP's comment:
if(sizeof(int*) == 4)
//system is 32-bit
else if(sizeof(int*) == 8)
//system is 64-bit
EDIT: D'oh! I didn't realise you'd need runtime checking... Going through the output of sysctl -A, two variables look potentially useful. Try parsing the output of sysctl hw.optional.x86_64 and sysctl hw.cpu64bit_capable . I don't have a 32-bit Mac around to test this, but both these are set to 1 in Snow Leopard on a Core2Duo Mac.
Use [[NSRunningApplication currentApplication] executableArchitecture] which returns one of the following constants:
NSBundleExecutableArchitectureI386
NSBundleExecutableArchitectureX86_64
NSBundleExecutableArchitecturePPC
NSBundleExecutableArchitecturePPC64
For example:
switch ([[NSRunningApplication currentApplication] executableArchitecture]) {
case NSBundleExecutableArchitectureI386:
// TODO: i386
break;
case NSBundleExecutableArchitectureX86_64:
// TODO: x86_64
break;
case NSBundleExecutableArchitecturePPC:
// TODO: ppc
break;
case NSBundleExecutableArchitecturePPC64:
// TODO: ppc64
break;
default:
// TODO: unknown arch
break;
}
You don't have to detect it manually to achieve that effect. One Mach-O executable file can contain both binaries for 32 bit and 64 bit intel machines, and the kernel runs the most appropriate ones automatically. If you're using XCode, there's a setting in the project inspector where you can set the architectures (ppc, i386, x86_64) you want to have in a single universal binary.
Also, remember that on OS X, running a 64-bit kernel (with Snow Leopard) and being able to run a 64-bit user land app are two orthogonal concepts. If you have a machine with 64 bit cpu, you can run a user-land program in a 64-bit mode even when the kernel is running in the 32 bit mode (with Leopard or Snow Leopard), as long as all of the libraries you link with are available with 64 bit. So it's not that useful to check if the OS is 64-bit capable.
Usually, you shouldn't need to be able to check at runtime whether you're on 64 or 32 bits. If your host application (that's what I'd call the app that launches the 64 or 32 bit tools) is a fat binary, the compile-time check is enough. Since it will get compiled twice (once for the 32-bit part of the fat binary, once for the 64-bit part), and the right one will be launched by the system, you'll compile in the right launch code by just writing sth. like
#if __LP64__
NSString *vExecutablePath = [[NSBundle mainBundle] pathForResource: #"tool64" ofType: #""];
#else
NSString *vExecutablePath = [[NSBundle mainBundle] pathForResource: #"tool32" ofType: #""];
#endif
[NSTask launchedTaskWithLaunchPath: vExecutableName ...];
If the user somehow explicitly launches your app in 32 bits on a 64 bit Mac, trust them that they know what they're doing. It's an edge case anyway, and why break things for power users out of a wrong sense of perfection. You may even be happy yourself if you discover a 64-bit-only bug if you can tell users the workaround is launching as 32 bits.
You only need a real runtime check if your app itself is only 32 bits (e.g. Carbon GUI with command-line helper). In that case, host_processor_info or sysctl or similar are probably your only route if for some weird reason you can't just lipo the two executables together.
If you are on Snow Leopard use NSRunningApplication's executableArchitecture.
Otherwise, I would do the following:
-(BOOL) is64Bit
{
#if __LP64__
return YES;
#else
return NO;
#endif
}
To programmatically get a string with the CPU architecture name:
#include <sys/types.h>
#include <sys/sysctl.h>
// Determine the machine name, e.g. "x86_64".
size_t size;
sysctlbyname("hw.machine", NULL, &size, NULL, 0); // Get size of data to be returned.
char *name = malloc(size);
sysctlbyname("hw.machine", name, &size, NULL, 0);
// Do stuff...
free(name);
To do the same thing in a shell script:
set name=`sysctl -n hw.machine`
The standard way of checking the os version (and hence whether its snow leopard, a 64-bit os) is detailed here.