I have an app that talks to a rabbitmq server. The message exchange occurs trough the STOMP protocol. My question is why are the STOMP messages from client to server not decoded in the user interface i.e. when i right click and use the "Follow TCP Stream" menuu in the wireshark i do not see the communication from the client to the server decoded. Websocket protocol defines something called masking key which basically say that the traffic from client to server should be encoded with that random masking key value. When i click on any websocket packet in Wireshark i see two fields i.e. "Payload" and "Unmask Payload", the last one basically represent the payload after the masking key has been applied. Now the question is why I am seeing the value of the payload instead of the "Unmasked Payload" when i right click and choose "Follow TCP Stream". For decoding stomp i am using the (stomp.lua) plugin https://github.com/ficoos/wireshark-stomp-plugin the link to an example trace file is here Basically this is the follow up question from the one i posted in the stackoverflow i.e. link text asked 04 Jul '15, 01:07 tito edited 04 Jul '15, 06:57 |
2 Answers:
As @Hadriel noted in his answer on SO, the STOMP lua dissector is written to only dissect the protocol when carried directly over TCP. To modify the dissector to dissect traffic carried over WebSocket you'll have to modify the dissector's registration function at the bottom of the script to register with the WebSocket dissector instead of the TCP dissector:
If you now set the STOMP port preference (still called TCP unless you also modify that part of the script as well) to "8080", then the traffic is correctly dissected as STOMP. answered 04 Jul '15, 08:44 grahamb ♦ |
For posterity's sake, below is a corrected version of the plugin with bugs fixed:
answered 04 Jul ‘15, 09:28 Hadriel edited 04 Jul ‘15, 14:53 @Hadriel i get the following startup erro when i replaced the old pluggin with this one Lua: Error During execution of prefs apply callback: [string “/home/mike/.wireshark/plugins/stomp.lua”]:209: bad argument #1 to ‘remove’ (string expected, got boolean) (04 Jul ‘15, 10:22) tito Ooops. I suppose I should actually test it before posting. :) I just updated it - it should be good now. The line:
…should have been:
(04 Jul ‘15, 11:01) Hadriel @Hadriel there is one more error i.e. line 51 p_stomp.prefs[“websocket_port”] = Pref.uintl( should be p_stomp.prefs[“websocket_port”] = Pref.uint( however now when i put the filter stomp in wireshark i am not able to see any messages. Could you please take another look into it. ? (04 Jul ‘15, 11:35) tito It works for me (with the one line’s type fixed). Since you found the original “ If your real live traffic uses a different port number, are you sure you’re putting in the correct server port number in that preference field? It needs to be the TCP port number of the HTTP server - namely, the destination TCP port number of the connection-creating TCP SYN. (well, technically it’s the TCP source port number that the HTTP Response came back from; but in practical terms that will be the destination TCP port number of the first TCP SYN of the connection) (04 Jul ‘15, 11:48) Hadriel One other thing to note with the above version is that if the STOMP preferences for both tcp and websocket ports are the same, and the STOMP is carried over WebSocket, then the STOMP registration in the tcp table will prevent the WebSocket dissector having a go at it first leading to the STOMP dissector not being called. I suppose n any particular environment STOMP is likely either run over tcp or WebSocket, but not both at the same time. Maybe the port prefs should be exclusive? (04 Jul ‘15, 12:55) grahamb ♦ OK, added a check for same port numbers, and warning/error message. (04 Jul ‘15, 14:54) Hadriel showing 5 of 6 show 1 more comments |
Also, the "Follow TCP Stream" dialog window will continue to just show what it showed originally, because all it does is show the TCP stream contents, which the masked payload is. (well... for websocket it will also show the unmasked payload in the "Follow TCP Stream" output, because the websocket dissector is clever and sets the unmasked payload to be treated as real buffer content of the original TCP stream)
Oh, and there's a small bug in the original
stomp.lua
script from github: it adds the proto to the TCP port dissector table every timep_stomp.init()
is invoked - but that will happen a lot (like multiple times per file lifetime), so it will keep adding the dissector to the table again and again. And it won't remove it from a previous table if you changed the port number preference.@grahamb @Hadriel many thanks for the response. I have done the changes that you suggested and i can now see that the traffic is dissected correctlly in wireshark main window but i still have one question regarding the comment that @Hadriel made i..e "well... for websocket it will also show the unmasked payload in the "Follow TCP Stream" output," in "Follow TCP Stream" i still only see the traffic comming from the server to the client in a clear text but the traffic from client to server is still masked. Do I understand that correctly that i shell see the unmasked payload in the "Follow TCP Stream" for the traffic that client -> server in case i am running stomp over ws ?
Hmmm... I see what you mean - I wasn't paying close attention and assumed it was showing the masked and unmasked payload of the same message, but it's not.
The actual content of the websocket payload coming back from the server to the client is not masked to begin with, and the "Follow TCP Stream" output is just showing it as it originally was.
That's probably just how "Follow TCP Stream" works - showing TCP stream content as raw bytes. I'm not sure there's any other choice with that particular feature.
If you just want to see the STOMP packets, you could use a display filter of "
stomp
", which will at least only display the frames that contain STOMP messages. But you'll still have to click on each one to see it. Alternatively, you could edit the Lua script to open a TextWindow and put all the STOMP message content in it.