First post! Full disclosure, I have a very limited programming / pi background.
I'm working on a project to communicate with a Chroma Bi-Directional power supply (Model #: 62180D-1200) using LXI / SCPI communication. There's more I hope to do in the future, but for the time being I'm simply trying to establish a working communication channel using the "*IDN?" identify command. I have a raspberry pi connected to the same network as the power supply, which I am using to communicate to the 62180D.
Before beginning any of this testing, I have been able to establish that I can communicate with the device via http (web browser). The web page for the device even includes an scpi query tool -- which works!
Successful HTTP communication
To query the device from the pi I have used PuTty to log in to my pi and issue the following command:
lxi scpi -a <device ip address> "*IDN?"
I am expecting to see the same result as shown in the image above (Model No. , Serial No., Firmware Version), but instead I'm receiving the following:
Error: Read error (timeout)
Error: Failed to receive message
I was under the impression that this protocol is fairly plug and play. I have other LXI enabled devices on the same network that I am able to communicate with them using this same approach. Is there some obvious thing I'm missing here?
Related
I am running a BLE beacon in bluez5.52 on a linux machine(ubuntu 14.04) using the default gatt-service and the beacon using the btmgmt provided in the tools folder. Following are the commands I run to setup the beacon:
Terminal 1:
./gatt-service
Terminal 2
sudo ./btmgmt
add-adv -u 180d -u 180f -d 080954657374204C45 1
I am easily able to connect and disconnect with the beacon using BLE scanner app in android.
What I would like to do is setup a password for the beacon so that I am the only one who can connect to it. So far I have been unable to find any resources online that could help set that up. I have a decent understanding of the btmgmt and gatt-service code. I am looking for direction on what part of bluez code to look for to set up the password protection. Any leads, pseudo-code or partial code would help a lot.
Emil already mentioned pairing and bonding in the comments. This would definetly serve your purpose as you would be able to control who could connect to your peripheral.
A BLE characteristic can ask a connected device to authenticate before reading or writing which would result in a 'insufficient authentication error' if the device is not paired to your peripheral. A Android app is able to handle this error by displaying a pairing popup depending on the used pairing method.
So it is possible to have characteristics without security right next to one's that require pairing.
In case you still want to implement something like your mentioned password safety you should look into a 'authorized read'.
A characteristic which requires authorization first receives a read request and you can allow or deny it based on your own requirements. That means you can authorize yourself by sending a password to one characteristic and afterwards allow a read request on another characteristic. This would be even easier if you only accept one connection at a time.
I'm trying to connect to a BTLE device from Linux from C++ with BlueZ.
Connecting to most devices works fine, but there is a special device which times out with 90% probability. From a standard Android smartphone the connection to this particular device works as intended.
For #Emil's advice in my other question (thanks!) I've setup a Link Layer sniffer tool for further investigation.
During the sniff period I tried connecting to the device(Destination) from both device(Good) and device(Bad).
Device(Good) is working perfectly - it connected
Device(Bad) is not working - timed out
Now I have a Link Layer data of both device connection trials and there is one significant difference between their trials:
Device(Good)'s LL Data for its CONNECT_REQ uses 500 for Timeout value (which is 625ms) while Device(Bad)'s LL Data in CONNECT_REQ uses 42 (which is 52.5ms).
I think Device(Destination)'s response is normally (mostly) arriving between those two, ie after 52.5ms and below 625ms, but sometimes it arrives in less than 52.5ms, and then also BlueZ can connect to it finally.
Is there any possibility to change this Timeout property for CONNECT_REQ in BlueZ? Maybe with setsockopt by any chance?
Or this is something hardcoded into kernel, even for bluetooth adapters attached to USB?
I am using a BeagleBone Black board (kernel 4.14.108-ti-r104) to create USB gadget using configfs/functionfs. I compose my gadget (using gadgettool) providing details about device configuration (function, vendor id, product id and ton of other params), run my userspace program that writes descriptors and strings to ep0 and connect the device to host. All works fine, I get BIND (when binding device to UDC) and ENABLE (when actually host is connected) events and my device can read from ep2 and write to ep1. Using wireshark I see the communication looks good, device and configuration descriptors as well as strings are exchanged.
The problem starts when I connect the device to another host. Unfortunately I have almost no control over that host, in particular I cannot run wireshark there, I don't even know the OS. The only thing I can do is to plug/unplug device, optionally see a message that device was detected and optionally a restart. What I see on the gadget side is that following BIND and ENABLE events I immediately get SUSPEND event and read on ep2 fails with 108 (ESHUTDOWN). Now the question is how to track the problem down.
I tried usbmon, but it seems it does not listen to traffic when device is in gadget mode. I have also seen https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/udc/trace.h file which seems to define some udc trace points, but I am not really sure how they can be used.
So the final question is simple: how do I get any information about traffic on USB bus having access only to gadget side? I don't need full trace, but al least some information which packets were exchanged would be super useful. Did it fail while exchanging device descriptors, configuration/interface/endpoint descriptors or strings or something totally different?
Small update:
The whole thing is about Android Open Accessory Protocol and I am trying to write a gadget that would connect to this accessory.
I have changed my gadget composition somewhat and now I know the gadget is being identified by host (it displays manufacturer/model) so I suppose the issue is not in device descriptor and strings. I have used two additional flags in descriptors (FUNCTIONFS_ALL_CTRL_RECIP | FUNCTIONFS_CONFIG0_SETUP) and when connecting to my computer I get setup event (request 51 as expected), but when connecting to my accessory I still get SUSPEND/ESHUTDOWN. This time though it looks like the time between ENABLE and SUSPEND is much greater (over 10 seconds) which looks to me as if the host send some message, but this message was not processed by my gadget and then the host timeout out and disabled usb device. Still don't know how to find out if the accessory sent anything to gadget and what it was...
Problem
I have just started to scratch the surface of this topic so excuse me if I'm formulating the question a bit strange and novice. Let's say I'm on a wireless network which I am right now, and I want to see all the data that is flowing in and out of this network from other clients connected to the network. I remember reading a book about someone doing this while being connected to the Tor network and it got me thinking about how this is done.
Questions
A: what is this process called?
B: How is it done?
Wireshark can do this:
http://www.wireshark.org/
It sniffs packets in "promiscuous mode":
http://en.wikipedia.org/wiki/Promiscuous_mode
That lets you see all the packets routed through a specified network interface, not just the packets targeted to a particular client.
A: It's call packet analyzing / packet sniffing.
B: In an unswitched network (e.g. a wifi network or hub), all you need is a network card that supports promiscuous mode and some software, as mentioned by sdanzig.
In a switched environment (e.g. most modern wired networks), you need to use a Layer 3 switch and set it up to mirror the traffic you're interested in to the port to which you are connected. (Otherwise your network adapter won't 'see' the other traffic.)
Some tools:
http://www.dmoz.org/Computers/Software/Networking/Network_Performance/Protocol_Analyzers/
Related topics on SO:
https://stackoverflow.com/questions/tagged/packet-sniffers
https://stackoverflow.com/questions/tagged/packet-capture
I have an interesting problem. I am working on an embedded box with multiple instances of Linux running each on an ARM processor. They are connected over internal 1GBps network. I have a serial port device node attached to processor A (Lets say Linux-A running on it). I have a program running on processor B (Lets say on Linux-B) access the serial port device as if it is attached to Linux-B locally.
My program invokes term i/o type api calls on device node to control tty echo, character mode input. What I am wondering is if there is a way to create a virtual serial device that is available on Linux-B somehow talking to real serial device on Linux-A over internal network.
I am thinking something along the lines of:
Linux-B has /dev/ttyvirtual. Anything that gets written to it gets transported over network socket to Linux-A serialserver. The serial server exrcises the api calls on real device lets say /dev/ttys0.
Any data waiting on ttys0 gets transported back to /dev/ttyvirtual.
What are all the things involved to get this done fast?
Thanks
Videoguy
Update:
I found a discussion at
http://fixunix.com/bsd/261068-network-socket-serial-port-question.html with great pointers.
Another useful link is http://blog.philippklaus.de/2011/08/make-rs232-serial-devices-accessible-via-ethernet/
Take a look at openpty(3). This lets you create a pseudo-TTY (like /dev/pts/0, the sort that ssh connections use), which will respond as a normal TTY would, but give you direct programmatic control over the connections.
This way you can host a serial device (eg. /dev/pts/5) that you forward data between a network connection, and then other apps can perform serial operations on it without knowing about the underlying network bridge.
I ended up using socat
Examples can be found here: socat examples
You socat back to back on both the machines. One listens on a tcp port and forwards data to local virtual port or pty. The socat on other box uses real device as input and forwards any data to tcp port.