Ulf Lamping wrote:
So there seems to be a special "MS Proxy" protocol existing you're
talking about (I just don't know any protocol around ;-)
He *might* be referring to the Microsoft "Remote WinSock Protocol",
which is what our "MS Proxy" dissector dissects.
I infer from some stuff I found on the Web:
http://www.isaserver.org/articles/Understanding_the_Firewall_Client_Control_Channel.html
that it runs on port 1745 for setup operations. We dissect it only on
UDP port 1745; that article says TCP port 1745 is also used.
After the setup is done, the client can then talk to the proxy/firewall;
in our dissector, "add_msproxy_conversation()" sets that up. That's a
different protocol - the packets don't have the RWSP control channel
header, they just have a destination port and address.
I don't know whether the "proxy activity" that's on "a port different
from 80 or 8080" is RWSP setup traffic or session traffic.
If it's setup traffic, the reason why we don't support it for "Decode
As" is probably that we only decode RWSP setup traffic over UDP - if the
"proxy activity" is running over TCP, we'd have to add support for
RWSP-over-TCP.
If it's session traffic, our dissector for that is currently only set up
as a result of RWSP setup traffic in the same session; we don't support
explicitly setting traffic to be proxy session traffic.
You may send a *small* capture file to the list, so the people with more
knowledge than me might get an idea what's the problem or there's a
simple way to fix it.
We'd probably need a capture file like that to figure out what more we
need to do.
