Announcement

Collapse
No announcement yet.

UDP Send CheckSum error (according to WireShark)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • UDP Send CheckSum error (according to WireShark)

    Greetings.

    I've been beating my head against the wall trying to get UDP working with an unproven prototype hardware device. I've been using WireShark to monitor communications and it seems to be quite helpful.

    One thing is that the packets that I'm sending contain a CheckSum error. Here's the complete text of the packet:
    Code:
    No.     Time        Source                Destination           Protocol Info
        188 1812.943226 192.168.10.3          192.168.255.255       UDP      Source port: 52306  Destination port: 50501 [UDP CHECKSUM INCORRECT]
    
    Frame 188 (58 bytes on wire, 58 bytes captured)
        Arrival Time: Oct 23, 2008 16:26:32.067104000
        [Time delta from previous captured frame: 0.320303000 seconds]
        [Time delta from previous displayed frame: 0.320303000 seconds]
        [Time since reference or first frame: 1812.943226000 seconds]
        Frame Number: 188
        Frame Length: 58 bytes
        Capture Length: 58 bytes
        [Frame is marked: False]
        [Protocols in frame: eth:ip:udp:data]
    Ethernet II, Src: QuantaCo_e8:b0:82 (00:1b:24:e8:b0:82), Dst: Cisco-Li_89:74:7e (00:0c:41:89:74:7e)
        Destination: Cisco-Li_89:74:7e (00:0c:41:89:74:7e)
            Address: Cisco-Li_89:74:7e (00:0c:41:89:74:7e)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Source: QuantaCo_e8:b0:82 (00:1b:24:e8:b0:82)
            Address: QuantaCo_e8:b0:82 (00:1b:24:e8:b0:82)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Type: IP (0x0800)
    Internet Protocol, Src: 192.168.10.3 (192.168.10.3), Dst: 192.168.255.255 (192.168.255.255)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 44
        Identification: 0x57b9 (22457)
        Flags: 0x00
            0... = Reserved bit: Not set
            .0.. = Don't fragment: Not set
            ..0. = More fragments: Not set
        Fragment offset: 0
        Time to live: 128
        Protocol: UDP (0x11)
        Header checksum: 0x0000 [incorrect, should be 0x57b4]
            [Good: False]
            [Bad : True]
        Source: 192.168.10.3 (192.168.10.3)
        Destination: 192.168.255.255 (192.168.255.255)
    User Datagram Protocol, Src Port: 52306 (52306), Dst Port: 50501 (50501)
        Source port: 52306 (52306)
        Destination port: 50501 (50501)
        Length: 24
        Checksum: 0x8b7d [incorrect, should be 0xe0d1 (maybe caused by "UDP checksum offload"?)]
            [Good Checksum: False]
            [Bad Checksum: True]
    Data (16 bytes)
        Data: 01FFFFFFFFFFFFFFFFFFFFFFFF0100FF
    
    0000  00 0c 41 89 74 7e 00 1b 24 e8 b0 82 08 00 45 00   ..A.t~..$.....E.
    0010  00 2c 57 b9 00 00 80 11 00 00 c0 a8 0a 03 c0 a8   .,W.............
    0020  ff ff cc 52 c5 45 00 18 8b 7d 01 ff ff ff ff ff   ...R.E...}......
    0030  ff ff ff ff ff ff ff 01 00 ff                     ..........
    The Data string is correct. The rest, well, I don't know about calculating the check sum.

    Here's the snippet that generated that packet:
    Code:
    t = Chr$(&H01) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&H01) + Chr$(&H00) + Chr$(&HFF)
    UDP OPEN AS 105
    HOST ADDR "192.168.255.255" TO i
    UDP SEND 105, AT i, 50501, t
    UDP CLOSE 105
    I'm wondering if the device that I'm trying to communicate with is seeing the checksum error and causing an issue.

    Any thoughts would be greatly appreciated.

    Dan
    Last edited by Dan Gin zel; 23 Oct 2008, 06:03 PM.
    www.thecomputerarchive.com Preserving the history of companies that advanced the computer revolution

  • #2
    As I understand it the checksums are created by winsock.
    Your destination address is rather strange. 192.168.10.xxx is a C class address so its broadcast address would be 192.168.10.255 or if you are trying to contact anything on a LAN 255.255.255.255 Not sure where 192.168.255.255 address would go to, should be looking for a default gateway but the packets are not showing it.

    Comment


    • #3
      Thank you for your reply, John.

      I have tried sending the message to the known IP address of the device, 192.168.10.2 and the result is the same with the checksum error.

      I'm fixin' to post the source of a small test program that I working with. I tried to 'press on through' but discovered that I cannot receive packets, either.
      www.thecomputerarchive.com Preserving the history of companies that advanced the computer revolution

      Comment


      • #4
        I created the follow program-ette to demonstrate my problem. (Okay, I stand corrected: my UDP problem.)

        Here are my devices:
        192.168.10.4 = Programming computer, Vista, firewall disabled
        192.168.10.3 = Second computer, XP, firewall disabled
        192.168.10.2 = Hardware device

        In a nutshell, I have a hardware device transmitting UDP packets from 50501 to 50500. WireShark sees these packets on two computers on the same router.

        At the same time, I'm trying to transmit UDP packets from my programming computer to port 50501. WireShark sees these packets on sending computer flagged with the [UDP CHECKSUM INCORRECT] error. However, the other computer on the network doesn't see the packets at all unless I send them direct to it.

        I cannot change the base port of 50500 at this time. However, I've used a NirSoft program to see what ports I've got open. 50500 is only open when I've got it open.

        So, here's the source. You'll see some of my 'test' stuff in it. There's probably something super simple that I'm missing that I hope someone out there can help me identify.

        Thanks for assistance y'all can provide.
        Dan


        Code:
             #COMPILE EXE
        
             #Include "c:\progutil\pbwin80\winapi\win32api.inc"
        
             Declare Function IPtoString (IPLong as Long) as String
             Declare Function Dialog_Main as Long
             Declare Callback Function Events_Main as Long
        
             Function IPtoString (IPLong as Long) as String
                  Local k as Byte Ptr
                  k = VarPtr(IPLong)
                  Function = USING$("#_.#_.#_.#", @k, @k[1], @k[2], @k[3])
             End Function
        
             Global hMain as Long
        
             Global UDP_Handle        as Long        ' UDP (File) Handle
             Global UDP_Message       as Long        ' CBCtl were messages are to be delivered
             Global UDP_MonitorPort   as Long        ' Port to monitor (also known as the From Port)
        
             Global UDP_SendToIP      as Long        ' Destination IP Address
             Global UDP_SendToPort    as Long        ' To Port
             Global UDP_SendString    as String      ' Message to send
        
             Global UDP_RecFromIP     as Long        ' Receieved from IP Address
             Global UDP_RecFromPort   as Long        ' Receieved from Port Number
             Global UDP_RecString     as String      ' Receieved message
        
        
             Function WinMain (ByVal hinstance as Long, ByVal hPrevInstance as Long, ByVal lpCmdLine as ASCIIZ Ptr, ByVal iCmdShow as Long) as Long
                  UDP_Handle      = FreeFile
                  UDP_Message     =  1000
                  UDP_MonitorPort = 50500
        
                  UDP_SendToPort  = 50501
                  UDP_SendString  = Chr$(&H01) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&HFF) + Chr$(&H01) + Chr$(&H00) + Chr$(&HFF)
        
                  Dialog_Main
             End Function
        
        
             Function Dialog_Main as Long
                  DIALOG NEW 0, "UDP Tester", , , 420, 130, %DS_MODALFRAME or %DS_NOFAILCREATE or %WS_BORDER or %WS_CLIPSIBLINGS or %WS_DLGFRAME or %WS_SYSMENU, to hMain
        
                  Control Add Label,  hMain, 100, "Monitoring Port:", 10, 10, 90, 20
                  Control Add Label,  hMain, 101, Str$(UDP_MonitorPort), 100, 10, 310, 20
        
                  Control Add Label,  hMain, 110, "Last msg from IP and Port:", 10, 30, 90, 20
                  Control Add Label,  hMain, 111, "(No Packet Received)", 100, 30, 310, 20
        
                  Control Add Label,  hMain, 130, "Last msg string:", 10, 50, 90, 20
                  Control Add Label,  hMain, 131, "(No Packet Received)", 100, 50, 310, 20
        
        
                  Control Add Label,  hMain, 200, "Transmitting on IP and Port:", 10, 80, 90, 20
                  Control Add Label,  hMain, 201, "Multiple on port" + Str$(UDP_SendToPort), 100, 80, 310, 20
        
        
                  Control Add Button, hMain, 299, "Transmit Packet", 100, 110, 100, 15
        
                  Control Add Button, hMain, 999, "Close", 310, 110, 100, 15
        
                  DIALOG SHOW MODAL hMain, Call Events_Main
             End Function
        
        
             Callback Function Events_Main as Long
                  If CBCtl = 1000 Then MsgBox "I see CBCtl = 1000 !"
        
                  Select Case CBMsg
                       Case %WM_InitDialog
                            UDP_Handle = FreeFile
                            UDP Open Port UDP_MonitorPort as UDP_Handle
                            UDP Notify UDP_Handle, SEND RECV CLOSE to hMain as 1000 ' UDP_Message
        
                       Case %WM_Close, %WM_QueryEndSession, %WM_Quit
                            UDP Close UDP_Handle
        
                       Case %WM_Command
                            Select Case CBCtl
                                 Case 1000 ' UDP_Message
         '                             Select Case LO(Word, CbLParam)
         '                                  Case %FD_Read
                                                UDP RECV UDP_Handle, FROM UDP_RecFromIP, UDP_RecFromPort, UDP_RecString
                                                Control Set Text hMain, 111, IPtoString(UDP_RecFromIP) + " port" + Str$(UDP_RecFromPort)
                                                Control Set Text hMain, 131, UDP_RecString
         '                             End Select
        
                                 Case 299 ' Transmit Packet
                                      Select Case CBCtlMsg
                                           Case %BN_Clicked
                                                ' I'm sending multiple just trying to get ANYTHING out
                                                HOST ADDR "192.168.10.2" TO UDP_SendToIP
                                                UDP Send UDP_Handle, AT UDP_SendToIP, UDP_SendToPort, UDP_SendString + "...10.2"
        
                                                HOST ADDR "192.168.10.3" TO UDP_SendToIP
                                                UDP Send UDP_Handle, AT UDP_SendToIP, UDP_SendToPort, UDP_SendString + "...10.3"
        
                                                HOST ADDR "192.168.10.255" TO UDP_SendToIP
                                                UDP Send UDP_Handle, AT UDP_SendToIP, UDP_SendToPort, UDP_SendString + "...10.255"
        
                                                HOST ADDR "192.168.255.255" TO UDP_SendToIP
                                                UDP Send UDP_Handle, AT UDP_SendToIP, UDP_SendToPort, UDP_SendString + "...255.255"
                                      End Select
        
                                 Case 999 ' Close Button
                                      Select Case CBCtlMsg
                                           Case %BN_Clicked
                                                UDP Close UDP_Handle
                                                Dialog End hMain
                                      End Select
                            End Select
                  End Select
             End Function
        www.thecomputerarchive.com Preserving the history of companies that advanced the computer revolution

        Comment


        • #5
          Okay, I've learned something.

          I changed the UDP open to include a timeout of 1 ms.
          Code:
          UDP Open Port UDP_MonitorPort as UDP_Handle Timeout 1
          UDP Notify UDP_Handle, RECV SEND CLOSE to hMain as %WM_USER + 1500
          Then in the Callback function, I threw in a bit of test code to just grab the data and write it to a text file:
          Code:
          UDP RECV UDP_Handle, FROM UDP_RecFromIP, UDP_RecFromPort, UDP_RecString
          Print #99, Str$(timer) + "," + STr$(CBCtl) + "," + str$(CBCtlMsg) + "," + str$(LO(Word, CbLParam)) + "," + IPtoString(UDP_RecFromIP) + " port" + Str$(UDP_RecFromPort) + "," + UDP_RecString
          I saw the packet come in via WireShark and checked the log and found this waiting for me:
          Code:
           66598.123, 144, 0, 1,192.168.10.2 port 50501,ST=Ready
          If I'm not mistaken, it came in as CBCtl = 144 (decimal) and CBCtlMsg = 0, and 144 is a far cry from %WM_User + 1500 which equates to 2524 (decimal).

          So, it appears that the notification works. I'm just not looking where I'm supposed to.



          Ding. Ding. Ding. As I was typing this out, I found the problem!!!
          Code:
                    Select Case CBMsg
                         Case %WM_User + 1500
          I was thinking it posting the message as a control message but I was mistaken.

          ....Now I've just got to get past the invalid checksum because I have confirmed that the hardware device IS checking the checksum and throwing out the packet.

          Any thoughts on the checksum??
          www.thecomputerarchive.com Preserving the history of companies that advanced the computer revolution

          Comment


          • #6
            Originally posted by Dan Gin zel View Post
            Any thoughts on the checksum??
            http://en.wikipedia.org/wiki/User_Datagram_Protocol

            I checked your output and the checksum was 0x0000 which is "valid" as in IPV4 checksum as it is optional to calculate it. In IPV6 checksum is required.

            I am not sure how you can set the system to calculate this under ipv4. I guess you could switch to ipv6, if all your devices support it.

            Maybe you can set the device your trying to connect to to ignore checksum?

            The only thing I found searching is to check your network card configuration. If checksum offload is set, disable it. It is possible that the card doesn't perform the calculation at leaves it at 0.

            Comment


            • #7
              I've tried four computers and they all produce the same result, no checksum. Thankfully, the device I am communicating with is a prototype, so there is hope that I can get a firmware change. Now that the UDP working, I've identified several other items that need attention. I'm sure it's just a checksum-required flag in the Ethernet communications chip.

              Thank you for looking that information up, Brian. I'll be studying that area quite a bit this weekend.

              Dan
              www.thecomputerarchive.com Preserving the history of companies that advanced the computer revolution

              Comment


              • #8
                To test my UDP applications I've found this tool very useful:
                http://www.colasoft.com/packet_build....php?click=box

                It lets you build TCP or UDP packets graphically in an easy and intuitive way. Than you can send them over the net.

                Regards
                Eros
                thinBasic programming language
                Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                Comment


                • #9
                  Wireshark seems to tell me every application's TCP is also a checksum error.

                  I'd be cautious putting too much emphasis on that...
                  Scott Turchin
                  MCSE, MCP+I
                  http://www.tngbbs.com
                  ----------------------
                  True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi

                  Comment


                  • #10
                    Check this: The Wireshark Wiki
                    TCP checksum offload

                    Sometimes outgoing TCP packets appear black with red Text and the TCP Checksum is marked as incorrect with the note [incorrect, should be xxxx (maybe caused by "TCP checksum offload"?)].

                    This is the case when your network adapter has the option called (TCP) Checksum Offload or similar, like newer Gigabit ethernet cards. When this option is enabled, the network adapter will calculate the checksum by itself, making the CPU not have to do this work. As Wireshark captures the packets before they get to the network adapter it won't see the correct checksum because it has not been calculated yet.

                    You can disable the option "Check the validity of the TCP checksum when possible" in the TCP dissector preferences if desired, so Wireshark won't check that any more.

                    If you are experiencing network problems and while trying to figure it out with Wireshark you found these checksum errors, you may have a network card with TCP checksum offload enabled and for some reason the packet is not being fixed by the adapter (NAT, bridge or route redirection is sending the packet to another interface). In this case, you may want to check and disable checksum offload for the adapter, if possible.

                    [...]
                    The same apply for UDP too.
                    Off course, if you sniff "on the wire", instead of "on the host" (i.e. in the same machine that's producing the packets), there will no be checksum problem, since the device will have already taken care of that at that point.

                    Bye!
                    Last edited by Marco Pontello; 25 Oct 2008, 11:53 AM.
                    -- The universe tends toward maximum irony. Don't push it.

                    File Extension Seeker - Metasearch engine for file extensions / file types
                    Online TrID file identifier | TrIDLib - Identify thousands of file formats

                    Comment

                    Working...
                    X