Ask Your Question
0

Malformed Packets-App to MS SQL DB server

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

hisrafi gravatar image

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

Guy Harris gravatar image

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,

H

edit retag flag offensive close merge delete

Comments

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

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

DB is on VMWare- WS 2016-

App server is using SQL to communicate with DB.

hisrafi gravatar imagehisrafi ( 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 gravatar imagegrahamb ( 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 gravatar imagehisrafi ( 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 gravatar imageChuckc ( 2020-04-16 02:58:54 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-04-16 03:12:14 +0000

Chuckc gravatar image

updated 2020-04-16 03:12:39 +0000

Bug 7622 - [Malformed Packet: TDS] DONE token breakout has wrong length
The TDS dissector needs to know what version it is working with.
Right click the Tabular Data Stream line in the packet details.
Select Protocol Preferences -> TDS Protocol Type and the proper version.
For the sample capture I changed it from Not Specified to TDS 7.1 but seems anything lower than that down to TDS 4.x got rid of the error.

edit flag offensive delete link more

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 gravatar imagehisrafi ( 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 gravatar imagegrahamb ( 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 gravatar imagehisrafi ( 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 gravatar imagegrahamb ( 2020-04-16 15:00:01 +0000 )edit

Some great info! Thanks a lot guys!!

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

Your Answer

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

Add Answer

Question Tools

1 follower

Stats

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

Seen: 9,397 times

Last updated: Apr 16 '20