heatpumpMonitor

Working with tcpdump and interpreting its output

Asked by alphaomega

Hello,

I would like to start this thread to exchange experience with tcpdump and interpreting its output.
Andreas has already described the prerequisites to be able to sniff the network traffic to/ from the heatpump in Robert's Wiki at: http://heatpumpmonitor.penz.name/heatpumpmonitorwiki/SetupDebian

Here a short English translation:

1. In your Linux- (e.g. Debian) or Unix-like system, do an "apt-get install ser2net tcpdump" to install ser2net and tcpdump.
I don't know how to use ser2net or tcpdump in Windows, but you will need Windows later to run the heatpump software of the manufacturer. Maybe you find a way to get these two tools to work under Windows (e.g. with Wine, or there are ready binaries).

2. In Linux, edit /etc/ser2net.conf like below (2020 in the example is the port, /dev/ttyUSB0 is the device where the heatpump is connected to):
##BANNER:banner ...
2020:telnet:600:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT

3. In Linux, restart ser2net with "/etc/init.d/ser2net restart".

4. In Windows, install the heatpump software of the manufacturer and the software "HW Virtual Serial Port" (use Google to find it) and configure the port of your Linux system where the heatpump is connected to. Only the second tab of the Windows tool ("Virtual Serial Port") needs to be configured (see screenshot in Wiki for details) and click on "Create COM".

5. In Windows, start the heatpump software of the manufacturer, adjust the correct software version of your heatpump and the connection (the COM port you have selected in step 4) and connect to your heatpump.

6. In Linux, do a "tcpdump port 2020 -x" (warning: it may happen that tcpdump cannot be quit by ctrl-c).

7. In Windows, read parameters with your manufacturer's software, e.g. current heating values.

8. In Linux, watch the output of tcpdump (hex) and try to compare the values with those of the software in Windows (decimal). This obviously is the most difficult part and the reason why I start this thread here. ;-)

Best regards, Alphaomega

Question information

Language:
English Edit question
Status:
Solved
For:
heatpumpMonitor Edit question
Assignee:
No assignee Edit question
Solved by:
Robert Penz
Solved:
Last query:
Last reply:
Revision history for this message
alphaomega (alpha-omega) said : 		#1

First I try to read the "set values" of my heatpump (HP) parameters (P), i.e. the values which I had set e.g. for the following "normal" parameters:
P1 "room temperature" (21.5°C),
P4 "domestic heating water" (DHW or "Brauchwassertemp.") (45°C),
P7 "fan" ("Lüfterstufe") (2).

This at first glance may make less sense, because one is more interested in measured values instead of set values. However, the latter are easier to find in tcpdump, I believe, because they do not change all the time. And why not later present them in your own webserver for your information?

With "tcpdump port 2020 -q -c 10 -x" I listen on port 2020 (see post above) with a little bit quieter output (-q) and capture 10 packets (for a first try this should suffice). For the -x (and other options), please refer to the tcpdump man pages:
http://www.tcpdump.org/tcpdump_man.html

Interestingly, after 3 tries I get 3 different outputs already in the first packet, i.e. there seems to be changing data even for unchanged values (maybe some checksums over time?). Also have a look at Robert's findings here:
http://robert.penz.name/heat-pump-lwz
... and also VViki's comments here:
https://answers.launchpad.net/heatpumpmonitor/+question/100347

So here are the first packets, captured three times, with slightly different data (though I have not changed anything at my HP).
Please also note the traffic directions: nslu (Linux), xp (Windows), fb1 (router)

1st run:

root@nslu ~ $ tcpdump port 2020 -q -c 10 -x
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:27:07.694017 IP xp.fb1.1081 > nslu.fb1.2020: tcp 1
 0x0000: 4500 0029 5d1b 4000 8006 b857 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 680a e855 dfec
 0x0020: 5018 7fce 0707 0000 0200 0000 0000
08:27:07.715750 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8bd1 4000 4006 c9a2 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 dfec 0530 680b
 0x0020: 5010 0b68 7d75 0000
08:27:07.702974 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8bd2 4000 4006 c9a0 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 dfec 0530 680b
 0x0020: 5018 0b68 6d6c 0000 10
08:27:07.803854 IP xp.fb1.1081 > nslu.fb1.2020: tcp 0
 0x0000: 4500 0028 5d1c 4000 8006 b857 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 680b e855 dfed
 0x0020: 5010 7fce 090e 0000 0000 0000 0000
08:27:07.904322 IP xp.fb1.1081 > nslu.fb1.2020: tcp 1
 0x0000: 4500 0029 5d1d 4000 8006 b855 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 680b e855 dfed
 0x0020: 5018 7fce 0805 0000 0100 0000 0000
08:27:07.942475 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8bd3 4000 4006 c9a0 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 dfed 0530 680c
 0x0020: 5010 0b68 7d73 0000
08:27:07.943397 IP xp.fb1.1081 > nslu.fb1.2020: tcp 5
 0x0000: 4500 002d 5d1e 4000 8006 b850 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 680c e855 dfed
 0x0020: 5018 7fce eed7 0000 0018 1710 0300
08:27:07.943574 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8bd4 4000 4006 c99f c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 dfed 0530 6811
 0x0020: 5010 0b68 7d6e 0000
08:27:07.952915 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8bd5 4000 4006 c99d c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 dfed 0530 6811
 0x0020: 5018 0b68 6d65 0000 10
08:27:07.982835 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8bd6 4000 4006 c99c c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 dfee 0530 6811
 0x0020: 5018 0b68 7b64 0000 02
10 packets captured
13 packets received by filter
0 packets dropped by kernel

2nd run:

root@nslu ~ $ tcpdump port 2020 -q -c 10 -x
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:27:46.236218 IP xp.fb1.1081 > nslu.fb1.2020: tcp 1
 0x0000: 4500 0029 5e1b 4000 8006 b757 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 68a4 e855 e1b3
 0x0020: 5018 7f95 04df 0000 0200 0000 0000
08:27:46.254304 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8c89 4000 4006 c8ea c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e1b3 0530 68a5
 0x0020: 5010 0b68 7b14 0000
08:27:46.242954 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8c8a 4000 4006 c8e8 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e1b3 0530 68a5
 0x0020: 5018 0b68 6b0b 0000 10
08:27:46.427788 IP xp.fb1.1081 > nslu.fb1.2020: tcp 0
 0x0000: 4500 0028 5e1c 4000 8006 b757 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 68a5 e855 e1b4
 0x0020: 5010 7f95 06e6 0000 0000 0000 0000
08:27:46.443195 IP xp.fb1.1081 > nslu.fb1.2020: tcp 4
 0x0000: 4500 002c 5e1d 4000 8006 b752 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 68a5 e855 e1b4
 0x0020: 5018 7f95 edc2 0000 0100 1817 0000
08:27:46.482467 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8c8b 4000 4006 c8e8 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e1b4 0530 68a9
 0x0020: 5010 0b68 7b0f 0000
08:27:46.483087 IP xp.fb1.1081 > nslu.fb1.2020: tcp 2
 0x0000: 4500 002a 5e20 4000 8006 b751 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 68a9 e855 e1b4
 0x0020: 5018 7f95 f6d4 0000 1003 0000 0000
08:27:46.483261 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8c8c 4000 4006 c8e7 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e1b4 0530 68ab
 0x0020: 5010 0b68 7b0d 0000
08:27:46.492890 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8c8d 4000 4006 c8e5 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e1b4 0530 68ab
 0x0020: 5018 0b68 6b04 0000 10
08:27:46.532853 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8c8e 4000 4006 c8e4 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e1b5 0530 68ab
 0x0020: 5018 0b68 7903 0000 02
10 packets captured
11 packets received by filter
0 packets dropped by kernel

3rd run:

root@nslu ~ $ tcpdump port 2020 -q -c 10 -x
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:28:36.777550 IP xp.fb1.1081 > nslu.fb1.2020: tcp 1
 0x0000: 4500 0029 5f36 4000 8006 b63c c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 6936 e855 e379
 0x0020: 5018 7f5c 02c0 0000 0200 0000 0000
08:28:36.800153 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8d3d 4000 4006 c836 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e379 0530 6937
 0x0020: 5010 0b68 78bc 0000
08:28:36.782943 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8d3e 4000 4006 c834 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e379 0530 6937
 0x0020: 5018 0b68 68b3 0000 10
08:28:36.892376 IP xp.fb1.1081 > nslu.fb1.2020: tcp 0
 0x0000: 4500 0028 5f37 4000 8006 b63c c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 6937 e855 e37a
 0x0020: 5010 7f5c 04c7 0000 0000 0000 0000
08:28:36.983696 IP xp.fb1.1081 > nslu.fb1.2020: tcp 1
 0x0000: 4500 0029 5f38 4000 8006 b63a c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 6937 e855 e37a
 0x0020: 5018 7f5c 03be 0000 0100 0000 0000
08:28:37.022476 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8d3f 4000 4006 c834 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e37a 0530 6938
 0x0020: 5010 0b68 78ba 0000
08:28:37.022978 IP xp.fb1.1081 > nslu.fb1.2020: tcp 5
 0x0000: 4500 002d 5f39 4000 8006 b635 c0a8 b207
 0x0010: c0a8 b203 0439 07e4 0530 6938 e855 e37a
 0x0020: 5018 7f5c ea90 0000 0018 1710 0300
