Malformed Packets-App to MS SQL DB server

asked 2020-04-15 16:47:25 +0000

hisrafi
1 ●1 ●2 ●1

updated 2020-04-16 19:32:42 +0000

Guy Harris
19890 ●3 ●634 ●207

New to Wireshark and trying to figure out why i am getting Malformed Packets in the logs. I perform 2 tasks from the application server which communicates to the DB server.

One task- creates a new record Second Task- queries an existing record.

both of them don't return any data from the database server. I ran few wireshark traces and it returns some malformed packets back.

how do you troubleshoot these kind of issues using wireshark? i have read online that malformed packets can be caused by any of these : "Malformed packet means that the protocol dissector can’t dissect the contents of the packet any further. There can be various reasons:

Wrong dissector: Wireshark erroneously has chosen the wrong protocol dissector for this packet. This will happen e.g. if you are using a protocol not on its well known TCP or UDP port. You may try Analyze|Decode As to circumvent this problem. Packet not reassembled: The packet is longer than a single frame and it is not reassembled, see Section 7.8, “Packet Reassembly” for further details. Packet is malformed: The packet is actually wrong (malformed), meaning that a part of the packet is just not as expected (not following the protocol specifications). Dissector is buggy: The corresponding protocol dissector is simply buggy or still incomplete."

however- i am not sure how to complete these tasks. if i can get some advise. would much appreciate it.

Thanks,

edit retag flag offensive close merge delete

Comments

What is your database server and how is the app communicating with it?

grahamb ( 2020-04-15 16:59:57 +0000 )edit

DB is on VMWare- WS 2016-

App server is using SQL to communicate with DB.

hisrafi ( 2020-04-15 17:22:57 +0000 )edit

I meant as in the database server "application" itself. From your comment I suspect it is MS SQL Server, can you confirm? And how is the application communicating with the server, using SQL Server native libraries or something else such as ODBC?

Can you share a capture with the traffic? You can post the capture on a public share, e.g. Google Drive, DropBox etc. and post a link to it back here. Make sure your capture only contains the traffic to your DB server, i.e. use a capture filter of "host dbservername".

grahamb ( 2020-04-15 17:28:26 +0000 )edit

Capturing traffic will provide IP address and some sensitive info which i am not comfortable to share--- what exactly are you looking for?-- yes it is using MS SQL on DB server which is on VM Ware- WS 2016-

Wireshark console display Malformed Packet: TDS in red and below that -

Expert Info (Error/Maclformed) : Malformed Packet (Exception Occured)]

below that there is another view with bunch of characters and numbers on the left side and translation on the right.. e.g.00 50 56 91 2a e6 00 50 56 91 1b 59 08 00 45 02 - PV.* . . P V . . Y..E. has several similar info following below it---

hisrafi ( 2020-04-15 18:28:20 +0000 )edit

There is a TDS sample capture on the wiki
MS SQL Server protocol - Tabular Data Stream (TDS) ms-sql-tds-rpc-requests.cap (17 KB) RPC requests and a few SQL queries Contributor: Emil Wojak
Frame #6 is displayed as [Malformed Packet: TDS]

Chuckc ( 2020-04-16 02:58:54 +0000 )edit

add a comment

Comments

the error did go away. thank you for that, but does it effect application performance? i feel like this error is equivalent to "check your engine" error on your car... you can disable it, but doesn't verify if the actual issue is gone away. I will test the application in the morning and see if it makes any difference. Thanks again!! Learnt something new :) - just to recap i was having issue retrieving data from the DB server via the Application Server (both on Test).

hisrafi ( 2020-04-16 06:29:37 +0000 )edit

Wireshark will show you if there are network issues, such as malformed packets, missing packets etc., but if the issue is app or server performance, then you will have to infer that by looking at the time between requests and responses. Remember Wireshark shows what has happened not why it happened.

grahamb ( 2020-04-16 09:46:53 +0000 )edit

i am not sure which time requests and response i am looking for - for TDS Remote Procedure Call i see a time of 8.515376 ---- and Response of 8.516955 .....there are several other entries but using TDS because that is what shows SQL is being utilized right? which would mean app is communicating with the DB at that point....what does that time mean to you?

hisrafi ( 2020-04-16 13:33:22 +0000 )edit

Wireshark can display the timers of packets in several different ways, but I suspect that you're using the "default" which is to show the time in seconds since the start of the capture. In this case the difference ins ~ 1.5 mS which seems quite insignificant.

Anyway, now that Wireshark is interpreting the packets correctly it shouldn't display any more errors for the TDS traffic, and this would NOT have affected the app and server as the "know" what version they are using.

To debug your application issues you are going to have to look server and application debug logs to find out what they are up to. Understanding what TDS traffic looks like (which is helped by looking at it with Wireshark) may also help, but there's quite a learning curve, and again Wireshark shows you WHAT, not WHY.

grahamb ( 2020-04-16 15:00:01 +0000 )edit

Some great info! Thanks a lot guys!!

hisrafi ( 2020-04-16 15:58:37 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Malformed Packets-App to MS SQL DB server

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Malformed Packets-App to MS SQL DB server edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Malformed Packets-App to MS SQL DB server