iSerial access gets Malformed Packet

For more advanced meter data users. Learn from others and ask questions about how to read meters, how to use the EKM Push Data, and how to display the meter data in useful ways.
Post Reply
dandelot
Posts: 17
Joined: Fri Sep 05, 2014 7:07 pm

iSerial access gets Malformed Packet

Post by dandelot » Sat Jan 10, 2015 3:08 pm

I was watching packets on my home network
and noticed something odd sent from
ekm iSerial v.4.

I am getting good values, so the oddity
seems harmless. I just thought I would mention
it here in case someone has a suggestion as to
what the oddity might mean.

I've done this with my own software (in C)
and EKM Dash and both resulted in the
Malformed Packet seen here.
Dash and I send the same request packet.

So, we send out a request. Get an ACK. Then
a PSH,ACK which is a Malformed Packet?
Why? What?

Thanks in advance for any hints.
DavidA
--------what follows are the details, picked up by
wireshark watching the in-house network. I did disguise
the interal IP addresses slightly.

Here is the request.
No. Time Source Destination Protocol Length Info
448 936.745571000 192.168.1.2 192.168.1.6 TCP 73 39083 > 50000 [PSH, ACK] Seq=1 Ack=1 Win=29200 Len=19

Frame 448: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) on interface 0
Ethernet II, Src: AsustekC_26:5c:53 (00:23:54:26:5c:53), Dst: Cimsys_39:4d:33 (00:11:22:39:4d:33)
Internet Protocol Version 4, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.6 (192.168.1.6)
Transmission Control Protocol, Src Port: 39083 (39083), Dst Port: 50000 (50000), Seq: 1, Ack: 1, Len: 19
Data (19 bytes)

0000 2f 3f 30 30 30 33 30 30 30 30 31 32 33 37 30 30 /?00030000123700
0010 21 0d 0a !..

Here is the ACK
No. Time Source Destination Protocol Length Info
449 936.752357000 192.168.1.6 192.168.1.2 TCP 60 50000 > 39083 [ACK] Seq=1 Ack=20 Win=1400 Len=0

Frame 449: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Cimsys_39:4d:33 (00:11:22:39:4d:33), Dst: AsustekC_26:5c:53 (00:23:54:26:5c:53)
Internet Protocol Version 4, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 50000 (50000), Dst Port: 39083 (39083), Seq: 1, Ack: 20, Len: 0

And here is the surprising PSH,ACK that is noted as MalFormed.
No. Time Source Destination Protocol Length Info
450 936.790865000 192.168.1.6 192.168.1.2 TCP 60 50000 > 39083 [PSH, ACK] Seq=1 Ack=20 Win=1400 Len=1[Malformed Packet]

Frame 450: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Cimsys_39:4d:33 (00:11:22:39:4d:33), Dst: AsustekC_26:5c:53 (00:23:54:26:5c:53)
Internet Protocol Version 4, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 50000 (50000), Dst Port: 39083 (39083), Seq: 1, Ack: 20, Len: 1
[Malformed Packet: FMTP]

----------end

Jameson
Posts: 770
Joined: Fri Nov 04, 2011 7:42 pm
Location: Santa Cruz, CA
Contact:

Re: iSerial access gets Malformed Packet

Post by Jameson » Thu Jan 15, 2015 10:18 am

Im going to have to phone a friend for this one. I cant begin to guess what that means. :?
Jameson
EKM METERING
http://www.ekmmetering.com
831.425.7371

JayDee
Posts: 20
Joined: Mon Aug 11, 2014 4:24 pm

Re: iSerial access gets Malformed Packet

Post by JayDee » Thu Jan 15, 2015 2:28 pm

Dandelot.

Here is one explanation

"Wireshark thinks the packet is malformed. This could be because it really is malformed. A few possible reasons might be because the snaplen causes the packet to be truncated during capturing, or the packet could have been malformed originally by the sender. The packet could have become corrupted in transit or intentionally by a fuzz-tester, for example. On the other hand, the packet could be just fine and it's incorrectly being reported as malformed due to a bug in the Wireshark TDS dissector."

More can be found here

https://ask.wireshark.org/questions/347 ... med-packet

dandelot
Posts: 17
Joined: Fri Sep 05, 2014 7:07 pm

Re: iSerial access gets Malformed Packet

Post by dandelot » Sun Jan 18, 2015 2:27 pm

Very helpful link, JayDee. Thanks. It will be a few days (at least)
before I can look at this further. But you provided important
hints. Thanks again.

Post Reply