-
Notifications
You must be signed in to change notification settings - Fork 9
Infodump
Here I'll probably put info before I format it properly into their own pages so you guys have something to work with way before "it looks nice" :) ofc feel free to add stuff here too, formatting doesn't matter as long as it's clear what you mean!
The camera will respond to a UDP broadcast on the local LAN with a payload of 4 bytes (f1 30 00 00) sent to port 32108. The response will be sent as a unicast to the source port of the machine that sent the broadcast.
The source port in the initial response is to be used for further UDP commands. It looks like the initial response is a cookie that the client sends back, and the source port of that message is used as the reply port by the server.
E.g. If the camera IP were on 192.168.0.129 and your test machine on 192.168.0.50 then:
Source IP. Source Port Dest.IP. Dest.Port Payload Means
192.168.0.50 : (aaaaa) -> 192.168.0.255 : 32108 (fixed) (f1 30 00 00) What's your port?
192.168.0.129 : server_port -> 192.168.0.50. : (aaaaa) (f1 41 00 ..) Talk to me on "server_port", here's a cookie
...
192.168.0.50 : client_port -> 192.168.0.255 : server_port (f1 41 00 ..) Talk to me on "client_port", here's your cookie back
192.168.0.129 : server_port -> 192.168.0.50. : client_port (f1 42 00 ..) Channel established?
aaaaa: Random high port >1024 chosen at runtime
32108: Fixed port for broadcast to the network on which the camera is always listening
server_port: Random high port >1024 chosen at runtime by the camera for ongoing communication
client_port: Random high port >1024 chosen at runtime by the client, can be the same as aaaaa above.
Seems to follow this pattern, but some messages are repeated (and acknowledged as repeats in the acknowledgement).
- Command sent
- Acknowledgement of command received
- Response sent
- Acknowledgement of response received
Command sent (37 or 40 bytes?)
| Byte offset | Value | Purpose(?) |
|---|---|---|
| 0 | F1 | Constant - present in all commands / acks / responses |
| 1 | D0 | Message sent |
| 2 | 00 | Constant |
| 3 | xx | 20 or 24, varies by command |
| 4 | D1 | Constant |
| 5 | 00 | Constant |
| 6 | xx | Message index (MSB) N.B. Server and client both maintain separate counters |
| 7 | xx | Message index (LSB) |
| 8 | 88 | Constant |
| 9 | 88 | Constant |
| 10 | 76 | Constant |
| 11 | 76 | Constant |
| 12 | xx | 04 or 08, varies by command |
| 13 | 00 | Constant |
| 14 | 00 | Constant |
| 15 | 00 | Constant |
| 16 | xx | Varies by command |
| 17 | xx | Varies by command |
| 18-31 | 00 | Constant |
| 32 | xx | Varies by command |
| 33 | xx | Varies by command |
| 34 | 00 | Constant |
| 35 | 00 | Constant |
| 36 | xx | Varies by command |
| 37 | ?? | Optional on some commands, 00 if present |
| 38 | ?? | Optional on some commands, 00 if present |
| 39 | ?? | Optional on some commands, 00 if present |
xx shows variable contents, fixed values as stated
Byte 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 ...
Value F1 D0 00 xx D1 00 xx xx 88 88 76 76 xx 00 00 00 xx xx ...
| Pan/Tilt | Byte 03 | 12 | 16 | 17 | 32 | 33 |
|---|---|---|---|---|---|---|
| Tilt up | 24 | 08 | 01 | 10 | 02 | 08 |
| Tilt down | 24 | 08 | 01 | 10 | 01 | 08 |
| Pan left | 24 | 08 | 01 | 10 | 06 | 08 |
| Pan right | 24 | 08 | 01 | 10 | 03 | 08 |
| Video definition | Byte 03 | 12 | 16 | 17 |
|---|---|---|---|---|
| Toggle SD/HD | 20 | 04 | 03 | 00 |
(How does the app stay in sync with the camera to know whether it's currently SD/HD, or does this only show up in the format of the video frames?)
| Video definition | Byte 03 | 12 | 16 | 17 |
|---|---|---|---|---|
| On | 20 | 04 | 04 | 00 |
| Off | 20 | 04 | 05 | 00 |
| Video definition | Byte 03 | 12 | 16 | 17 | 36 |
|---|---|---|---|---|---|
| Low | 24 | 08 | 1A | 81 | 28 |
| Medium | 24 | 08 | 1A | 81 | 4B |
| High | 24 | 08 | 1A | 81 | 55 |
| Video definition | Byte 03 | 12 | 16 | 17 | 32 | 33 |
|---|---|---|---|---|---|---|
| Low | 24 | 08 | 24 | 03 | xx | 19 |
| Medium | 24 | 08 | 24 | 03 | xx | 32 |
| High | 24 | 08 | 24 | 03 | xx | 4B |
| Sound on | 08 | 24 | 24 | 03 | 00 | xx |
| Sound off | 08 | 24 | 24 | 03 | 01 | xx |
| Video definition | Byte 03 | 12 | 16 | 17 | 36 |
|---|---|---|---|---|---|
| Indoor (50Hz) | 24 | 08 | 60 | 03 | 01 |
| Outdoor (60Hz) | 24 | 08 | 60 | 03 | 00 |
| Video definition | Byte 03 | 12 | 16 | 17 | 36 |
|---|---|---|---|---|---|
| Normal | 24 | 08 | 70 | 03 | 00 |
| Rotated | 24 | 08 | 70 | 03 | 03 |
(Sent immediately after channel setup and before video feed begins) Bytes 07-08 are set to 00 00 - resetting command counter?
0000 F1 D0 00 64 D1 00 00 00 88 88 76 76 48 00 00 00 ...d......vvH...
0010 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 31 32 33 34 35 36 37 38 00 00 00 00 00 00 00 00 12345678........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 ........
Current status(?) response
0000 F1 D0 00 28 D1 00 00 00 88 88 76 76 0C 00 00 00 ...(......vv....
0010 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 07 00 00 01 ............
(Sent immediately before video data stream starts)
0000 F1 D0 00 30 D1 00 00 01 88 88 76 76 14 00 00 00 ...0......vv....
0010 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 ....
Start video(?) response
0000 F1 D0 00 34 D1 00 00 01 88 88 76 76 18 00 00 00 ...4......vv....
0010 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 03 00 00 00 80 02 00 00 68 01 00 00 52 00 00 00 ........h...R...
0030 00 00 00 00 00 00 00 00 ........
Send back to confirm receipt of commands or data frames or responses.
| Byte offset | Value | Purpose(?) |
|---|---|---|
| 0 | F1 | Constant - present in all commands / acks / responses |
| 1 | D1 | Message acknowledgment? |
| 2 | 00 | Constant |
| 3 | xx | Useful length in bytes. 06 indicates 1x two-byte ack, 08 for two and 0C for four, 26 for eleven |
| 4 | D1 | Constant |
| 5 | 02 | Constant |
| 6 | xx | Number of acks in this message (MSB) |
| 7 | xx | Number of acts in this message (LSB) |
| 8 | xx | Ack #1 MSB |
| 9 | xx | Ack #1 LSB |
| 10 | xx | Ack #2 MSB (or 00) |
| 11 | xx | Ack #2 LSB (or 00) |
| 12 | xx | Ack #3 MSB (or 00) |
| 13 | xx | Ack #3 LSB (or 00) |
| 14 | xx | Ack #4 MSB (or 00) |
| 15 | xx | Ack #4 LSB (or 00) |
| 16 | xx | Ack #5 MSB (or 00) |
| 17 | xx | Ack #5 LSB (or 00) |
| 18 | xx | Ack #6 MSB (optional) |
| 19 | xx | Ack #6 LSB (optional) |
| 20 | xx | Ack #7 MSB (optional) |
| 21 | xx | Ack #7 LSB (optional) |
| .. | xx | etc to a maximum offset of 83? |
Sent back and forth while no other traffic is flowing e.g. video stream. Timeout seems to be around 1-2 seconds of silence before this is initiated.
Either side (client or server) starts the keepalive exchange with a message containing a 4 byte payload:
F1 E0 00 00
The other side first responds with
F1 E1 00 00
Then the two switch roles, the other side sends
F1 E0 00 00
And the original initiator completes the keep alive by responding
F1 E1 00 00
First video frames received:
0000 F1 D0 04 04 D1 02 00 01 F1 0F 86 19 63 4B 00 00 ............cK..
0010 F4 E3 81 00 01 00 00 00 61 66 0A 00 01 00 00 00 ........af......
0020 03 00 00 00 00 00 00 00 00 00 00 01 47 4D 40 1E ............GM@.
0030 99 A0 28 0B FE 58 40 00 00 FA 00 00 13 88 21 00 ..(..X@.......!.
0040 00 00 01 48 EE 3C 80 00 00 00 01 45 B8 02 08 FF ...H.<.....E....
<snipped>
0000 F1 D0 04 04 D1 02 00 02 D9 A0 7A 96 74 7D 5C CB ..........z.t}\.
0010 D5 B5 40 90 54 B1 29 21 73 C2 AC 48 96 10 5A 91 ..@.T.)!s..H..Z.
0020 5D E0 51 AC 61 F6 2E 91 E7 25 39 A4 A1 2A 66 74 ].Q.a....%9..*ft
0030 40 1A 77 1C 47 27 4C 19 76 AA 14 A7 49 F8 24 CB @.w.G'L.v...I.$.
0040 93 F5 D6 4C B5 FF 92 21 48 FE C5 C1 65 CD 08 AB ...L...!H...e...
<snipped>
0000 F1 D0 04 04 D1 02 00 03 C7 6B FB 9B D9 77 C3 0F .........k...w..
0010 E4 E7 54 EB FA 0B 31 C8 3C 29 20 8A D1 29 01 08 ..T...1.<) ..)..
0020 FB 50 0E 04 95 F0 2E F0 8B 81 1E 26 81 5D EF 36 .P.........&.].6
0030 D2 91 5E 0B B9 95 BF 9A AD 71 B5 52 F4 C8 B1 23 ..^......q.R...#
0040 47 37 E6 49 F6 74 59 AA F0 7A 35 6B 0F DF B6 B8 G7.I.tY..z5k....
<snipped>
...etc.
Video frames acknowledgement Includes frame count (00 11) at bytes 07/08, and individual message numbers in byte pairs from 09/10 onwards
0000 F1 D1 00 26 D1 02 00 11 00 01 00 02 00 03 00 04 ...&............
0010 00 05 00 06 00 07 00 08 00 09 00 0A 00 0B 00 0C ................
0020 00 0D 00 0E 00 0F 00 10 00 11 ..........
Includes frame count (00 02) at bytes 07/08, and individual message numbers in byte pairs from 09/10 onwards
0000 F1 D1 00 08 D1 02 00 02 00 12 00 13 00 00 00 00 ................
0010 00 00 ..