# TCPSocket MacOS vs Windows **URL:** \ **Category:** General Programming\ **Created:** [30 July 2020 17:01 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798 "2020-07-30T17:01:54Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [30 July 2020 17:01 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/1 "2020-07-30T17:01:54Z")
I have a cross-platform app I wrote in Xojo. Uses TCPSockets. Works fine in MacOS, but chokes on Windows. It’s receiving a data via TCPSocket, and all is well until a large packet arrives. (1460 bytes). The TCPSocket in MacOS receives it properly, but in Windows, it receives only 1308 bytes. Using Wireshark I can see the difference and an indication of the error in Windows, but I’m no networking expert and can barely figure out Wireshark. My questions: Does maybe the Windows TCPSocket have a smaller buffer or something? Is there something different I have to do on Windows with TCPSockets for large packets? Hopefully someone has run into this and can offer some suggestions. Thanks! ![TCPSocket Error (WS)](https://ifnotnil.com/uploads/default/original/1X/fafe65de39c75610e5b5e8219c0acbe65db3a08f.jpeg) ![TCPSocket Error (WS) - MacOS](https://ifnotnil.com/uploads/default/original/1X/68ac944eefbab6c8141bf7600e52946cd4010ac0.png) ---
**Author:** ![mikecotrone](https://ifnotnil.com/user_avatar/ifnotnil.com/mikecotrone/32/524_2.png) [@mikecotrone](https://ifnotnil.com/u/mikecotrone)\ **Post date:** [30 July 2020 17:20 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/2 "2020-07-30T17:20:00Z")
Can you paste versions with the IP Header expanded please? I am wondering if the DF bit is set on your windows trace. What version of Windows are you using? Are these traces both from your same location - is this location home or corporate network? Thanks ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [30 July 2020 17:24 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/3 "2020-07-30T17:24:19Z")
> [@Meestor\_X](#): > > It’s receiving a data via TCPSocket, and all is well until a large packet arrives. (1460 bytes). The TCPSocket in MacOS receives it properly, but in Windows, it receives only 1308 bytes. never never never assume that a “packet” sent will be received as one unit this is almost NEVER true and assuming it will cause issues ---
**Author:** ![mikecotrone](https://ifnotnil.com/user_avatar/ifnotnil.com/mikecotrone/32/524_2.png) [@mikecotrone](https://ifnotnil.com/u/mikecotrone)\ **Post date:** [30 July 2020 17:24 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/4 "2020-07-30T17:24:47Z")
Chunks baby - chunks 🙂 ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [30 July 2020 17:40 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/5 "2020-07-30T17:40:12Z")
Ok, this is weird. On a separate Windows install on the same computer, it seems to be working. Something funky, I’d love to know what in case I have users finding the same problem. Windows 7 x64, and MacOS Mojave, same network home network (wired), speaking to the same device. I’ll post some more screenshots once I fully test this seemingly working copy. ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [30 July 2020 17:47 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/6 "2020-07-30T17:47:52Z")
different network adapter different buffer sizes etc etc etc and, you can get seemingly random results IF you assume that what got sent from one end arrives at the other in ONE data available event mostly it wont ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [30 July 2020 18:04 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/7 "2020-07-30T18:04:06Z")
Figured it out. 2 different versions of network drivers. The one that didn’t work had Jumbo Frames enabled. I would have to guess that the hardware device doesn’t support Jumbo Frames. Oddly, they are both the same version, but one has more settings than the other. Friggin Windows!! Bad Driver: ![Bad Network Driver](https://ifnotnil.com/uploads/default/original/1X/58dcd7097c410b88f8dee8cbd249e011b9f648cf.jpeg) Good Driver: ![Good Network Driver](https://ifnotnil.com/uploads/default/original/1X/75204c43433a229d0fe82a16f282de11a562c59d.png) Disabling Jumbo Frames fixed the problem. WHEW!! ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [30 July 2020 18:16 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/8 "2020-07-30T18:16:11Z")
That might fix THIS problem but if / when the data you send get larger you’ll have the problem again Data available makes NO guarantee all data arrive in one event Neither does TCP So heads up ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [30 July 2020 18:25 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/9 "2020-07-30T18:25:49Z")
No worries, Norm. I wrote into the handler how to deal with partial messages. Is there a way to detect whether or not jumbo packets are enabled? Since it produces no error, (the device just quits sending), it would be great if I can check that setting on a users computer… ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [30 July 2020 18:41 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/10 "2020-07-30T18:41:41Z")
I dont know of a way to detect it Possibly a registry setting ? I’ve seen mention of those but that might be specific to whatever adapter is in use Maybe netsh from the cmd line can tell ? On newer Windows you probably need to use PowerShell > **[NetTCPIP](https://docs.microsoft.com/en-us/powershell/module/nettcpip/?view=win10-ps)** > > Use this topic to help manage Windows and Windows Server technologies with Windows PowerShell. Get-NetIPInterface more than likely (or something in that vein) ---
**Author:** ![mikecotrone](https://ifnotnil.com/user_avatar/ifnotnil.com/mikecotrone/32/524_2.png) [@mikecotrone](https://ifnotnil.com/u/mikecotrone)\ **Post date:** [30 July 2020 20:46 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/11 "2020-07-30T20:46:06Z")
Disabling Jumbo frames is not a good solution - yes it works, but it will break again soon with someone else’s windows box. Thats where I was heading with your traces seeing if your DF (Dont fragment) bit was set in Windows – Windows used to have bad bad issues trying to detect a path MTU (PTMUD) which always set the DF bit to True on PMTUD failure causing larger frames to be discarded when they needed to be fragmented at the next hop layer 3 boundary. You just need to query the MTU of the Windows Driver Interface to detect Jumbo or not. Anything \> 1500 is Jumbo (Usually its 9000 mtu for Jumbo) **Here are the easy steps I took to do it in Windows 10 .** 1. Open a command prompt as administrator. ( … 2. type the command : netsh interface ipv4 show subinterfaces. 3. This should output your interfaces and current **MTU** size. ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [30 July 2020 20:57 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/12 "2020-07-30T20:57:00Z")
Thank you, Mike for that information! Since users will be using this software on unknown machines, it would be great to see if there’s a way to head off potential problems. Really appreciate your help. Here is the Wireshark capture, if you can make heads or tails of it! [Wireshark Capture](https://www.dropbox.com/s/s0plgrbu5fx3fwt/JumboFrame%20Error%20-%20Windows.zip?dl=1) Ultimately, if it turns out that the hardware device does not support Jumbo Frames, it would be great if I could detect whether the user’s computer had them enabled and give a warning. This would need to work cross-platform, Win/Mac/Linux of course… 😉 ---
**Author:** ![mikecotrone](https://ifnotnil.com/user_avatar/ifnotnil.com/mikecotrone/32/524_2.png) [@mikecotrone](https://ifnotnil.com/u/mikecotrone)\ **Post date:** [31 July 2020 03:25 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/13 "2020-07-31T03:25:09Z")
That makes sense – Your IP header DF bit is set to “don’t fragment” (Flags 0x4000) so any frame coming in with link layer / upper layer headers over 1500 will drop at the NIC. I think the thing to do like Norman said above is to try to detect if yoru Windows NIC has an MTU capable of 9000 MTU (jumbo frames) or not (1500 MTU). If not then you know what you can do already its seems in code. Im not a super windows dude anymore so ill end this post but look to see if there is a way with netsh to query your NIC to see if you NIC can do above 1500 or not. (light reading on it: [https://en.wikipedia.org/wiki/Path\_MTU\_Discovery](https://en.wikipedia.org/wiki/Path_MTU_Discovery)) Ok Two Ideas: 1. This link shows how to use netsh to get the existing MTU of the NIC [https://cpsdocs.dellemc.com/bundle/VXF\_CONF\_CUST/page/GUID-237194FA-AB9B-4594-80FA-D10EEA40DF87.html](https://cpsdocs.dellemc.com/bundle/VXF_CONF_CUST/page/GUID-237194FA-AB9B-4594-80FA-D10EEA40DF87.html) 2. You could also do a (OS X: ping -s 2000 127.0.0.1 [IP of said NIC] ) or (Win: ping -l 2000 127.0.0.1 [IP of said NIC]) to see if you get a valid response. Valid = Jumbo is enabled and Not = 1500 MTU. I am still trying to see if there is a command to query Jumbo frame support boolean for a NIC. In my experience Windows is notorious at sucking with MTU discovery. ---
**Author:** ![mikecotrone](https://ifnotnil.com/user_avatar/ifnotnil.com/mikecotrone/32/524_2.png) [@mikecotrone](https://ifnotnil.com/u/mikecotrone)\ **Post date:** [31 July 2020 03:35 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/14 "2020-07-31T03:35:17Z")
Ok Try this (I dont have my windows box handy). > **[Get-NetAdapterAdvancedProperty (netadapter)](https://docs.microsoft.com/en-us/powershell/module/netadapter/get-netadapteradvancedproperty?view=win10-ps)** > > The Get-NetAdapterAdvancedProperty cmdlet gets the advanced properties for a network adapter. By default this cmdlet returns advanced properties that have display name values, meaning that these advanced properties are visible in the Advanced pane of... Apparently this command result is supposed to have the NICs capabilities. I am hoping jumbo frame support is one of them. 1. Power shell command to query jumbo frame capability: Get-NetAdapterAdvancedProperty -Name 2. Power shell command #2 (untested) Set-NetAdapterAdvancedProperty -Name “ISCSI” -RegistryKeyword “\*JumboPacket” Good luck and let us know how you end up on this. - Mike ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [31 July 2020 06:48 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/15 "2020-07-31T06:48:27Z")
Thanks, Mike. Just in case it’s not clear, the issue is not with the computer’s NIC, but with the hardware’s NIC, where it doesn’t seem to support Jumbo Frames. All I’m looking for is a simple test to see whether or not the person’s computer’s NIC is set up with Jumbo Frames, and to give a warning if it is, as the program will fail. The ping command will always fail with anything \> 1500 because the Hardware device doesn’t support it. Whether the NIC in the computer supports it is not the issue, just whether it has them enabled. ---
**Author:** ![mikecotrone](https://ifnotnil.com/user_avatar/ifnotnil.com/mikecotrone/32/524_2.png) [@mikecotrone](https://ifnotnil.com/u/mikecotrone)\ **Post date:** [31 July 2020 17:06 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/16 "2020-07-31T17:06:59Z")
Mark, Please clarify what the “hardware’s NIC” is if its not the computer your software is running on? Thanks bud. ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [31 July 2020 17:18 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/17 "2020-07-31T17:18:27Z")
My software connects to a digital mixer via ethernet. The “Hardware’s NIC” is the NIC on that digital mixer. It is not configurable in any way, so my software has to accommodate it, and that means no jumbo frames, it seems. When a customer uses my software, I would like to check their computer’s NIC to see if it has Jumbo frames enabled, and if it does, to warn them that the software will not work until they disable that. ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [6 August 2020 17:40 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/18 "2020-08-06T17:40:46Z")
Here’s my crude solution… ```auto Private Function CheckMTU() As Integer Dim s As New Shell Dim r As New RegEx Dim Fields() As String Dim Index As Integer If TargetWindows Then s.Execute("netsh interface ipv4 show interfaces | find " + Chr(34) + " connected" + Chr(34) + _ " | find /v " + Chr(34) + "Loopback" + Chr(34)) Index = 3 Elseif TargetMacOS Then s.Execute("ifconfig | grep flags=8863 | grep -v bridge | grep -o 'mtu.*'") Index = 1 Elseif TargetLinux Then s.Execute("ifconfig | grep flags=4163 | grep -v bridge | grep -o 'mtu.*'") Index = 1 End If If s.ErrorCode = 0 Then r.SearchPattern = ("\s+") r.ReplacementPattern = Chr(9) r.Options.ReplaceAllMatches = True Fields = r.Replace(s.Result).Split(Chr(9)) Return Val(Fields(Index)) Else Return -1 End If End Function ``` ---
**Author:** ![Meestor\_X](https://ifnotnil.com/user_avatar/ifnotnil.com/meestor_x/32/567_2.png) [@Meestor\_X](https://ifnotnil.com/u/Meestor_X)\ **Post date:** [6 August 2020 17:43 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/19 "2020-08-06T17:43:21Z")
It would be better if I could pass it a socket and it would check that one specifically… If there’s multiple active interfaces, it’s just returning the MTU of the 1st one… ---
**Author:** ![npalardy](https://ifnotnil.com/user_avatar/ifnotnil.com/npalardy/32/10_2.png) [@npalardy](https://ifnotnil.com/u/npalardy)\ **Post date:** [6 August 2020 17:57 UTC](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798/20 "2020-08-06T17:57:40Z")
a connected socket has a networkinterface property and that can tell you which address etc it on havent checked any of the commands in your code to see if you could use that to find the right one but it seems plausible [Next page](https://ifnotnil.com/t/tcpsocket-macos-vs-windows/798.md?page=2)