Netzwerk Datenverkehr im eigenen LAN mitschneiden

Alles was kleiner ist als gleich ein ganzes Heimkino ;)
Benutzeravatar
flinke flasche
Beiträge: 3298
Registriert: Montag 16. Dezember 2013, 17:07
Wohnort: Laupheim
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von flinke flasche » Dienstag 22. Dezember 2015, 08:16

Ich habe die codeliste im Netz gefunden, dauert das im Pi so lange?
Muss ich mal über mein demopad testen.


1 --> "KEYCODE_MENU"
2 --> "KEYCODE_SOFT_RIGHT"
3 --> "KEYCODE_HOME"
4 --> "KEYCODE_BACK"
5 --> "KEYCODE_CALL"
6 --> "KEYCODE_ENDCALL"
7 --> "KEYCODE_0"
8 --> "KEYCODE_1"
9 --> "KEYCODE_2"
10 --> "KEYCODE_3"
11 --> "KEYCODE_4"
12 --> "KEYCODE_5"
13 --> "KEYCODE_6"
14 --> "KEYCODE_7"
15 --> "KEYCODE_8"
16 --> "KEYCODE_9"
17 --> "KEYCODE_STAR"
18 --> "KEYCODE_POUND"
19 --> "KEYCODE_DPAD_UP"
20 --> "KEYCODE_DPAD_DOWN"
21 --> "KEYCODE_DPAD_LEFT"
22 --> "KEYCODE_DPAD_RIGHT"
23 --> "KEYCODE_DPAD_CENTER"
24 --> "KEYCODE_VOLUME_UP"
25 --> "KEYCODE_VOLUME_DOWN"
26 --> "KEYCODE_POWER"
27 --> "KEYCODE_CAMERA"
28 --> "KEYCODE_CLEAR"
29 --> "KEYCODE_A"
30 --> "KEYCODE_B"
31 --> "KEYCODE_C"
32 --> "KEYCODE_D"
33 --> "KEYCODE_E"
34 --> "KEYCODE_F"
35 --> "KEYCODE_G"
36 --> "KEYCODE_H"
37 --> "KEYCODE_I"
38 --> "KEYCODE_J"
39 --> "KEYCODE_K"
40 --> "KEYCODE_L"
41 --> "KEYCODE_M"
42 --> "KEYCODE_N"
43 --> "KEYCODE_O"
44 --> "KEYCODE_P"
45 --> "KEYCODE_Q"
46 --> "KEYCODE_R"
47 --> "KEYCODE_S"
48 --> "KEYCODE_T"
49 --> "KEYCODE_U"
50 --> "KEYCODE_V"
51 --> "KEYCODE_W"
52 --> "KEYCODE_X"
53 --> "KEYCODE_Y"
54 --> "KEYCODE_Z"
55 --> "KEYCODE_COMMA"
56 --> "KEYCODE_PERIOD"
57 --> "KEYCODE_ALT_LEFT"
58 --> "KEYCODE_ALT_RIGHT"
59 --> "KEYCODE_SHIFT_LEFT"
60 --> "KEYCODE_SHIFT_RIGHT"
61 --> "KEYCODE_TAB"
62 --> "KEYCODE_SPACE"
63 --> "KEYCODE_SYM"
64 --> "KEYCODE_EXPLORER"
65 --> "KEYCODE_ENVELOPE"
66 --> "KEYCODE_ENTER"
67 --> "KEYCODE_DEL"
68 --> "KEYCODE_GRAVE"
69 --> "KEYCODE_MINUS"
70 --> "KEYCODE_EQUALS"
71 --> "KEYCODE_LEFT_BRACKET"
72 --> "KEYCODE_RIGHT_BRACKET"
73 --> "KEYCODE_BACKSLASH"
74 --> "KEYCODE_SEMICOLON"
75 --> "KEYCODE_APOSTROPHE"
76 --> "KEYCODE_SLASH"
77 --> "KEYCODE_AT"
78 --> "KEYCODE_NUM"
79 --> "KEYCODE_HEADSETHOOK"
80 --> "KEYCODE_FOCUS"
81 --> "KEYCODE_PLUS"
82 --> "KEYCODE_MENU"
83 --> "KEYCODE_NOTIFICATION"
84 --> "KEYCODE_SEARCH"
85 --> "TAG_LAST_KEYCODE"
Grüße
Tobias


Mein Heimkino - Kammer 1

Benutzeravatar
Joker82
Beiträge: 2040
Registriert: Samstag 10. Januar 2015, 18:40
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Joker82 » Dienstag 22. Dezember 2015, 08:52

Hallo Papsi,

schau mal hier, da steuert wohl schon jemand sein Fire TV via FHEM...

