Announcement

**John Petty** · 24 Oct 2008, 02:10 PM

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.

**Dan Gin zel** · 24 Oct 2008, 03:49 PM

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.

**Dan Gin zel** · 24 Oct 2008, 04:10 PM

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

**Dan Gin zel** · 24 Oct 2008, 06:42 PM

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??

**Brian Chirgwin** · 24 Oct 2008, 08:54 PM

Originally posted by Dan Gin zel View Post

Any thoughts on the checksum??

User Datagram Protocol - Wikipedia

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.

**Dan Gin zel** · 24 Oct 2008, 09:20 PM

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

**Eros Olmi** · 25 Oct 2008, 01:48 AM

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

**Scott Turchin** · 25 Oct 2008, 11:11 AM

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

I'd be cautious putting too much emphasis on that...

**Marco Pontello** · 25 Oct 2008, 11:49 AM

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!

Announcement

UDP Send CheckSum error (according to WireShark)

UDP Send CheckSum error (according to WireShark)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment