Wireshark-users: [Wireshark-users] CoAP dissector mixed-up about Accept and Content-Format?
From: Stuart Longland <stuartl@xxxxxxxxxxxxxxxxxx>
Date: Wed, 13 Nov 2019 10:51:48 +1000
Hi all,

Can someone explain what's going on here?  I have a CoAP response packet
that Wireshark is telling me is malformed.

> 0000   60 00 00 00 00 36 11 ff fd 34 fe 56 78 91 00 10   `....6.ÿý4þVx...
> 0010   54 62 5b 54 a7 d8 75 6f fd 9e e3 08 e1 4c b8 77   Tb[T§Øuoý.ã.áL¸w
> 0020   00 00 00 00 00 00 00 fd 16 33 f0 b0 00 36 33 73   .......ý.3ð°.63s
> 0030   48 02 b7 ea 88 e9 f5 60 ba 20 7c c9 18 35 3a 6e   H.·ê.éõ`º |É.5:n
> 0040   7a 71 74 57 67 a1 63 10 3a 74 3d 6b 58 2d 78 4f   zqtWg¡c.:t=kX-xO
> 0050   56 6f 69 21 3c ff 74 73 2e 63 2e 63 31 30         Voi!<ÿts.c.c10

That's the hex dump, attached is the pcap dump of it.
The full summary is here:
> No.     Time           Source                Destination           Protocol Length Info                                                            Payload    Comment
>   25316 2250.908148    fd34:fe56:7891:10:5462:5b54:a7d8:756f fd9e:e308:e14c:b877::fd CoAP     94     CON, MID:47082, POST, TKN:88 e9 f5 60 ba 20 7c c9, /c?t=kX-xOVoi[Malformed Packet]            
> 
> Frame 25316: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
>     Encapsulation type: Raw IP (7)
>     Arrival Time: Nov 13, 2019 10:36:32.155124000 AEST
>     [Time shift for this packet: 0.000000000 seconds]
>     Epoch Time: 1573605392.155124000 seconds
>     [Time delta from previous captured frame: 0.156517000 seconds]
>     [Time delta from previous displayed frame: 0.156517000 seconds]
>     [Time since reference or first frame: 2250.908148000 seconds]
>     Frame Number: 25316
>     Frame Length: 94 bytes (752 bits)
>     Capture Length: 94 bytes (752 bits)
>     [Frame is marked: True]
>     [Frame is ignored: False]
>     [Protocols in frame: raw:ipv6:udp:coap:cbor]
>     [Coloring Rule Name: UDP]
>     [Coloring Rule String: udp]
> Raw packet data
> Internet Protocol Version 6, Src: fd34:fe56:7891:10:5462:5b54:a7d8:756f, Dst: fd9e:e308:e14c:b877::fd
>     0110 .... = Version: 6
>     .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)                                                                                                   
>         .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)                                                                                              
>         .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)                                                                             
>     .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000                                                                                                                             
>     Payload Length: 54                                                                                                                                                                        
>     Next Header: UDP (17)                                                                                                                                                                     
>     Hop Limit: 255                                                                                                                                                                            
>     Source: fd34:fe56:7891:10:5462:5b54:a7d8:756f                                                                                                                                             
>     Destination: fd9e:e308:e14c:b877::fd                                                                                                                                                      
> User Datagram Protocol, Src Port: 5683, Dst Port: 61616
>     Source Port: 5683
>     Destination Port: 61616
>     Length: 54
>     Checksum: 0x3373 [unverified]
>     [Checksum Status: Unverified]
>     [Stream index: 0]
> Constrained Application Protocol, Confirmable, POST, MID:47082
>     01.. .... = Version: 1
>     ..00 .... = Type: Confirmable (0)
>     .... 1000 = Token Length: 8
>     Code: POST (2)
>     Message ID: 47082
>     Token: 88e9f560ba207cc9
>     Opt Name: #1: If-Match: 35 3a 6e 7a 71 74 57 67
>         Opt Desc: Type 1, Critical, Safe
>         0001 .... = Opt Delta: 1
>         .... 1000 = Opt Length: 8
>         If-Match: 353a6e7a71745767
>     Opt Name: #2: Uri-Path: c
>         Opt Desc: Type 11, Critical, Unsafe
>         1010 .... = Opt Delta: 10
>         .... 0001 = Opt Length: 1
>         Uri-Path: c
>     Opt Name: #3: Content-Format: text/plain; charset=utf-8
>         Opt Desc: Type 12, Elective, Safe
>         0001 .... = Opt Delta: 1
>         .... 0000 = Opt Length: 0
>         Content-type: text/plain; charset=utf-8
>     Opt Name: #4: Uri-Query: t=kX-xOVoi
>         Opt Desc: Type 15, Critical, Unsafe
>         0011 .... = Opt Delta: 3
>         .... 1010 = Opt Length: 10
>         Uri-Query: t=kX-xOVoi
>     Opt Name: #5: Accept: application/cbor
>         Opt Desc: Type 17, Critical, Safe
>         0010 .... = Opt Delta: 2
>         .... 0001 = Opt Length: 1
>         Accept: application/cbor
>     End of options marker: 255
>     [Response In: 25319]
>     [Uri-Path: /c]
>     Payload: Payload Content-Format: application/cbor, Length: 8
>         Payload Desc: application/cbor
>         [Payload Length: 8]
> Concise Binary Object Representation
> [Malformed Packet: CBOR]
>     [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
>         [Malformed Packet (Exception occurred)]
>         [Severity level: Error]
>         [Group: Malformed]

It clearly knows its text/plain, specifically it's a JMESPath query.
The CoAP client in this case is requesting a JMESPath query be performed
on a JSON document stored server side, and that the server return the
response back to it in CBOR format (hence "Accept: application/cbor").

That does not mean there is any CBOR contained anywhere in that packet.
 Why does WireShark try to interpret it as such?
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Attachment: coap-badpacket.pcap
Description: application/vnd.tcpdump.pcap