This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Can’t capture http post from web server

0

Hello, I have an IIS web server (IP=Y.Y.Y.Y) running under Windows 2008 R2. One test ASP.NET application is running under this IIS instance.

I access this web application from a client (IP=X.X.X.X) from which I capture traffic with Wireshark and I see all HTTP requests (GET and POST).

In the mean time I capture traffic on the server with Wireshark too but I only see GET requests coming from the client, not POST requests.

I filtered traffic like this : ip.addr == X.X.X.X OR ip.addr == Y.Y.Y.Y

Why Wireshark doesn't see these POST requests when capturing from the server? (I also tried to capture traffic with netmon from Microsoft but I ran into the same problem...)

asked 07 Dec '12, 01:14

bigproblem's gravatar image

bigproblem
1111
accept rate: 0%


One Answer:

0

Why Wireshark doesn't see these POST requests when capturing from the server? (I also tried to capture traffic with netmon from Microsoft but I ran into the same problem...)

There is really no reason why the POST requests would be "ignored" by Wireshark (according to your description of the capture setup). Are you sure those POST requests are going to the same server?

Regards
Kurt

answered 11 Dec '12, 07:17

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thank for your response Kurt but I am really sure the requests are going to the server because I can seen them in IIS logs (from this server).

I have to precise that the requests that I can't capture with Wireshark are corresponding to some postback actions (button clic from an aspx page).

Is there any IIS mechanism that could catch the requests before Wireshark ?

I really don't understand what's going on with these requests...

(12 Dec '12, 08:10) bigproblem

Can you upload a sample trace on e.g. cloudshark - given that there are no sensitive details in it?

(12 Dec '12, 08:12) Landi

Thank for your response Kurt but I am really sure the requests are going to the server because I can seen them in IIS logs (from this server).

Strange.

I have to precise that the requests that I can't capture with Wireshark are corresponding to some postback actions (button clic from an aspx page).

Wireshark does not care who/what generated the POST request, so if the request was sent to the network and Wireshark was able to see it, it should be in the capture file. Where did you capture? At the client or at the server? Is there any difference, if you do both?

Is there any IIS mechanism that could catch the requests before Wireshark ?

Not that I know of.

What if that the POST requests are going to a port that Wireshark does not recognize as HTTP (80,3128,8080,etc.) and thus you can't see the POST request in the Info column. The request would be in the capture file, but you would have to look at the data in a different way to see the POST request (select one packet of the tcp connection with the "non standard port", right click it and select "Decode as").

(12 Dec '12, 08:24) Kurt Knochner ♦

Sorry Landi I can't share the capture file, I've made the capture from our production server so there is sensitive content...

Kurt yes it is very strange and that's why I post my problem here...

I have tried to capture from the client and from the server at the same time : the result is many requests seen on client capture (arround 200 packets) and very few on server capture (arround 10 packets).

I didn't filter the capture on HTTP, I just used the filter that you can find in my first post. I really don't see any packets corresponding to the postback requests made from the client...

(12 Dec '12, 08:48) bigproblem

Very strange. Maybe there is another system on your network with the same IP address as your server and that's the one the client is talking to, instead of the server you think it should be. Please check the ARP cache at the client and compare it to the MAC address of the server.

Client: arp -a | find "x.x.x.x", where x.x.x.x is the IP address of your server.
Server: ifconfig /all

If that's not the problem, then most certainly something is wrong with your capture setup, as you don't see the same amount of packets if you used the same filter.

BTW: If it possible you have adapter teaming on the server and you captured only one physical interface (possibly the wrong one)?

Regards
Kurt

(12 Dec '12, 08:54) Kurt Knochner ♦

Very strange. Maybe there is another system on your network with the same IP address as your server and that's the one the client is talking to, instead of the server you think it should be. Please check the ARP cache at the client and compare it to the MAC address of the server.

I know perfectly our network and there is only one server with this IP address. Moreover I can see the requests in IIS logs of this server so I am sure that requests are processed by this server.

If that's not the problem, then most certainly something is wrong with your capture setup, as you don't see the same amount of packets if you used the same filter.

I have already thought about that but I strictly used the filter that I have done in my first post :

ip.addr == X.X.X.X OR ip.addr == Y.Y.Y.Y

BTW: If it possible you have adapter teaming on the server and you captured only one physical interface (possibly the wrong one)?

There is effectively four physical interfaces but I tried to capture on each of them with the same result. I also tried to capture on all interfaces simultaneously : always the same result :(

Regards

(14 Dec '12, 00:45) bigproblem

well, I don't see a reason why Whireshark should not see the POST requests, while it does see the GET requests, according to your description of the capture setup.

BTW: You did not answer my question regarding the TCP port number of the POST requests? Is that the same as the GET requests (if you capture them on the client).

If nothing else helps, I suggest to capture on a mirror port of the switch, instead of the server itself. See:

http://wiki.wireshark.org/CaptureSetup/Ethernet

(14 Dec '12, 06:53) Kurt Knochner ♦
showing 5 of 7 show 2 more comments