http://forum.fhem.de/index.php/topic,28770.15.html
Beamer:Sony VPL-VW760ES|21:9/16:9(151")
Media/Sound/RC/Lights:Kodi|PS4|Marantz AV8805|DCX-2496 Pro|8 T.Amp E800|1 Proline 3000|7 BCC2 5BCC1+4 K13+1 Earthquake Sub(12.5)
HarmonySmart|iPadAir(Constellation)|FHEM
Bild<-Movie Collection

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 09:09

Die Steuerung über ADB habe ich am laufen.
Über Lirc an die Lircrc und von dort über ADB ins Netz.
Das klappt auch mit den Codes von oben.


Ich möchte aber auf eine direkte IP Steuerung umsteigen, da ich alle meine Geräte über IP steuern möchte(Umbau Steuerung :wink: )

Es gibt da eine Firma, die hat die IP Steuerung entschlüsselt znd verkauft jetzt die Infos für 50$ um sie in Steuerungen sla Crestron usw. einzubinden.

http://www.cepro.com/article/fusion_res ... utomation/


Die 50$ können wir doch sparen und finden das selber raus :rock:
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 09:11

Es gibt für IOS auch ne App zum steuern vom FireStick.
Da msste man den Verkehr vom Wlan mitschneiden.

Müsste doch auch mit tcpdump am Raspi gehen...
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 10:02

gusi hat geschrieben:Ich schlage vor, Du schneidet den Verkehr nochmal mit, dann aber mit dem -X und dann schauen wir weiter.
Hier das Ergebnis:

Code: Alles auswählen

09:59:33.911496 IP (tos 0x0, ttl 64, id 65522, offset 0, flags [DF], proto TCP (6), length 100)
    Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [P.], cksum 0x8232 (incorrect -> 0x65e6), seq 1786168770:1786168818, ack 2175982618, win 229, options [nop,nop,TS val 26008 ecr 18858], length 48
        0x0000:  4500 0064 fff2 4000 4006 b8c5 c0a8 0040  E..d..@.@......@
        0x0010:  c0a8 004b c7ef 15b3 6a76 c5c2 81b2 dc1a  ...K....jv......
        0x0020:  8018 00e5 8232 0000 0101 080a 0000 6598  .....2........e.
        0x0030:  0000 49aa 4f50 454e 0e00 0000 0000 0000  ..I.OPEN........
        0x0040:  1800 0000 9708 0000 b0af bab1 7368 656c  ............shel
        0x0050:  6c3a 696e 7075 7420 6b65 7965 7665 6e74  l:input.keyevent
        0x0060:  2031 3900                                .19.
09:59:34.004631 IP (tos 0x0, ttl 64, id 60996, offset 0, flags [DF], proto TCP (6), length 52)
    android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [.], cksum 0xc27b (correct), seq 1, ack 48, win 227, options [nop,nop,TS val 24593 ecr 26008], length 0
        0x0000:  4500 0034 ee44 4000 4006 caa3 c0a8 004b  E..4.D@.@......K
        0x0010:  c0a8 0040 15b3 c7ef 81b2 dc1a 6a76 c5f2  ...@........jv..
        0x0020:  8010 00e3 c27b 0000 0101 080a 0000 6011  .....{........`.
        0x0030:  0000 6598                                ..e.
09:59:34.005692 IP (tos 0x0, ttl 64, id 60997, offset 0, flags [DF], proto TCP (6), length 76)
    android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [P.], cksum 0xb15b (correct), seq 1:25, ack 48, win 227, options [nop,nop,TS val 24593 ecr 26008], length 24
        0x0000:  4500 004c ee45 4000 4006 ca8a c0a8 004b  E..L.E@.@......K
        0x0010:  c0a8 0040 15b3 c7ef 81b2 dc1a 6a76 c5f2  ...@........jv..
        0x0020:  8018 00e3 b15b 0000 0101 080a 0000 6011  .....[........`.
        0x0030:  0000 6598 4f4b 4159 0300 0000 0e00 0000  ..e.OKAY........
        0x0040:  0000 0000 0000 0000 b0b4 bea6            ............
09:59:34.041161 IP (tos 0x0, ttl 64, id 65523, offset 0, flags [DF], proto TCP (6), length 52)
    Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [.], cksum 0x8202 (incorrect -> 0xc254), seq 48, ack 25, win 229, options [nop,nop,TS val 26021 ecr 24593], length 0
        0x0000:  4500 0034 fff3 4000 4006 b8f4 c0a8 0040  E..4..@.@......@
        0x0010:  c0a8 004b c7ef 15b3 6a76 c5f2 81b2 dc32  ...K....jv.....2
        0x0020:  8010 00e5 8202 0000 0101 080a 0000 65a5  ..............e.
        0x0030:  0000 6011                                ..`.
09:59:34.499199 IP (tos 0x0, ttl 64, id 60998, offset 0, flags [DF], proto TCP (6), length 76)
    android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [P.], cksum 0xb404 (correct), seq 25:49, ack 48, win 227, options [nop,nop,TS val 24643 ecr 26021], length 24
        0x0000:  4500 004c ee46 4000 4006 ca89 c0a8 004b  E..L.F@.@......K
        0x0010:  c0a8 0040 15b3 c7ef 81b2 dc32 6a76 c5f2  ...@.......2jv..
        0x0020:  8018 00e3 b404 0000 0101 080a 0000 6043  ..............`C
        0x0030:  0000 65a5 434c 5345 0000 0000 0e00 0000  ..e.CLSE........
        0x0040:  0000 0000 0000 0000 bcb3 acba            ............
09:59:34.499310 IP (tos 0x0, ttl 64, id 65524, offset 0, flags [DF], proto TCP (6), length 52)
    Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [.], cksum 0x8202 (incorrect -> 0xc1dd), seq 48, ack 49, win 229, options [nop,nop,TS val 26066 ecr 24643], length 0
        0x0000:  4500 0034 fff4 4000 4006 b8f3 c0a8 0040  E..4..@.@......@
        0x0010:  c0a8 004b c7ef 15b3 6a76 c5f2 81b2 dc4a  ...K....jv.....J
        0x0020:  8010 00e5 8202 0000 0101 080a 0000 65d2  ..............e.
        0x0030:  0000 6043                                ..`C
09:59:34.499830 IP (tos 0x0, ttl 64, id 65525, offset 0, flags [DF], proto TCP (6), length 76)
    Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [P.], cksum 0x821a (incorrect -> 0xbebd), seq 48:72, ack 49, win 229, options [nop,nop,TS val 26066 ecr 24643], length 24
        0x0000:  4500 004c fff5 4000 4006 b8da c0a8 0040  E..L..@.@......@
        0x0010:  c0a8 004b c7ef 15b3 6a76 c5f2 81b2 dc4a  ...K....jv.....J
        0x0020:  8018 00e5 821a 0000 0101 080a 0000 65d2  ..............e.
        0x0030:  0000 6043 434c 5345 0000 0000 0300 0000  ..`CCLSE........
        0x0040:  0000 0000 0000 0000 bcb3 acba            ............
09:59:34.536169 IP (tos 0x0, ttl 64, id 60999, offset 0, flags [DF], proto TCP (6), length 52)
    android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [.], cksum 0xc1c3 (correct), seq 49, ack 72, win 227, options [nop,nop,TS val 24647 ecr 26066], length 0
        0x0000:  4500 0034 ee47 4000 4006 caa0 c0a8 004b  E..4.G@.@......K
        0x0010:  c0a8 0040 15b3 c7ef 81b2 dc4a 6a76 c60a  ...@.......Jjv..
        0x0020:  8010 00e3 c1c3 0000 0101 080a 0000 6047  ..............`G
        0x0030:  0000 65d2                                ..e.
09:59:34.959538 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 162)
    android-ff82c1528c2e98b.fritz.box.mdns > 224.0.0.251.mdns: [udp sum ok] 0 [1a] PTR (QM)? _KpUE3ep2ohiY._sub._amzn-wplay._tcp.local. _KpUE3ep2ohiY._sub._amzn-wplay._tcp.local. PTR amzn.dmgr:CB430A451863F6E5A8A55FE3D87ADE4F:sw7Vr+6bbA:888507._amzn-wplay._tcp.local. (134)
        0x0000:  4500 00a2 0000 4000 ff11 d95b c0a8 004b  E.....@....[...K
        0x0010:  e000 00fb 14e9 14e9 008e 226e 0000 0000  .........."n....
        0x0020:  0001 0001 0000 0000 0d5f 4b70 5545 3365  ........._KpUE3e
        0x0030:  7032 6f68 6959 045f 7375 620b 5f61 6d7a  p2ohiY._sub._amz
        0x0040:  6e2d 7770 6c61 7904 5f74 6370 056c 6f63  n-wplay._tcp.loc
        0x0050:  616c 0000 0c00 01c0 0c00 0c00 0100 0011  al..............
        0x0060:  9400 3f3c 616d 7a6e 2e64 6d67 723a 4342  ..?<amzn.dmgr:CB
        0x0070:  3433 3041 3435 3138 3633 4636 4535 4138  430A451863F6E5A8
        0x0080:  4135 3546 4533 4438 3741 4445 3446 3a73  A55FE3D87ADE4F:s
        0x0090:  7737 5672 2b36 6262 413a 3838 3835 3037  w7Vr+6bbA:888507
        0x00a0:  c01f                                     ..

Wenn da irgendwelche Fehler auftreten - da kann ich nichts machen.
Das senden geht von ADB aus mit dem Befehl

Code: Alles auswählen

pi@Raspberry:~ $ adb shell input keyevent 19
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 10:08

Evtl. hilft dies hier weiter:
https://android.googlesource.com/platfo ... otocol.txt

Das ist die Erklärung, wie ADB funktioniert. (nach dem ersten überfliegen mit meinem Schulenglisch)
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
Joker82
Beiträge: 2040
Registriert: Samstag 10. Januar 2015, 18:40
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Joker82 » Dienstag 22. Dezember 2015, 10:31

Dann realisiere das gabze doch via FHEM...

Mit FHEM kannst Du sämtliche Signalwege gehen: Funk, Infrarot, HTTP etc...
Beamer:Sony VPL-VW760ES|21:9/16:9(151")
Media/Sound/RC/Lights:Kodi|PS4|Marantz AV8805|DCX-2496 Pro|8 T.Amp E800|1 Proline 3000|7 BCC2 5BCC1+4 K13+1 Earthquake Sub(12.5)
HarmonySmart|iPadAir(Constellation)|FHEM
Bild<-Movie Collection

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 10:40

FHEM nutzt auch nur ADB...

Das möchte ich ja umgehen, da damit keine schnelles bedienen möglich ist.
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
gusi
Beiträge: 1117
Registriert: Donnerstag 19. Mai 2011, 19:06
Wohnort: Linz/Österreich

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von gusi » Dienstag 22. Dezember 2015, 10:45

Papsi hat geschrieben:Die 50$ können wir doch sparen und finden das selber raus :rock:
Klar schaffen wir das :beer2: !

Bei einer Steuerung über TCP/IP hat man aber ein grundsätzliches Problem: viele Geräte lassen sich über TCP/IP nicht einschalten, da im Standby/Off Zustand des Gerätes die Netzwerk Hardware nicht aktiv ist, und deshalb können die "power on" Pakete/Befehle nicht am Empfänger gelesen und umgesetzt werden. Beispiele dafür sind z.B. Onkyo Receiver oder auch mein Oppo BluRay Player. Das Einschalten funktioniert da entweder über "WakeOnLan" (wenn das Gerät es unterstützt) oder über RS232. Das ist auch der Grund warum ich meine Geräte über RS232 steuere und nicht über TCP/IP direkt. Ich schicke meine Befehle von meiner App zu meinem WLAN Router, auf dem ein kleines Programm von mir läuft, dass die Befehle entgegennimmt und dann über RS232 an das jeweilige Gerät weiterleitet.

Zurück zu Deinem Problem. Wenn ich mir den Mitschnitt ansehe, so benötigt das Versenden des Befehls ca. 0,7 Sekunden (von 23:27:43.466845 bis 23:27:44.132793). Das erste Paket ist sicherlich falsch, da stimmen die ack/seq Nummern nicht. Das "incorrect checksum" deutet auch darauf hin, dass da was nicht passt. Allerdings stimmt die checksum bei keinem Paket, das vom raspi versendet wird. Trotzdem antwortet der Stick so, als ob alles stimmt!? Ich glaub fast, dass der Stick die checksum nicht prüft.

Egal. Schauen wir uns doch mal den ersten Mitschnitt an (ich vermute mal android-ff82c1528c2e98b ist der Name des Sticks):

Code: Alles auswählen

    23:27:43.466845 IP (tos 0x0, ttl 64, id 62254, offset 0, flags [DF], proto TCP (6), length 100)
        Raspberry.fritz.box.37707 > android-ff82c1528c2e98b.fritz.box.5555: Flags [P.], cksum 0x8232 (incorrect -> 0x3f92), seq 3804389929:3804389977, ack 1745528538, win 229, options [nop,nop,TS val 29213 ecr 51794], length 48
"seq" ist die Abkürzung für "Sequenz". Hier sollen die Bytes (die Sequenz) von Nummer 3804389929 bis zu Nummer 3804389977 versendet werden. Das sind 48 Bytes (length 48). Gleichzeitig bestätigt der raspi hier den Empfang von Daten bis zur Sequenz-Nummer 1745528538 des Sticks. Wenn man sich die nun folgenden Pakete ansieht, dann merkt man gleich, dass diese Daten nicht stimmen können. Das "cksum incorrect" deutet ja auch darauf hin. Allerdings scheint der Stick keine checksummen prüfung zu machen ...

Code: Alles auswählen

    23:27:43.584416 IP (tos 0x0, ttl 64, id 33270, offset 0, flags [DF], proto TCP (6), length 52)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.37707: Flags [.], cksum 0x80ea (correct), seq 1, ack 48, win 227, options [nop,nop,TS val 66550 ecr 29213], length 0
Der Stick antwortet mit "seq 1" (hier ist kein Bereich angegeben, "length 0" zeigt uns auch, dass da keine Nutzdaten vorhanden sind) und ack 48. D.h. der Stick sagt, er hat bis Byte Nummer 48 alles empfangen. Die angegebenen Nummern vom ersten Paket oben sind also ohne Belang.

Code: Alles auswählen

    23:27:43.585711 IP (tos 0x0, ttl 64, id 33271, offset 0, flags [DF], proto TCP (6), length 76)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.37707: Flags [P.], cksum 0x62ca (correct), seq 1:25, ack 48, win 227, options [nop,nop,TS val 66550 ecr 29213], length 24
Der Stick schickt aber gleich noch was. Nämlich 24 Bytes (sequenz 1 bis 25) und bestätigt nochmal den Empfang bis Byte Nummer 48.

Code: Alles auswählen

    23:27:43.616492 IP (tos 0x0, ttl 64, id 62255, offset 0, flags [DF], proto TCP (6), length 52)
        Raspberry.fritz.box.37707 > android-ff82c1528c2e98b.fritz.box.5555: Flags [.], cksum 0x8202 (incorrect -> 0x80c1), seq 48, ack 25, win 229, options [nop,nop,TS val 29228 ecr 66550], length 0
Der Raspi schickt jetzt ein einfaches ACK zurück. Seq 48 (kein Bereich, length 0) heißt, ich habe keine Nutzdaten, aber "ack 25" heißt soviel, wie ich bestätige Empfang bis Byte Nummer 25.

Code: Alles auswählen

    23:27:44.076712 IP (tos 0x0, ttl 64, id 33272, offset 0, flags [DF], proto TCP (6), length 76)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.37707: Flags [P.], cksum 0x6a72 (correct), seq 25:49, ack 48, win 227, options [nop,nop,TS val 66599 ecr 29228], length 24
Der Stick antwortet wieder mit 24 weiteren Bytes (seq 25:49) und bestätigt (ACK) den Empfang bis Byte 48.

Code: Alles auswählen

    23:27:44.076806 IP (tos 0x0, ttl 64, id 62256, offset 0, flags [DF], proto TCP (6), length 52)
        Raspberry.fritz.box.37707 > android-ff82c1528c2e98b.fritz.box.5555: Flags [.], cksum 0x8202 (incorrect -> 0x804a), seq 48, ack 49, win 229, options [nop,nop,TS val 29274 ecr 66599], length 0
Hier ist die Antwort des raspi: ich habe nix für dich und bestätige Empfang bis Nummer 49.

Code: Alles auswählen

    23:27:44.077169 IP (tos 0x0, ttl 64, id 62257, offset 0, flags [DF], proto TCP (6), length 76)
        Raspberry.fritz.box.37707 > android-ff82c1528c2e98b.fritz.box.5555: Flags [P.], cksum 0x821a (incorrect -> 0x782a), seq 48:72, ack 49, win 229, options [nop,nop,TS val 29274 ecr 66599], length 24
Jetzt schickt der Raspi wieder Daten und zwar 24 Bytes mit der Sequenz 48 bis 72 und bestätigt wird der Empfang bis 49.

Code: Alles auswählen

    23:27:44.132793 IP (tos 0x0, ttl 64, id 33273, offset 0, flags [DF], proto TCP (6), length 52)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.37707: Flags [.], cksum 0x802f (correct), seq 49, ack 72, win 227, options [nop,nop,TS val 66604 ecr 29274], length 0
Hier haben wir wieder die Bestätigung, dass bis Byte Nummer 72 alles empfangen wurde.

Schneide einfach den Verkehr nochmals mit und verwende das -X als Parameter fürs tcpdump. Dann sollten wir auch die Nutzdaten sehen, die in diesen Paketen drin sind. Optional kannst Du den mitgeschnittenen Verkehr auch abspeichern ("-w dateiname") und dann hier anhängen oder mir per PN schicken. Ich schau mir das dann an und analysiere es für Dich.

Ciao,
Christian.

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 10:55

gusi hat geschrieben:...viele Geräte lassen sich über TCP/IP nicht einschalten, da im Standby/Off Zustand des Gerätes die Netzwerk Hardware nicht aktiv ist
Das ist kein Problem. Die Sachen, die ich habe, schalten alle sofort in den normalen Betriebsmodus wenn sie mit Strom versorgt werden.
Dieses läss sich bei allen Geräten einstellen.(glaub Wake on Power nennt sich das).

Leider besitzen meine Geräte(Dune, VU-Box und der FireStick) keine RS232 Schnittstelle, daher der Umweg über IP-Controll.
Beamer und Vorstufe laufen schon über RS232 - fein Sache das :thumbsup:
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Dienstag 22. Dezember 2015, 10:59

Hier mal der Mitschnitt mit Option -X

http://www.heimkino-papsi.de/HCM/FireTV/Taste_hoch.txt
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
gusi
Beiträge: 1117
Registriert: Donnerstag 19. Mai 2011, 19:06
Wohnort: Linz/Österreich

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von gusi » Dienstag 22. Dezember 2015, 11:12

Hallöchen!

Na das schaut doch schon mal super aus! Das letzte Paket in diesem Mitschnitt ist ein Multicast Paket und gehört nicht dazu. Deshalb lasse ich es mal hier weg. Schauen wir uns mal das erste Paket aus dem Mitschnitt an:

Code: Alles auswählen

    09:59:33.911496 IP (tos 0x0, ttl 64, id 65522, offset 0, flags [DF], proto TCP (6), length 100)
        Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [P.], cksum 0x8232 (incorrect -> 0x65e6), seq 1786168770:1786168818, ack 2175982618, win 229, options [nop,nop,TS val 26008 ecr 18858], length 48
            0x0000:  4500 0064 fff2 4000 4006 b8c5 c0a8 0040  E..d..@.@......@
            0x0010:  c0a8 004b c7ef 15b3 6a76 c5c2 81b2 dc1a  ...K....jv......
            0x0020:  8018 00e5 8232 0000 0101 080a 0000 6598  .....2........e.
            0x0030:  0000 49aa 4f50 454e 0e00 0000 0000 0000  ..I.OPEN........
            0x0040:  1800 0000 9708 0000 b0af bab1 7368 656c  ............shel
            0x0050:  6c3a 696e 7075 7420 6b65 7965 7665 6e74  l:input.keyevent
            0x0060:  2031 3900                                .19.
Hier werden 48 Bytes Nutzdaten übertragen. Die Nutzdaten sind im Dump die letzten 48 Bytes, also:

Code: Alles auswählen

            0x0030:  .... .... 4f50 454e 0e00 0000 0000 0000  ..I.OPEN........
            0x0040:  1800 0000 9708 0000 b0af bab1 7368 656c  ............shel
            0x0050:  6c3a 696e 7075 7420 6b65 7965 7665 6e74  l:input.keyevent
            0x0060:  2031 3900                                .19.
Von diesen 48 Bytes sind die letzten 24 Byte scheinbar der Befehl: "shell:input keyevent 19" mit einem abschließendem Byte 00. Die ersten 24 Byte beginnen mit "OPEN", das würde ich mal mit dem Beginn der Datenübertragung gleich setzen. Mit den folgenden 20 Byte kann ich noch nichts anfangen. Schauen wir uns mal die Antwort an.

Code: Alles auswählen

    09:59:34.004631 IP (tos 0x0, ttl 64, id 60996, offset 0, flags [DF], proto TCP (6), length 52)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [.], cksum 0xc27b (correct), seq 1, ack 48, win 227, options [nop,nop,TS val 24593 ecr 26008], length 0
            0x0000:  4500 0034 ee44 4000 4006 caa3 c0a8 004b  E..4.D@.@......K
            0x0010:  c0a8 0040 15b3 c7ef 81b2 dc1a 6a76 c5f2  ...@........jv..
            0x0020:  8010 00e3 c27b 0000 0101 080a 0000 6011  .....{........`.
            0x0030:  0000 6598                                ..e.
Das ist mal ein einfaches "ACK" ohne Nutzdaten (length 0).

Code: Alles auswählen

    09:59:34.005692 IP (tos 0x0, ttl 64, id 60997, offset 0, flags [DF], proto TCP (6), length 76)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [P.], cksum 0xb15b (correct), seq 1:25, ack 48, win 227, options [nop,nop,TS val 24593 ecr 26008], length 24
            0x0000:  4500 004c ee45 4000 4006 ca8a c0a8 004b  E..L.E@.@......K
            0x0010:  c0a8 0040 15b3 c7ef 81b2 dc1a 6a76 c5f2  ...@........jv..
            0x0020:  8018 00e3 b15b 0000 0101 080a 0000 6011  .....[........`.
            0x0030:  0000 6598 4f4b 4159 0300 0000 0e00 0000  ..e.OKAY........
            0x0040:  0000 0000 0000 0000 b0b4 bea6            ............
Ahhh und hier kommt die eigentliche Antwort. 24 Byte Nutzdaten, also:

Code: Alles auswählen

0x0030:  .... .... 4f4b 4159 0300 0000 0e00 0000  ..e.OKAY........
            0x0040:  0000 0000 0000 0000 b0b4 bea6            ............
Der Stick antwortet also mit "OKAY" und 20 Bytes, mit denen ich noch nichts anfangen kann. Das Byte nach OKAY ist 03 und danach kommen 3 x 00 ... das ist verdächtig. Danach kommt ein 0e (also dezimal 14) und im Anschluss noch 15 Bytes ... hmmmm. Schauen wir weiter.

Code: Alles auswählen

    09:59:34.041161 IP (tos 0x0, ttl 64, id 65523, offset 0, flags [DF], proto TCP (6), length 52)
        Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [.], cksum 0x8202 (incorrect -> 0xc254), seq 48, ack 25, win 229, options [nop,nop,TS val 26021 ecr 24593], length 0
            0x0000:  4500 0034 fff3 4000 4006 b8f4 c0a8 0040  E..4..@.@......@
            0x0010:  c0a8 004b c7ef 15b3 6a76 c5f2 81b2 dc32  ...K....jv.....2
            0x0020:  8010 00e5 8202 0000 0101 080a 0000 65a5  ..............e.
            0x0030:  0000 6011                                ..`.
Das ist wieder ein einfaches Ack ohne Nutzdaten.

Code: Alles auswählen

    09:59:34.499199 IP (tos 0x0, ttl 64, id 60998, offset 0, flags [DF], proto TCP (6), length 76)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [P.], cksum 0xb404 (correct), seq 25:49, ack 48, win 227, options [nop,nop,TS val 24643 ecr 26021], length 24
            0x0000:  4500 004c ee46 4000 4006 ca89 c0a8 004b  E..L.F@.@......K
            0x0010:  c0a8 0040 15b3 c7ef 81b2 dc32 6a76 c5f2  ...@.......2jv..
            0x0020:  8018 00e3 b404 0000 0101 080a 0000 6043  ..............`C
            0x0030:  0000 65a5 434c 5345 0000 0000 0e00 0000  ..e.CLSE........
            0x0040:  0000 0000 0000 0000 bcb3 acba            ............
Hier haben wir wieder Daten, die vom Stick zum Raspi geschickt werden:

Code: Alles auswählen

 0x0030:  .... .... 434c 5345 0000 0000 0e00 0000  ..e.CLSE........
            0x0040:  0000 0000 0000 0000 bcb3 acba            ............
Hier haben wir "CLSE", das vom Stick geschickt wird. CLSE könnte "CLOSE" bedeuten und würde zu dem "OPEN" von oben passen.

Code: Alles auswählen

    09:59:34.499310 IP (tos 0x0, ttl 64, id 65524, offset 0, flags [DF], proto TCP (6), length 52)
        Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [.], cksum 0x8202 (incorrect -> 0xc1dd), seq 48, ack 49, win 229, options [nop,nop,TS val 26066 ecr 24643], length 0
            0x0000:  4500 0034 fff4 4000 4006 b8f3 c0a8 0040  E..4..@.@......@
            0x0010:  c0a8 004b c7ef 15b3 6a76 c5f2 81b2 dc4a  ...K....jv.....J
            0x0020:  8010 00e5 8202 0000 0101 080a 0000 65d2  ..............e.
            0x0030:  0000 6043                                ..`C
Das ist wieder ein ACK.

Code: Alles auswählen

    09:59:34.499830 IP (tos 0x0, ttl 64, id 65525, offset 0, flags [DF], proto TCP (6), length 76)
        Raspberry.fritz.box.51183 > android-ff82c1528c2e98b.fritz.box.5555: Flags [P.], cksum 0x821a (incorrect -> 0xbebd), seq 48:72, ack 49, win 229, options [nop,nop,TS val 26066 ecr 24643], length 24
            0x0000:  4500 004c fff5 4000 4006 b8da c0a8 0040  E..L..@.@......@
            0x0010:  c0a8 004b c7ef 15b3 6a76 c5f2 81b2 dc4a  ...K....jv.....J
            0x0020:  8018 00e5 821a 0000 0101 080a 0000 65d2  ..............e.
            0x0030:  0000 6043 434c 5345 0000 0000 0300 0000  ..`CCLSE........
            0x0040:  0000 0000 0000 0000 bcb3 acba            ............
Hier schickt der raspi die Antwort "CLSE" (also close) zurück.

Code: Alles auswählen

    09:59:34.536169 IP (tos 0x0, ttl 64, id 60999, offset 0, flags [DF], proto TCP (6), length 52)
        android-ff82c1528c2e98b.fritz.box.5555 > Raspberry.fritz.box.51183: Flags [.], cksum 0xc1c3 (correct), seq 49, ack 72, win 227, options [nop,nop,TS val 24647 ecr 26066], length 0
            0x0000:  4500 0034 ee47 4000 4006 caa0 c0a8 004b  E..4.G@.@......K
            0x0010:  c0a8 0040 15b3 c7ef 81b2 dc4a 6a76 c60a  ...@.......Jjv..
            0x0020:  8010 00e3 c1c3 0000 0101 080a 0000 6047  ..............`G
            0x0030:  0000 65d2                                ..e.
Und hier haben wir das ACK.

Also die grundsätzlichen Dinge, die dieses Steuerprotokoll ausmachen, haben wir soeben gefunden. Ich würde jetzt vorschlagen, Du schickst jetzt mehrere Befehle und schneidest den Verkehr mit. Dann vergleichst Du die Nutzdaten der einzelnen Pakete und versuchst Regelmäßigkeiten in den "ersten" 24 Byte zu finden (also diejenigen, in denen "OPEN", "CLSE" o.ä. stehen). Sind die vielleicht immer gleich, oder ändern sie sich auch mal? Sind da vielleicht irgendwelche Checksummen eingebaut usw.

Ich denke, Papsi, jetzt bist Du wieder dran :-).

Viel Spaß!

Ciao,
Christian.

Benutzeravatar
gusi
Beiträge: 1117
Registriert: Donnerstag 19. Mai 2011, 19:06
Wohnort: Linz/Österreich

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von gusi » Dienstag 22. Dezember 2015, 12:07

Hallöchen!

Ich bin ein Stück weiter. Ich weiß jetzt, wie die letzen 4 Bytes berechnet werden. Beispiel:

Code: Alles auswählen

0x0030:  .... .... 4f4b 4159 0300 0000 0e00 0000  ..e.OKAY........
0x0040:  0000 0000 0000 0000 b0b4 bea6            ............
Die Nutzdaten fangen mit "OKAY" an. In Hex sind das die Bytes 4f, 4b, 41, 59. Invertiert man diese Bytes jetzt (sprich tauscht man alle 0 durch 1 und 1 durch 0) dann bekommt man b0 b4 be a6 :-). Somit sind von diesen 24 Bytes bereits die ersten 4 und die letzten 4 Bytes bekannt. Die Bytefolge "03 00 00 00" dürfte sowas wie eine Adresse sein. Ich vermute auch "0e 00 00 00" ist eine Adresse. Vielleicht sowas wie Absender-/Empfängeradresse? Wenn ja, dann bleiben noch 8 Bytes die unbekannt sind.

Ciao,
Christian.

Benutzeravatar
Bölling
Beiträge: 406
Registriert: Montag 6. April 2015, 18:22
Wohnort: Münster

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Bölling » Dienstag 22. Dezember 2015, 14:16

:hmmm:

Seit ihr Künstler? Versteh hier nix :lol:
Grüße

Benutzeravatar
gusi
Beiträge: 1117
Registriert: Donnerstag 19. Mai 2011, 19:06
Wohnort: Linz/Österreich

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von gusi » Dienstag 22. Dezember 2015, 15:43

Bölling hat geschrieben::hmmm:

Seit ihr Künstler? Versteh hier nix :lol:
Nein, ... ich kleide mich nicht schwarz, also kann ich kein Künstler sein :grin:

Benutzeravatar
Papsi
Beiträge: 2239
Registriert: Mittwoch 6. April 2011, 18:11
Wohnort: Vohburg
Kontaktdaten:

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von Papsi » Freitag 25. Dezember 2015, 21:02

@ Christian,
wie in meinem Bauthread geschrieben, ist dieses hier erstma verschoben.
Da mache ich später mal weiter, wenn der Rest per LAN läuft. Muss erstmal ne neue Platine(Lan Anbindung) entwerfen :wink:
Ich habe kein Geld für eine Kinokarte - ich hab mir mein eigenes Kino gebaut

Benutzeravatar
gusi
Beiträge: 1117
Registriert: Donnerstag 19. Mai 2011, 19:06
Wohnort: Linz/Österreich

Re: Netzwerk Datenverkehr im eigenen LAN mitschneiden

Beitrag von gusi » Freitag 25. Dezember 2015, 21:13

Kein Problem. Wenn Du Hilfe brauchst, melde Dich einfach :)

Antworten