First of all, sorry for my bad english.
For the entire projet, I am trying to connect a generic smartwatch (this one) to an Arduino. The purpose is to gather information (heart rate for example).
I don't know how the device communicate with the application Mistep. So I followed several steps.
At this moment, I didn't analyze the establishment of the connection at the beginning but only the value (heart rate) transmission.
Running application with HCI/BLuetooth Log on Android
I analyzed this log in Wireshark.
First of all, I have a packet sent by the smartwatch and received by the Android machine:
Bluetooth HCI ACL Packet
.... 1110 0000 0001 = Connection Handle: 0x0e01
..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
00.. .... .... .... = BC Flag: Point-To-Point (0)
Data Total Length: 17
[Connect in frame: 12999]
[Source BD_ADDR: d6:1c:5a:c3:05:** (d6:1c:5a:c3:05:**)]
[Source Device Name: HRW_1c5ac305**]
[Source Role: Unknown (0)]
[Destination BD_ADDR: IntelCor_95:05:** (fc:f8:ae:95:05:**)]
[Destination Device Name: VMware Virtual Platform]
[Destination Role: Unknown (0)]
[Current Mode: Unknown (-1)]
Bluetooth Attribute Protocol
Opcode: Write Command (0x52)
0... .... = Authentication Signature: False
.1.. .... = Command: True
..01 0010 = Method: Write Request (0x12)
Handle: 0x0018 (Unknown)
[UUID: Unknown (0xfff2)]
Value: 68260400110a1000bd16
Then the Android device send a packet (notification) to the smartwatch:
Edit:
Bluetooth HCI ACL Packet
.... 1110 0000 0001 = Connection Handle: 0x0e01
..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
00.. .... .... .... = BC Flag: Point-To-Point (0)
Data Total Length: 9
[Connect in frame: 12999]
[Source BD_ADDR: IntelCor_95:05:** (fc:f8:ae:95:05:**)]
[Source Device Name: VMware Virtual Platform]
[Source Role: Unknown (0)]
[Destination BD_ADDR: d6:1c:5a:c3:05:25 (d6:1c:5a:c3:05:**)]
[Destination Device Name: HRW_1c5ac305**]
[Destination Role: Unknown (0)]
[Current Mode: Unknown (-1)]
Bluetooth Attribute Protocol
Opcode: Handle Value Notification (0x1b)
0... .... = Authentication Signature: False
.0.. .... = Command: False
..01 1011 = Method: Handle Value Notification (0x1b)
Handle: 0x000e (Heart Rate Measurement)
[UUID: Heart Rate Measurement (0x2a37)]
Flags: 0x04, Sensor Support
000. .... = Reserved: 0x00
...0 .... = RR Interval: False
.... 0... = Energy Expended: False
.... .1.. = Sensor Support: True
.... ..0. = Sensor Contact: False
.... ...0 = Value is UINT16: False
Value: 76
This packet contains the value of heart rate (76) but it is sent by Android device to the smartwatch for notification. I guess this value has been retrieved from the handle 0x0018 value: 68260400110a1000bd16.
The problem is: I don't know how to get the value from this hexa.
Do you have an idea how to analyze the value and get the heart value ?
Related
I have developed a UMTS core network using a home nodeB (HNB) which the mobile phones (or UEs) can register on my network and get the required services such as call service. I have implemented all the required procedures for call service and I can establish a successful call for my connected UEs.
In one of the most important procedure, i.e Call Proceeding, I have identified the coding of speech transferred between UEs and core. Here is my coding options (in wireshark):
GSM A-I/F DTAP - Call Proceeding
Protocol Discriminator: Call Control; call related SS messages (3)
.... 0011 = Protocol discriminator: Call Control; call related SS messages (0x3)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
00.. .... = Sequence number: 0
..00 0010 = DTAP Call Control Message Type: Call Proceeding (0x02)
Bearer Capability 1 - (Spare)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: Spare
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 1000 = Speech version indication: GSM full rate speech version 5(FR AMR-WB) (0x8)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1)
So I can see the RTP packets transferred between UE and core. An instance is mentioned here (in wireshark):
Real-Time Transport Protocol
[Stream setup by RANAP (frame 2950)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: DynamicRTP-Type-96 (96)
Sequence number: 56611
[Extended sequence number: 56611]
Timestamp: 424448575
Synchronization Source identifier: 0x5c260101 (1545994497)
RFC 2198: Redundant Audio Data
Header 1: PT=ITU-T G.728
0... .... = Follow: Not set
.000 1111 = Payload type: ITU-T G.728 (15)
Payload: 0028ba44776b3eee7a050039cdaa521cc20ac08d2bcf1818…
I have aggregated all RTP packets payload. How can I convert the aggregated bytes to a hearable audio?
I've been trying to update someone else' software to work on a new machine.
They built a Modbus controller using the Pymodbus library to work with the main software.
The only difference between the original working machine and this new one is that the DAQ is different.
I had assumed going in that this would just mean changing addresses but probably due to my lack of knowledge about Pymodbus this has been very far from the case.
The main issue I am having right now is that is that I am trying to simply communicate with holding registers and the only response I can get back is "(131, 3, Slave Device Busy)".
I am really not sure what to do with this information, It happens as soon as it is started and nothing is able to change it.
Has anyone else had any experience where a device always outputting this same error code?
the DAQ I am using is a Aspar IO Slim Module MOD-ETH
Any advice would be much appreciated.
Thank you
J
(I would attached the code here but it is quite long and I'm not sure a snippet would really help but do let me know if it would be helpful)
Short test code
from pymodbus.client.sync import ModbusTcpClient as ModbusClient
import logging
logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)
log.debug("Connecting to controller (IP=169.254.54.23, Port 502)")
client = ModbusClient('192.168.1.135', port=502)
59 #client = ModbusClient(method='ascii', port='/dev/pts/2', timeout=1)
60 # client = ModbusClient(method='rtu', port='/dev/ttyp0', timeout=1)
client.connect()
log.debug("Connected to controller (IP=192.168.1.135, Port 502)")
log.debug("Reading Sump Oil Temperature")
rr = client.read_holding_registers(1021, 1, unit=1)
log.debug("Read Sump Oil Temperature")
if rr.function_code > 0x80:
print( "Error has occured!\n" + str( rr.function_code ) + "\n" + str( rr.exception_code ) )
else:
print( rr.getRegister(0) )
client.close()
Response:
DEBUG:root:Connecting to controller (IP=169.254.54.23, Port 502)
DEBUG:root:Connected to controller (IP=192.168.1.135, Port 502)
DEBUG:root:Reading Sump Oil Temperature
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x3 0xfd 0x0 0x1
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0 0x1 0x0 0x0 0x0 0x3 0x1 0x83 0x6
DEBUG:pymodbus.framer.socket_framer:Processing: 0x0 0x1 0x0 0x0 0x0 0x3 0x1 0x83 0x6
DEBUG:pymodbus.factory:Factory Response[131]
DEBUG:pymodbus.transaction:Adding transaction 1
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
DEBUG:root:Read Sump Oil Temperature
Error has occured!
131
6
I'm trying to write a fake access point script in ruby; the script is below:
require 'packetgen'
def fake_ap
print 'Making a fake ap...'
while true
bssid = 'aa:aa:aa:aa:aa:aa'
iface = 'mon0'
ssid = 'NoWifi'
broadcast = 'ff:ff:ff:ff:ff:ff'
pkt = PacketGen.gen('RadioTap')
pkt.add('Dot11::Management', mac1: broadcast, mac2: bssid, mac3: bssid)
pkt.add('Dot11::Beacon', cap: '0x1114')
pkt.dot11_beacon.add_element(type: 'SSID', value: ssid)
pkt.dot11_beacon.add_element(type: 'Rates', value: "\x82\x84\x8b\x96\x24\x30\x48\x6c")
pkt.dot11_beacon.add_element(type: 'DSset', value: "\x06")
pkt.dot11_beacon.add_element(type: 'TIM', value: "\x00\x01 \0x00\0x00")
pkt.calc
pkt.to_w(iface)
end
end
fake_ap
Hexdump of packet
The program is supposed to send beacon frames; I ran the program (with my wireless card on monitor mode) however it doesn't show up as an access point. It there a problem with my code or something else. The docs for the packetgen library are here. Thanks!
I'm running an Linux Image (kernel 3.2.8) for beagleboard-xm on QEMU's 1.4.0 emulator Ubuntu distribution for 13.04. My image is created using Buildroot beagle_defconfig. I added some pkgs to be able to debug a little.
QEMU call cmd:
`$ sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -serial stdio -device usb-mouse -device usb-kbd -serial pty -serial pty`
[sudo] password for emperador:
char device redirected to /dev/pts/3 (label serial1)
char device redirected to /dev/pts/4 (label serial2)
What I want to do is to have a communication between guest and host across serial the 4 differents ttyO present on the guest. QEMU offer facilities to redirect the trafic to some device in the host side. My problem goes like this:
At the guest kernel boot Im able to see that my UART where enabled
[ 2.682040] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 2.777947] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
[ 2.794967] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
[ 2.814942] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
[ 2.966825] console [ttyO2] enabled
[ 2.984777] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3
In fact when I go see in to /proc/tty/driver and I do a cat on OMAP-SERIAL Im able to see this
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x4806A000 irq:72 tx:0 rx:0 CTS|DSR|CD
1: uart:OMAP UART1 mmio:0x4806C000 irq:73 tx:0 rx:0 CTS|DSR|CD
2: uart:OMAP UART2 mmio:0x49020000 irq:74 tx:268 rx:37 RTS|CTS|DTR|DSR|CD
3: uart:OMAP UART3 mmio:0x49042000 irq:80 tx:0 rx:0 CTS|DSR|CD
I know that ttyO2 is working because my console is been redirected to it. The thing is that doing a set serial on any of the ttyO I get the following message:
[root#enu driver]# setserial -a /dev/ttyO0
/dev/ttyO0, Line 0, UART: undefined, Port: 0x0000, IRQ: 72
Baud_base: 3000000, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
The same goes with ttyO2.
I tried to set some settings to any of the ttyO with setserial but I always get the same message:
[root#enu ~]# setserial /dev/ttyO0 uart 8250
setserial: can't set serial info: Invalid argument
[root#enu ~]# setserial /dev/ttyO0 port 0x4806a000
setserial: can't set serial info: Invalid argument
While looking at guest /proc/tty/drives this is what we see
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
sdio_uart /dev/ttySDIO 249 0-7 serial
acm /dev/ttyACM 166 0-31 serial
ttyprintk /dev/ttyprintk 5 3 console
OMAP-SERIAL /dev/ttyO 253 0-3 serial
serial /dev/ttyS 4 64-95 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
unknown /dev/tty 4 1-63 console
Basically I want to establish a serial communication between a guest and a host, but the serial ports on the guest side aren't well configured.
/sys/class/tty show that tty drivers had been linked to a serial device.
has I showed up before, only omap uarts have been initialized and attached to ttyO*. notice that the console is been redirected ttyO2 by kernel configs. but because I added -serial stdio, console is been redirected to the terminal that invoked QEMU.
If I redirect the console using at first -serial pty instead of -serial stdio , I'm able to prompt the console in minicom by opening the pty created on the host side. Still nothing happen on the others pty created on the host side to communicate across other ports.
On host side I open /dev/pts/3 and /dev/pts/4 with minicom or by doing cat on them
On guest side:
Whent I do echo "test" > /dev/ttyO0 or 1 or 3 nothing. but when I do it on ttyO2, "test" prompt on the console terminal (which is normal).
now when using any of the ttyS:
echo "test" > /dev/ttyS0
I get
-bash: echo: write error: Input/output error
I made some research about this error and what I found is that is could be many things. But one thing that I noticed was that no device beside serial has been assigned to ttyS. and looking at /proc/tty/driver/serial we see this :
serinfo:1.0 driver revision:
0: uart:unknown port:00000000 irq:0
1: uart:unknown port:00000000 irq:0
2: uart:unknown port:00000000 irq:0
3: uart:unknown port:00000000 irq:0
also setserial -a /dev/ttyS0 confrim this:
/dev/ttyS0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
I managed to do serial communication with muliples ports usig grml image on a x86 architecture. So its seems my host side is fine.
If anyone have ever made something like this work before on QEMU -M beaglexm or any other ARM architecture, I would gladly take any details on the VM used, QEMU's version and distribution as well as the kernel details and image configs used.
I found what my problem was, QEMU ins't mapping the serial chardev of any extra -serial pty.
After doing the this Invoke command:
sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clonix -serial stdio -device usb-mouse -device usb-kbd -serial pty -serial pty -monitor pty
char device redirected to /dev/pts/5 (label compat_monitor0)
char device redirected to /dev/pts/7 (label serial1)
char device redirected to /dev/pts/10 (label serial2)
We can see that 2 extra serials where created with the label serial 1 and 2.
But if I look at the tree info
(qemu) info qtree
dev: omap_uart, id "uart4"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = uart4
irq 3
mmio 0000000049042000/0000000000001000
dev: omap_uart, id "uart3"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = serial0
irq 3
mmio 0000000049020000/0000000000001000
dev: omap_uart, id "uart2"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = uart2
irq 3
mmio 000000004806c000/0000000000001000
dev: omap_uart, id "uart1"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = uart1
irq 3
mmio 000000004806a000/0000000000001000
We clearly see that just the label serial0 was attached to a uart (the one setted to be the console). The other labels (serial1 and serial2) are no where to be found.
With the working image of grml that jofel was realy nice to tell me we see this:
dev: i440FX-pcihost, id ""
irq 0
bus: pci.0
type PCI
dev: PIIX3, id ""
addr = 01.0
romfile = <null>
rombar = 1
multifunction = on
command_serr_enable = on
class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100)
bus: isa.0
type ISA
dev: isa-serial, id ""
index = 2
iobase = 0x3e8
irq = 4
chardev = serial2
wakeup = 0
isa irq 4
dev: isa-serial, id ""
index = 1
iobase = 0x2f8
irq = 3
chardev = serial1
wakeup = 0
isa irq 3
dev: isa-serial, id ""
index = 0
iobase = 0x3f8
irq = 4
chardev = serial0
wakeup = 0
isa irq 4
all 3 serial lebels were attached to a chardev.
Now I just have to ask a new question about how making QEMU to link those lables to my beagleboard uarts.
Also I would like to add I think that setserial did not outputed any info about ttyO's because it doesn't support omap uarts. setserial ? shows what devices are supported. In the case of the ttyS's, I think its because the tty drivers are installed but there is no other type of uarts bisede omap uarts emulated for bealgeboard in QEMU.
Thanks alot for everyone that took a look on this question and specialy jofel.
I need to send a bunch of IP packets that I'm sure will trigger an ICMP TTL-expired error message. How exactly can I associate each error message with the packet that generated it? What field in the ICMP header is used for this?
Should I rather use some custom ID number in the original IP header, so that I can tell which error message corresponds to which packet? If so, which field is most suitable for this?
The body of ICMP TTL Expired messages must include the IP header of the original packet (which includes the source-port / destination-port) and 64 bits beyond the original header.
Based on timing and that header information, you can derive which packet triggered the TTL-expired message.
I am including a sample triggered by an NTP packet below...
See RFC 792 (Page 5) for more details.
ICMP TTL-Expired Message
Ethernet II, Src: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00), Dst: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
Destination: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
Address: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00)
Address: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 172.25.116.254 (172.25.116.254), Dst: 172.25.116.10 (172.25.116.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0x86d7 (34519)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xb3b1 [correct]
[Good: True]
[Bad : False]
Source: 172.25.116.254 (172.25.116.254)
Destination: 172.25.116.10 (172.25.116.10)
Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0x4613 [correct]
Internet Protocol, Src: 172.25.116.10 (172.25.116.10), Dst: 172.25.0.11 (172.25.0.11)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 36
Identification: 0x0001 (1)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 0
[Expert Info (Note/Sequence): "Time To Live" only 0]
[Message: "Time To Live" only 0]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (0x11)
Header checksum: 0xee80 [correct]
[Good: True]
[Bad : False]
Source: 172.25.116.10 (172.25.116.10)
Destination: 172.25.0.11 (172.25.0.11)
User Datagram Protocol, Src Port: telindus (1728), Dst Port: ntp (123)
Source port: telindus (1728)
Destination port: ntp (123)
Length: 16
Checksum: 0xa7a1 [unchecked, not all data available]
[Good Checksum: False]
[Bad Checksum: False]