CAsyncSocket: sender-ip / sender-mac-addr?
in [MFC]
|
Prev: Bitmap dialogs
Next: CComQIPtr and XML question
From: Stephen Myers on 25 May 2010 16:52 Yeah, I hate it when that happens to me too. Hector Santos wrote: > See my single line comment in embedded and buried in an over quoted > response below: > > Stephen Myers > wrote: > >> See my comments below: >> >> Hector Santos wrote: >>> bernd wrote: >>> >>>> Hi, >>>> >>>> is it possible to get some more information (in the OnReceive-method) >>>> about a received ethernet packet (for example; the ip-addr and / or >>>> mac addr from the sender)? >>>> >>>> I`m using casyncsocket; a udp-listener (at a specific port) >>> >>> 1) The IP-ADDR is easy from the socket handle: >>> >>> CAsyncSocket::GetPeerName() >>> >>> It would be redundant to do this in the OnReceive() since it will >>> never change. Do it once with the OnConnect(). >> >> There is no OnConnect with UDP. You can receive from multiple clients >> on the same socket. > > > I missed he mentioned udp. Then using ReceiveFrom() is the right way, > >> >>> >>> 2) But for the mac address of the client, it depends. >>> >>> The MAC ADDR is part of your NETWORK of computers. Not the OTHER >>> GUYS network of computers. You must be at least on the same subnet. >>> >>> For just any client that is not part of your LAN, just sending your a >>> TCP/UPD packet, you will not see it. >>> >>> Only for a client that is connecting you to establish a PPP connection >>> does the MAC can passed during the link negotiation phase. >>> >>> In other words, you are acting as ISP or host that has a PPP server >>> and your users connecting to you to get an IP address. They are now >>> part of your "LAN" >>> >>> Nonetheless, if the SENDER is part of your network, you can use the >>> SendARP() which is part of the IP HELPER LIBRARY. See SendARP on MSDN. >>> >> >> Steve > > >
From: Hector Santos on 25 May 2010 20:33 Stephen Myers > wrote: > Yeah, I hate it when that happens to me too. > I also hate it when I discover interesting .. <g> I never used CAsyncSocket in our production ware, maybe some where, but nothing I recall every done significant. It is all done internally directly with sockets. So I was playing with MFC CAsyncSocket for a UDP socket example using our "WCPING" utility logic to repeat results. WCPING is a utility we have that discovers our RPC servers on a network by broadcasting a packet and waiting 2 seconds for responses from any server running on the network. The WCPING tool is a diagnostic tool for customers resolving networking/router setup issues when they have multiple servers running in a LAN or WAN. Here is an example: I started two RPC servers on my network, on machines: hdev1 192.168.1.2 hdev21 192.168.1.101 c:\wc63> wcping wcPing v6.0.451.3 (c) copyright 1998-2004 by Santronics Software Inc. * Client Broadcasting: Requesting service from all Wildcat! Servers on network. + Waiting for server responses.... > server: HDEV21 (Default site name) ncacn_ip_tcp:hdev21[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] * Available servers count: 2 ! Since mulitple servers were found, GUI clients will be ! shown a list of servers to be selected. Non-GUI clients ! will fail. To avoid this, define the following environment ! variables: SET WILDCATSERVER=machinename SET WILDCATSERVERIP=ipaddress << if machine on different sub-net The reason for this is that when they run GUI utilities, if there are multiple server, then a POPUP comes up asking which one to connect too. wcPING gives a hint on setting environment variables to be specific. Ok, so in MFC using CAsyncSocket I began to duplicate the port 4012 broadcasting and getting OnReceive(). In OnReceive(), I used the ReceiveFrom() overload that returns the ip and port. What I was noticing there were three repeated OnReceive() all repeating the same information, same IP and PORT. So I tried using SYNC logic instead to see if there was a hidden repeated events firing in MFC code. I didn't expect it, but I tried it anyway. Same thing, three repeated ReceiveFrom(). So I went back to the C/C++ WCPING source to see if it dealt with this "repeated" response issue. After all, it was the same basic UDP broadcast and response source code logic, thus I should see the same thing there. wcPING uses sync calls with a 2 second delay on select(). CAsyncSocket source code has the same exact select() logic but with no delay. (Too bad, CAsyncSocket does not have a OnReceiveTimeOut() handler). WCPING indeed has DUPE checking logic in order to show the unique listing above. I enabled a debug display and it showed four results. server: HDEV21 (Default site name) ncacn_ip_tcp:hdev21[4012] server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] Note: During the MFC test I only had the HDEV1 server running. WCPING shows the response packet information, HostName, Service Name and RPC binding string. It didn't bother to get and show the IP address. That suppose to be transparent anyway for RPC. I then remembered HDEV1 is multi-home with three IPs! 192.168.1.2 HDEV1 192.168.1.3 HDEV2 192.168.1.4 HDEV3 And that is the reason I am getting 3 OnReceive events!! But it wasn't reflecting the true IP, only showing the first one 192.168.1.2 for all three responses. In short, on the server side, it is using listening address: sin.sin_addr.s_addr = INADDR_ANY; which binds all multi-home IP address for the machine, hence a broadcast will cause event for each one. So I am wondering if you would think or agree with me the SOCKET stack *should* at least return the proper sockaddr for the ReceiveFrom() for the particular UDP binded receive socket response? Comment? I have to dig deeper because our server does have logic to bind only a local IP for the local connections (ncalpc). But for networking (ncacn_ip_tcp), it doesn't use a specific machine ip. -- HLS
From: Hector Santos on 25 May 2010 21:42 getpeername() in MSDN describes the situation for UDP broadcasting. The Local IP is unknown by the server if INADDR_ANY is used for the UDP server. But it does say it may become available once I/O starts but that was already the case when the server is doing a recvfrom(). I wonder if the IP Helper API can help here. A event occurs for each multi-ip bound to the socket. The IP must be stored some where I would think. :) -- Hector Santos wrote: > Stephen Myers > wrote: > >> Yeah, I hate it when that happens to me too. >> > > I also hate it when I discover interesting .. <g> > > I never used CAsyncSocket in our production ware, maybe some where, but > nothing I recall every done significant. It is all done internally > directly with sockets. > > So I was playing with MFC CAsyncSocket for a UDP socket example using > our "WCPING" utility logic to repeat results. > > WCPING is a utility we have that discovers our RPC servers on a network > by broadcasting a packet and waiting 2 seconds for responses from any > server running on the network. The WCPING tool is a diagnostic tool > for customers resolving networking/router setup issues when they have > multiple servers running in a LAN or WAN. > > Here is an example: > > I started two RPC servers on my network, on machines: > > hdev1 192.168.1.2 > hdev21 192.168.1.101 > > c:\wc63> wcping > > wcPing v6.0.451.3 (c) copyright 1998-2004 by Santronics Software Inc. > * Client Broadcasting: Requesting service from all Wildcat! Servers on > network. > + Waiting for server responses.... > > server: HDEV21 (Default site name) ncacn_ip_tcp:hdev21[4012] > > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > * Available servers count: 2 > > ! Since mulitple servers were found, GUI clients will be > ! shown a list of servers to be selected. Non-GUI clients > ! will fail. To avoid this, define the following environment > ! variables: > > SET WILDCATSERVER=machinename > SET WILDCATSERVERIP=ipaddress << if machine on different sub-net > > The reason for this is that when they run GUI utilities, if there are > multiple server, then a POPUP comes up asking which one to connect > too. wcPING gives a hint on setting environment variables to be specific. > > Ok, so in MFC using CAsyncSocket I began to duplicate the port 4012 > broadcasting and getting OnReceive(). In OnReceive(), I used the > ReceiveFrom() overload that returns the ip and port. > > What I was noticing there were three repeated OnReceive() all repeating > the same information, same IP and PORT. > > So I tried using SYNC logic instead to see if there was a hidden > repeated events firing in MFC code. I didn't expect it, but I tried it > anyway. > > Same thing, three repeated ReceiveFrom(). > > So I went back to the C/C++ WCPING source to see if it dealt with this > "repeated" response issue. After all, it was the same basic UDP > broadcast and response source code logic, thus I should see the same > thing there. wcPING uses sync calls with a 2 second delay on > select(). CAsyncSocket source code has the same exact select() logic > but with no delay. (Too bad, CAsyncSocket does not have a > OnReceiveTimeOut() handler). > > WCPING indeed has DUPE checking logic in order to show the unique > listing above. I enabled a debug display and it showed four results. > > server: HDEV21 (Default site name) ncacn_ip_tcp:hdev21[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > > Note: During the MFC test I only had the HDEV1 server running. > > WCPING shows the response packet information, HostName, Service Name and > RPC binding string. It didn't bother to get and show the IP address. > That suppose to be transparent anyway for RPC. > > I then remembered HDEV1 is multi-home with three IPs! > > 192.168.1.2 HDEV1 > 192.168.1.3 HDEV2 > 192.168.1.4 HDEV3 > > And that is the reason I am getting 3 OnReceive events!! > > But it wasn't reflecting the true IP, only showing the first one > 192.168.1.2 for all three responses. > > In short, on the server side, it is using listening address: > > sin.sin_addr.s_addr = INADDR_ANY; > > which binds all multi-home IP address for the machine, hence a broadcast > will cause event for each one. > > So I am wondering if you would think or agree with me the SOCKET stack > *should* at least return the proper sockaddr for the ReceiveFrom() for > the particular UDP binded receive socket response? > > Comment? > > I have to dig deeper because our server does have logic to bind only a > local IP for the local connections (ncalpc). But for networking > (ncacn_ip_tcp), it doesn't use a specific machine ip. > -- HLS
From: Hector Santos on 25 May 2010 22:16 Studying this, it appears the WinSock level 2 function WSARecvMsg() http://msdn.microsoft.com/en-us/library/ms741687(v=VS.85).aspx Provide a method to obtain the IP address of the sender that originates on a multi-home machine and multiple responses are received. -- HLS Hector Santos wrote: > getpeername() in MSDN describes the situation for UDP broadcasting. The > Local IP is unknown by the server if INADDR_ANY is used for the UDP server. > > But it does say it may become available once I/O starts but that was > already the case when the server is doing a recvfrom(). > > I wonder if the IP Helper API can help here. A event occurs for each > multi-ip bound to the socket. The IP must be stored some where I would > think. :) -- HLS
From: Stephen Myers on 26 May 2010 11:22
Hector Santos wrote: > Stephen Myers > wrote: > >> Yeah, I hate it when that happens to me too. >> > > I also hate it when I discover interesting .. <g> > > I never used CAsyncSocket in our production ware, maybe some where, but > nothing I recall every done significant. It is all done internally > directly with sockets. > > So I was playing with MFC CAsyncSocket for a UDP socket example using > our "WCPING" utility logic to repeat results. > > WCPING is a utility we have that discovers our RPC servers on a network > by broadcasting a packet and waiting 2 seconds for responses from any > server running on the network. The WCPING tool is a diagnostic tool > for customers resolving networking/router setup issues when they have > multiple servers running in a LAN or WAN. > > Here is an example: > > I started two RPC servers on my network, on machines: > > hdev1 192.168.1.2 > hdev21 192.168.1.101 > > c:\wc63> wcping > > wcPing v6.0.451.3 (c) copyright 1998-2004 by Santronics Software Inc. > * Client Broadcasting: Requesting service from all Wildcat! Servers on > network. > + Waiting for server responses.... > > server: HDEV21 (Default site name) ncacn_ip_tcp:hdev21[4012] > > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > * Available servers count: 2 > > ! Since mulitple servers were found, GUI clients will be > ! shown a list of servers to be selected. Non-GUI clients > ! will fail. To avoid this, define the following environment > ! variables: > > SET WILDCATSERVER=machinename > SET WILDCATSERVERIP=ipaddress << if machine on different sub-net > > The reason for this is that when they run GUI utilities, if there are > multiple server, then a POPUP comes up asking which one to connect > too. wcPING gives a hint on setting environment variables to be specific. > > Ok, so in MFC using CAsyncSocket I began to duplicate the port 4012 > broadcasting and getting OnReceive(). In OnReceive(), I used the > ReceiveFrom() overload that returns the ip and port. > > What I was noticing there were three repeated OnReceive() all repeating > the same information, same IP and PORT. > > So I tried using SYNC logic instead to see if there was a hidden > repeated events firing in MFC code. I didn't expect it, but I tried it > anyway. > > Same thing, three repeated ReceiveFrom(). > > So I went back to the C/C++ WCPING source to see if it dealt with this > "repeated" response issue. After all, it was the same basic UDP > broadcast and response source code logic, thus I should see the same > thing there. wcPING uses sync calls with a 2 second delay on > select(). CAsyncSocket source code has the same exact select() logic > but with no delay. (Too bad, CAsyncSocket does not have a > OnReceiveTimeOut() handler). > > WCPING indeed has DUPE checking logic in order to show the unique > listing above. I enabled a debug display and it showed four results. > > server: HDEV21 (Default site name) ncacn_ip_tcp:hdev21[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > server: HDEV1 (Santronics Research) ncacn_ip_tcp:hdev1[4012] > > Note: During the MFC test I only had the HDEV1 server running. > > WCPING shows the response packet information, HostName, Service Name and > RPC binding string. It didn't bother to get and show the IP address. > That suppose to be transparent anyway for RPC. > > I then remembered HDEV1 is multi-home with three IPs! > > 192.168.1.2 HDEV1 > 192.168.1.3 HDEV2 > 192.168.1.4 HDEV3 > > And that is the reason I am getting 3 OnReceive events!! > > But it wasn't reflecting the true IP, only showing the first one > 192.168.1.2 for all three responses. > > In short, on the server side, it is using listening address: > > sin.sin_addr.s_addr = INADDR_ANY; > > which binds all multi-home IP address for the machine, hence a broadcast > will cause event for each one. > > So I am wondering if you would think or agree with me the SOCKET stack > *should* at least return the proper sockaddr for the ReceiveFrom() for > the particular UDP binded receive socket response? > > Comment? I'd be interested in seeing what something like WireShark records for this. It's quite possible that the three responses came from the same NIC and IP. Consider that HDEV1 receives a ping from each interface. It then responds with a UDP packet and a target IP. The SendTo() does not specify an interface, so HDEV1 is free to chose one arbitrarily. It is likely that all three responses came from the same interface. SM > > I have to dig deeper because our server does have logic to bind only a > local IP for the local connections (ncalpc). But for networking > (ncacn_ip_tcp), it doesn't use a specific machine ip. > |