Trying to replay CAN codes for 2018 Dodge Promaster using can-utils. From what I've read they use an 11 bit CAN ID. However when I use:
candump -L can0 > can.log
The log shows 29 bit ID's
(1519238827.107818) can0 04394100#00000000F0006000
(1519238827.122395) can0 063D4000#4652000080FE0000
(1519238827.126761) can0 04394000#000000AB
(1519238827.147822) can0 03029000#0000000000000000
(1519238827.152676) can0 06254000#00FFFF00FFFFFF00
(1519238827.157823) can0 03029100#0000000000000000
(1519238827.207842) can0 04394100#00000000F0006000
(1519238827.222727) can0 06314000#0000000000000000
(1519238827.226953) can0 04394000#000000AB
(1519238827.244633) can0 0E094000#001A00000409
(1519238827.247843) can0 03029000#0000000000000000
(1519238827.249614) can0 0E094003#001A
(1519238827.251375) can0 0E094020#000A
(1519238827.253121) can0 0E09400A#001A
(1519238827.254935) can0 0621400A#0000
(1519238827.257940) can0 03029100#0000000000000000
(1519238827.262128) can0 06314020#100000BC
I'm thinking this is why replaying with canplayer is not working. Does anyone know how I can force candump to use 11 bit ID's?
You cannot force candump into using 11 bits IDs as the frame format is defined by a bit in the arbitration field (cf. Wikipedia - CAN bus, "Data frame" sub-section). After a quick look at the article you linked, I saw that the car model is from the 2000s and your car is from 2018. Many changes have probably been made in the meantime.
In conclusion: your problem isn't one, it's your article that is too old and doesn't match your car.
You can use candump command with filter option as per below:
Up to 16 CAN interfaces with optional filter sets can be specified
on the commandline in the form: <ifname>[,filter]*
Comma separated filters can be specified for each given CAN interface:
<can_id>:<can_mask> (matches when <received_can_id> & mask == can_id & mask)
<can_id>~<can_mask> (matches when <received_can_id> & mask != can_id & mask)
#<error_mask> (set error frame filter, see include/linux/can/error.h)
[j|J] (join the given CAN filters - logical AND semantic)
CAN IDs, masks and data content are given and expected in hexadecimal values.
When can_id and can_mask are both 8 digits, they are assumed to be 29 bit EFF.
Without any given filter all data frames are received ('0:0' default filter).
Use interface name 'any' to receive from all CAN interfaces.
Examples:
candump -c -c -ta can0,123:7FF,400:700,#000000FF can2,400~7F0 can3 can8
candump -l any,0~0,#FFFFFFFF (log only error frames but no(!) data frames)
candump -l any,0:0,#FFFFFFFF (log error frames and also all data frames)
candump vcan2,92345678:DFFFFFFF (match only for extended CAN ID 12345678)
candump vcan2,123:7FF (matches CAN ID 123 - including EFF and RTR frames)
candump vcan2,123:C00007FF (matches CAN ID 123 - only SFF and non-RTR frames)
Related
I am capturing MQTT traffic for troubleshooting using below command
tcpdump -i team0 -w mqtt-trace.pcap src 10.x.x.x
But it results in very big file within minutes, Can i filter tcpdump on base of topic name
Following is tcp payload, I want it only capture payload which has PKGCTRL/1/status/frequency or if tcpdump can directly support filter on application layer protocol like wireshark mqtt.topic == PKGCTRL/1/status/frequency
0000 00 13 95 36 2e ef 00 10 7e 07 87 3d 08 00 45 00 ...6....~..=..E.
0010 00 77 2e 0d 40 00 40 06 f6 78 0a 0b 80 f3 0a 0b .w..#.#..x......
0020 80 f2 c3 6a 75 83 e4 f8 f7 7a 0a 89 67 76 50 18 ...ju....z..gvP.
0030 ea 60 59 f8 00 00 30 4d 00 1a 50 4b 47 43 54 52 .`Y...0M..PKGCTR
0040 4c 2f 31 2f 73 74 61 74 75 73 2f 66 72 65 71 75 L/1/status/frequ
0050 65 6e 63 79 0a 11 09 c2 7a 85 14 d0 71 37 16 12 ency....z...q7..
0060 06 08 01 10 01 18 00 12 1c 0a 0d 09 0b 46 25 75 .............F%u
0070 02 f2 48 40 10 21 18 00 11 00 60 76 14 d0 71 37 ..H#.!....`v..q7
0080 16 20 00 28 00 . .(.
I don't think the previously accepted answer necessarily does what you think it does and possibly not even what you want it to do. The original question stated, "But it results in very big file within minutes, Can i filter tcpdump on base of topic name"
If you're trying to limit the size of the capture file, then the previously accepted answer isn't doing that because it uses the exact same capture filter as was originally provided, namely src 10.x.x.x. This means that you're capturing the same amount of data as you were before. Just because a capture file name wasn't specified doesn't mean that packets aren't being written to a file; they are. In the case of tshark, packets are written to a temporary file, which will continue to grow until the capture session is terminated and then ideally it will be deleted, but not always. The location of the temporary file varies depending on the platform that tshark is run on, but you should be able to easily locate the directory by running tshark -G folders | grep "^Temp".
Now, if you want to reduce the size of the capture file, or the number of packets that you see, then you should be able to modify the tcpdump or tshark command-line arguments to accomplish that.
First off, if you don't need the entire payload, you can apply a snaplen to cut the packets short after some appropriate value. This is done using the -s option, and it's the same option for either capture tool.
OK, but whether you decide to apply a snaplen or not, if you want to filter based on the specific topic name, most likely you can achieve this; however there are a couple of caveats that I listed below. The main idea is to use the slice operator, [] (see the pcap-filter man page) to compare various bytes of the TCP payload to specific values. (NOTE: Neither tcpdump itself nor pcap-filter refers to this operator as the slice operator, but wireshark-filter does, so I do as well.) So the filter should:
Match packets only to/from a particular host, in this case 10.x.x.x
Match only MQTT packets (typically by port number, which I'll assume to be the standard tcp/1883 port)
Match only PUBLISH messages with QoS 0
Match only PUBLISH messages where the topic length is 26 bytes
Match only PUBLISH messages where the topic is "PKGCTRL/1/status/frequency"
Here's a command that should work (at least in most cases -> see caveats below):
tcpdump -i team0 -w mqtt-trace.pcap \
"(src host 10.x.x.x) and \
(tcp port 1883) and \
((tcp[20]&0xf6)=0x30) and \
(tcp[22:2]=26) and \
(tcp[24:4]=0x504b4743 and tcp[28:4]=0x54524c2f and \
tcp[32:4]=0x312f7374 and tcp[36:4]=0x61747573 and \
tcp[40:4]=0x2f667265 and tcp[44:4]=0x7175656e and tcp[48:2]=0x6379)"
It should be obvious from the description of the desired filter above what each separate component of the filter is doing for you.
Here, you'll end up with a capture file of the desired packets that you can reference later on if you need to. You can even apply this same filter to the tshark solution too if you prefer as well as writing to the named capture file, because as I explained earlier, tshark is writing packets to a file whether you explicitly specify one or not.
Caveats:
The filter assumes TCP headers are 20 bytes for simplicity in illustrating the solution, but that may not be the case. If you want a more robust solution to accommodate any TCP header size, then you'll need to determine the TCP header size from the data offset field of the TCP header, which is done in the filter using ((tcp[12]&0xf0)>>4)*4, and then replace every occurrence of 20 in the slice operator's offset field with that value. So for example, tcp[22:2]=26 becomes tcp[(((tcp[12]&0xf0)>>4)*4)+2:2]=26, etc.
Because the MQTT remaining message length field is variable-length encoded per MQTT3.1.1 section 2.2.3 Remaining Length, the filter, as provided above, will only work for values of the remaining length field from 0 to 127, i.e., the remaining length field must only be a single byte. Given that the topic in this case is 26 bytes and the topic length itself is 2 bytes, this means the filter will only work for MQTT message payloads of 99 bytes or less (127 - (2 + 26)).
As #hardillb suggested, use tshark instead. Due to tshark's architecture, you can't write a file at the same time as a display filter (it would be too slow).
To get the information you need, it would look something like this
$ tshark -i team0 -f "src 10.x.x.x" \
-Y "mqtt.topic == PKGCTRL/1/status/frequency" -T fields -e mqtt.topic
-i team0: Filter on interface team0
-f "src 10.x.x.x": Use a capture filter, which is the same as tcpdump's filtering. This will speed up processing as it's faster than a display filter (next bullet).
-Y "mqtt.topic == PKGCTRL/1/status/frequency": Filter for packets that match this display filter
-T fields -e mqtt.topic: Output only the mqtt.topic field, as that is the target information.
-T fields will output columnar data vertically delimited by newlines. It won't be horizontally delimited because there is only column, but the default is \t.
I need to send a frame from can0 to can1 and vice versa.
So, first I log candump output to a file like this: candump can1 -n 1 > /tmp/CANDUMP &
Then I send the frame: cansend can0 128#00FF00FF00FF00FF
It only works if I send a frame from can1 to can1 or can0 to can0... Wonder why?
It only works if I send a frame from can1 to can1 or can0 to can0... Wonder why?
cansend command takes 2 arguments. The first one is can-device ID, here the device is on which you want to send the data which means cansend can0 will publish the data on the canbus 0 on your system.
If you want to send data from can0 to can1 you can physically connect them to the same bus.
I'm writing a CAN driver and want to set up some tests for it. I have a simple echo program (accepts a can frame and echoes it back). I'm using can-utils for this and would use cangen to generate random data, log it, then make sure the frames were received and echoed back.
Everything seems to be working but there is some annoying behavior from candump. When sending non-FD frames, it does not print a leading zero for the DLC. See here (messages are sent, and then the echoed message - yes I'm aware it shouldn't use the same node id to echo back this is just for testing purposes):
candump can0
#can FD frames (11 and 29 bit ids)
can0 033FABCD [04] DE AD BE EF #sent
can0 033FABCD [04] DE AD BE EF #echoed
can0 277 [04] DE AD BE EF
can0 277 [04] DE AD BE EF
#non-FD frames sent (11 and 29 bit ids)
can0 277 [4] DE AD BE EF #sent
can0 277 [04] DE AD BE EF #echoed
can0 077AFFFF [4] DE AD BE EF
can0 077AFFFF [04] DE AD BE EF
Both FD and non-FD frames have a 4 bit DLC so I'm not sure why it'd be printed differently. We are only sending FD so the echoed frame is in FD format and gets a leading zero printed.
Obviously I can work around this but the behavior is kind of annoying. Does anyone know what might be wrong here?
No this is intentional to distinguish Classic CAN [x] from CAN FD [xx] frames in the human readable output. It is not the question whether the DLC (4 bit on the physical layer) to be the same, as we always operate with the real length information and not with the DLC on socket level. And when both are 5 bytes you wont be able to distinguish them.
Btw. your CAN driver seems to have an issue, when the echo'ed frame is always a CAN FD type - no matter what has been sent (Classic CAN / CAN FD) ...
I am new to the CAN-BUS protocol. So was going through the CAN Bus Specifications and related documents.
I have always used the CAN ID and Frame at the application level.
CANID like 0x1a1 CAN Frame like ff 22 ff 33 co 33 ee 44 (8 bytes).
In the specification, they mentioned that the Frame consists of identifier field.
I doubt what is that.
Is that the CAN ID like 0x1a1 or CAN ID + some other stuff.
No documents mentioned that clearly.
If that is not CAN ID.. Where is CAN-ID in CAN Format.
Can anyone clarify that doubt?
In short, a single CAN message consists of CANID, the CAN data and other stuffs,
https://en.wikipedia.org/wiki/CAN_bus#Data_frame
I am new to the Bluetooth system and I am trying to understand the data used for the new Apple's technology : iBeacon.
There is already some nice answers which explain how it works and I have been reading everything I could find (especially the Bluetooth Specification). Still, I am missing some points and I will go for an example first : (I am using the Set Advertising Data Command, it misses here the hcitool cmd before the OGF)
0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00 00 00 00 C5 00
I will list here what I didn't understand or find information about.
Is there any information anywhere about the OGF (here it is 0x08)? I know it stands for OpCode Group Field, but contratry to the OCF which follows the OGF, I didn't find anything.
What does the 02 01 1A 1A bytes line stand for? I know that the first byte, 1E, tells the length of the rest of the data and after that line, starting with FF, you get the manufacturer specific data. But I couldn't find anything about those 4 bytes.
How does the power byte work? Here it is C5. I know that what I get is the dBm value when ranging my iBeacon (on my iPhone for instance). And I know that the higher the value (on that power byte), the higher the power which means more accuracy but also more energy consumption. But how do you use that byte? What are the min and max values you can set? Or is there any kind of formula there? Do you get a set dBm value (at one meter from your iBeacon) for a set value on the byte?
Thank you.
Answers to the first two questions can be found in the gigantic Bluetooth 4.0 Core spec.
The OGF of 0x08 groups OCF commands for LE Controllers:
For the LE Controller Commands, the OGF code is defined as 0x08.
(Bluetooth Specification Version 4.0 [Vol 2], page 1114)
Because the 0x0008 OCF command is a controller command, you have to use the 0x08 OGF code with it. Confused? Forget it. Just know you use 0x08 0x0008 to set the advertising data using hcitool.
The byte sequence starting the advertisement is as follows:
1E Number of bytes that follow in the advertisement
02 Number of bytes that follow in first AD structure
01 Flags AD type
1A Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
1A Number of bytes that follow in second (and last) AD structure
FF Manufacturer specific data AD type
4C Company identifier code LSB
00 Company identifier code MSB (0x004C == Apple)
02 Byte 0 of iBeacon advertisement indicator
15 Byte 1 of iBeacon advertisement indicator
-- Bluetooth Specification Version 4.0 [Vol 3], "ADVERTISING AND SCAN RESPONSE DATA FORMAT" p. 375
-- Bluetooth Specification Version 4.0 [Vol 3], Appendix C (NORMATIVE): EIR AND AD FORMATS", p. 401
The power field is simply a one byte two's complement number representing the "measured power" in RSSI at one meeter away. In simpler terms
Here is how that works:
Hold an iBeacon scanner (like Locate for iBeacon for iOS) one meter away from your iBeacon transmitter.
Read its signal strength in RSSI. It will be a number between -1 and -127. (-1 is very strong, -127 is very weak)
Convert this number into a hex using two's complement. (Add 256 then convert to hex)
Note: The power field can be 80-FF. If it is 00, iOS will not do a distance calculation at all. You can read more on how this is used here.