{"id":1038,"date":"2009-09-19T21:42:51","date_gmt":"2009-09-19T19:42:51","guid":{"rendered":"https:\/\/alax.info\/blog\/?p=1038"},"modified":"2009-09-22T16:49:48","modified_gmt":"2009-09-22T14:49:48","slug":"udp-message-sent-off-wrong-network-interface","status":"publish","type":"post","link":"https:\/\/alax.info\/blog\/1038","title":{"rendered":"UDP message sent off wrong network interface"},"content":{"rendered":"

This is a funny one and I wonder what is exactly causing such misbehavior. An UDP broadcasting socket is being bound to IP address 192.168.0.2<\/strong>:<\/p>\n

__E(<\/span>m_Socket.<\/span>Create(<\/span>SOCK_DGRAM,<\/span> IPPROTO_UDP)<\/span> !<\/span>=<\/span> INVALID_SOCKET)<\/span>;<\/span>\r\nstatic<\/span> const<\/span> DWORD<\/span> g_nBroadcastValue =<\/span> 1<\/span>;<\/span>\r\n__E(<\/span>m_Socket.<\/span>SetOption(<\/span>SOL_SOCKET,<\/span> SO_BROADCAST,<\/span> &<\/span>g_nBroadcastValue,<\/span> sizeof<\/span> g_nBroadcastValue)<\/span>)<\/span>;<\/span>\r\nZeroMemory<\/span>(<\/span>&<\/span>m_LocalAddress,<\/span> sizeof<\/span> m_LocalAddress)<\/span>;<\/span>\r\nm_LocalAddress.<\/span>sin_family =<\/span> AF_INET;<\/span>\r\nm_LocalAddress.<\/span>sin_port =<\/span> htons<\/span>(<\/span>nPort)<\/span>;<\/span> \/\/ 7365<\/span><\/strong><\/span>\r\nm_LocalAddress.<\/span>sin_addr.<\/span>S_un.<\/span>S_addr =<\/span> htonl<\/span>(<\/span>nLocalIpAddress)<\/span>;<\/span> \/\/ 192.168.0.2<\/span><\/strong><\/span>\r\n_Z4(<\/span>atlTraceGeneral,<\/span> 4<\/span>,<\/span> _T(<\/span>\"<\/span>m_Socket <\/span>%d<\/span>, m_LocalAddress.sin_addr %hs<\/span>\\n<\/span>\"<\/span>)<\/span>,<\/span> m_Socket,<\/span> inet_ntoa<\/span>(<\/span>m_LocalAddress.<\/span>sin_addr)<\/span>)<\/span>;<\/span>\r\n__E(<\/span>bind<\/span>(<\/span>m_Socket,<\/span> (<\/span>SOCKADDR*<\/span>)<\/span> &<\/span>m_LocalAddress,<\/span> sizeof<\/span> m_LocalAddress)<\/span> !<\/span>=<\/span> SOCKET_ERROR)<\/span><\/pre>\n
Then off this socket a broadcast message is sent using sendto<\/a>:<\/p>\n
SOCKADDR_IN RemoteAddress;<\/span>\r\nZeroMemory<\/span>(<\/span>&<\/span>RemoteAddress,<\/span> sizeof<\/span> RemoteAddress)<\/span>;<\/span>\r\nRemoteAddress.<\/span>sin_family =<\/span> AF_INET;<\/span>\r\nRemoteAddress.<\/span>sin_port =<\/span> htons<\/span>(<\/span>7364<\/span>)<\/span>;<\/span>\r\nRemoteAddress.<\/span>sin_addr.<\/span>S_un.<\/span>S_addr =<\/span> INADDR_BROADCAST;<\/span>\r\n_Z4(<\/span>atlTraceGeneral,<\/span> 4<\/span>,<\/span> _T(<\/span>\"<\/span>BroadcastSocketData.m_Socket <\/span>%d<\/span>\\n<\/span>\"<\/span>)<\/span>,<\/span> BroadcastSocketData.<\/span>m_Socket)<\/span>;<\/span>\r\n__E(<\/span>sendto<\/span>(<\/span>BroadcastSocketData.<\/span>m_Socket,<\/span> NULL<\/span>,<\/span> 0<\/span>,<\/span> 0<\/span>,<\/span> (<\/span>const<\/span> SOCKADDR*<\/span>)<\/span> &<\/span>RemoteAddress,<\/span> sizeof<\/span> RemoteAddress)<\/span> !<\/span>=<\/span> SOCKET_ERROR)<\/span><\/pre>\n
The problem however is that WireShark<\/a> shows the message going off the wrong network interface, with IP address 192.168.56.1<\/strong>, while 192.68.0.2<\/strong> is an IP address on a different network adapter:<\/p>\n
C:\\>ipconfig \/all\r\n\r\nEthernet adapter Home Area Connection:\r\n\r\n        Connection-specific DNS Suffix  . :\r\n        Description . . . . . . . . . . . : Intel(R) 82566DC-2 Gigabit Network Connection\r\n        Dhcp Enabled. . . . . . . . . . . : No\r\n        IP Address. . . . . . . . . . . . : 192.168.0.2\r\n        Subnet Mask . . . . . . . . . . . : 255.255.0.0\r\n        Default Gateway . . . . . . . . . : 192.168.0.1\r\n        DNS Servers . . . . . . . . . . . : 192.168.0.1\r\n                                            4.2.2.4\r\n\r\nEthernet adapter VirtualBox Host-Only Network:\r\n\r\n        Connection-specific DNS Suffix  . :\r\n        Description . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter\r\n        Dhcp Enabled. . . . . . . . . . . : No\r\n        IP Address. . . . . . . . . . . . : 192.168.56.1\r\n        Subnet Mask . . . . . . . . . . . : 255.255.255.0\r\n        IP Address. . . . . . . . . . . . : fe80::a00:27ff:fe00:5ce8%7\r\n        Default Gateway . . . . . . . . . :\r\n        DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1\r\n                                            fec0:0:0:ffff::2%1\r\n                                            fec0:0:0:ffff::3%1<\/pre>\n
The problem appears to be in collision of networks: 192.168.0.0\/16<\/strong> and 192.168.56.0\/24<\/strong>. It seems that nevertheless the socket is bound to proper NIC, where the message is expected to be sent through, Windows Sockets takes a random matching\u00a0 adapter for the transmission.<\/p>\n
A correction of the IP address from 192.168<\/span>.56.1<\/strong> to 192.169<\/span>.56.1<\/strong>. immediately fixes the problem. There however has been no problems with other applications, the collision did not bring any other issues.<\/p>\n
Some more information on the topic: Windows XP Professional, 32-bit, Service Pack 3.<\/p>\n
See also on MSDN Forums: http:\/\/social.msdn.microsoft.com\/Forums\/…\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
This is a funny one and I wonder what is exactly causing such misbehavior. An UDP broadcasting socket is being bound to IP address 192.168.0.2: __E(m_Socket.Create(SOCK_DGRAM, IPPROTO_UDP) != INVALID_SOCKET); static const DWORD g_nBroadcastValue = 1; __E(m_Socket.SetOption(SOL_SOCKET, SO_BROADCAST, &g_nBroadcastValue, sizeof g_nBroadcastValue)); ZeroMemory(&m_LocalAddress, sizeof m_LocalAddress); m_LocalAddress.sin_family = AF_INET; m_LocalAddress.sin_port = htons(nPort); \/\/ 7365 m_LocalAddress.sin_addr.S_un.S_addr = htonl(nLocalIpAddress); \/\/… <\/p>\n
Read the full article<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[256,254,253,250,255,251,252],"class_list":["post-1038","post","type-post","status-publish","format-standard","hentry","category-technology","tag-adapter","tag-broadcast","tag-datagram","tag-network","tag-nic","tag-socket","tag-udp"],"_links":{"self":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts\/1038","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/comments?post=1038"}],"version-history":[{"count":0,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/posts\/1038\/revisions"}],"wp:attachment":[{"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/media?parent=1038"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/categories?post=1038"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alax.info\/blog\/wp-json\/wp\/v2\/tags?post=1038"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}