08:28:37.023145 IP nslu.fb1.2020 > xp.fb1.1081: tcp 0
 0x0000: 4500 0028 8d40 4000 4006 c833 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e37a 0530 693d
 0x0020: 5010 0b68 78b5 0000
08:28:37.032913 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8d41 4000 4006 c831 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e37a 0530 693d
 0x0020: 5018 0b68 68ac 0000 10
08:28:37.042807 IP nslu.fb1.2020 > xp.fb1.1081: tcp 1
 0x0000: 4500 0029 8d42 4000 4006 c830 c0a8 b203
 0x0010: c0a8 b207 07e4 0439 e855 e37b 0530 693d
 0x0020: 5018 0b68 76ab 0000 02
10 packets captured
17 packets received by filter
0 packets dropped by kernel

Revision history for this message
alphaomega (alpha-omega) said : 		#2

Sorry, the 10 packages are not enough. They seem to contain other than real data, maybe the overhead?
Since I am new to tcpdump (therefore this thread), and I do not have so much knowledge about network traffic headers etc., I just gave it a try, but the real HP data obviously comes later, but I do not want to flood this thread with so much output.
So first I will try to find out how to make tcpdump show only the relevant data, i.e. without any overhead/ headers.
If someone has some helpful hints, I would appreciate it very much. Thank you.

Revision history for this message
Robert Penz (robert-penz-name) said : 		#3

I don't recommend using tcpdump for this. I would use a serial interface (rs-232) sniffer on the windows system the heatpump software is running and it works also if you Desktop is connected directly to the heat pump. With tcpdump you get also the IP header stuff in the packets. So if you're using tcpdump to capture the traffic anyway than write the packets into a file with -s0 -w filename and take a look at it with wireshark. There you'll get marked which bytes belong to the header and which not.
Btw, i don't see a reason you don't use wireshark directly as the rs-232 traffic goes over your windows/linux desktop anyway and can be therefore also be captured.

Revision history for this message
alphaomega (alpha-omega) said : 		#4

Well, I followed Andreas' recommendation on your Wiki pages. To be honest, both tcpdump and wireshark are new to me, so I have no clue yet. But thanks a lot for your hint re. the headers etc. I will save the tcpdump and then look at it with wireshark or with the latter directly.
What I found nice with ser2net, the Windows "HW Virtual Serial Port" tool and tcpdump was the fact that this does not block my COM port. Before, I had tried various free serial interface (rs-232) sniffers under Windows, but they all blocked the COM port, so I could not use the HP manufacturer's Windows software to read the data from my HP. If you have a good hint re. a free Windows rs-232 sniffer which does not block the COM port, please let me know. Else, I will give wireshark directly a try, though I do not know how to set this up, i.e. on which system to let it run, if I then still need the Windows "HW Virtual Serial Port" tool and ser2net.
While the HP manufacturer's software runs under Windows (obviously), my HP is connected to my Cisco/ Linksys NSLU2 (a Linux-based NAS), and I do not want to unplug these and re-plug my HP to my Windows (because it runs virtually on my MacBook, and I do not want to always go down with it into the cellar with it ;-))

Revision history for this message
alphaomega (alpha-omega) said : 		#5

Hi Robert,
is it possible for your to remove my above posted hex output (1st to 3rd run)? It was unnecessary (header), is too long and thus makes this thread not very reader-friendly. Thank you very much and sorry for any inconvenience.
Kind regards, Alphaomega

Revision history for this message
Best Robert Penz (robert-penz-name) said : 		#6

I don't see any way to remove something. Sorry.

About the serial monitor, you did look for the wrong program. You don't need a program that is able to sniff on a communication of 2 other devices, but for one that sniffs the communication of an other windows program to and from the RS-232.

I'm using HHD Free Serial Port Monitor Version 3.31 which I got from there: http://www.serial-port-monitor.com/ to take a look at windows programs that talk to the serial interface.

Revision history for this message
alphaomega (alpha-omega) said : 		#7

Re. editing posts, the issue had been posted at Launchpad as a "bug" entry (i.e. feature request) already in 2007, but never solved. :-/
https://bugs.launchpad.net/launchpad-answers/+bug/119420
So there is indeed nothing we can do about it, except nagging the people from Launchpad to finally solve this hassle.

Thanks for the hint re. the software, I will have a look, too.

Revision history for this message
Marc Domachowski (marc-domachowski) said : 		#8

Just out of curiosity (as I do not have the SE software yet) - would "ser2net" run in parallel to the heatpumpmonitor.py scripts, or do I have to stop heatpumpmonitor.py?

Cheers,
Marc

Revision history for this message
alphaomega (alpha-omega) said : 		#9

Thanks Robert Penz, that solved my question.