Problem with raw-tcp feature when using version 0.17 (and 0.18)

Dear all,

I’m having trouble with the “raw-tcp” feature of mitmproxy. Everything worked fine with mitmproxy version 0.16. In particular, encrypted websocket traffic got simply logged in plaintext, while I was able to manipulate the “regular” HTTPS traffic using inline scripts. However, after upgrading to 0.17, the “raw-tcp” option appears to cause all the traffic to be treated as non-HTTP, i.e. mitmproxy falls back to plain TCP proxy. The behaviour seems to persist with version 0.18. The weird thing is that I only experience this on my Linux machine (Ubuntu 12.04.5) and on a Mac (El Capitan) the feature seems to work as before. In addition, for some reason I cannot get the --tcp option to match the problematic flows (contains websocket and RTMP) on any version (–ignore works but is not an option because I want to log the websocket traffic). I need to use the Linux machine so my only option currently is to fall back to the 0.16 version. Has anyone experience similar issues? Does someone have an idea what could be causing the problem? Thank you.

BR, Matti

Hi @matti,

that sounds weird - what’s the simplest way for us to reproduce this?


That’s a good question but I don’t have a good answer. Concerning the raw-tcp feature issue, it’s hard to say because I don’t know how specific it is to my setup (there shouldn’t be anything exotic, though). I’ve installed the software using pip. For the --tcp option, when using the following syntax I keep seeing the corresponding flows in mitmproxy console and errors in the message log due to the proxy not understanding websocket: --tcp
The --ignore feature works when I use the same syntax with :443 added to the end. I also tried adding the port with --tcp as well as using quotation marks around the string and using the name that I get when performing a reverse lookup on the corresponding IP address. Note that I cannot rely on IP addresses because I’m not sure which address ranges the servers are using. Am I trying to use wrong syntax?

BR, Matti

So, the best way we can help you with is you can provide me with some form of reproducable instructions how valid HTTP is misclassified as raw TCP for mitmproxy. :wink: