Say for example, my machine is multi-homed and has two network interfaces:
Wireless LAN adapter WiFi : Ip: 10.20.19.140
Ethernet adapter Ethernet: Ip: 10.20.19.154
I create two UDP sockets one listening on (1) and other on (2). The i am assuming the interface is already assigned, then why do i need IP_MULTICAST_IF and IPV6_MULTICAST_IF?
The IP_MULTICAST_IF or IPV6_MULTICAST_IF settings tell your socket which interface to send its multicast packets on. It's a separate, independent setting from the interface that you bound your socket to with bind(), since bind() controls which interface(s) the socket receives multicast packets from.
(Granted, the BSD sockets API implementers could have made the assumption that a socket would always want to send packets out over the same interface it receives packets on, but that would make a number of use cases more difficult; for example, if you are using a single socket to receive multicast packets from all interfaces (via INADDR_ANY), then when sending a packet using that socket you'd still need a way to specify which multicast interface you want that packet to be sent over)
Related
I have a Windows 7 machine with 3 Ethernet interfaces.
I created a UDP Socket and bound to INADDR_ANY. When the socket receives a broadcast UDP packet, how to know which network interface received the packets?
I need to get IP address corresponding to the network interface also?
Check out Wireshark:
https://www.wireshark.org/
From Wireshark about their product:
"Wireshark is the world's foremost network protocol analyzer. It lets you see what's happening on your network at a microscopic level. It is the de facto (and often de jure) standard across many industries and educational institutions."
I am a developer of WinPcap, a famous packet capturing and sending software under Windows. I have ported WinPcap to NDIS 6 Light-Weight Filter technique, but it still doesn't support loopback packets (such as packets sent to and received from 127.0.0.1) capturing because of Windows' nature: The loopback packets are handled directly in TCP/IP stack and don't go down to NDIS layer.
Someone told me that Windows Filtering Platform can see the loopback traffic, so I have done some research about it. I have several questions about this.
1) What are actually loopback packets? I mean the packets NDIS can't see? Like when I ping 127.0.0.1, these ICMP packets are definitely loopback ones. When I ping an address that a local network adapter has bound to (like 192.168.0.24), it is also loopback I think. Are these all conditions? If yes, then I can filter out which packets are loopback ones based on whether their local IPs are 127.0.0.1 or local adapter IPs (like 192.168.0.24).
2) I learnt that WFP has many layers, I think my requirement should use the "IP Packet (Network Layer)", I wonder that can WFP Network Layer captures all loopback packets inbound and outbound?
3) I don't know if the loopback packets captured by WFP will have an Ethernet header? If not, then I think I should manually add Ethernet header to the packet prefix before sending them to user mode, as WinPcap is an ethernet-level packet capture software and many software using WinPcap (like Wireshark) will by default parse the packets from Ethernet layer. However, I think I will let the whole Ethernet header to be all-0, as there's actually no Ethernet header in fact.
Thanks and appreciated for your help!
My application needs to receive UDP packets from multiple destination ports (this is a bonafide application and not a sniffer). Therefore, I have chosen to use a PF_PACKET socket and to do port filtering at the application level.
Here's how I create the socket:
int g_rawSocket = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
I am correctly receiving UDP packets. However, the kernel on which the application runs is sending ICMP packets of type 'Destination unreachable' and code 'Port unreachable' to the remote device that is sending packets to my app. I guess that this is because I have not bound a port number to the socket. However, I wonder if it is appropriate to use bind with a PF_PACKET socket, especially as I need to bind multiple ports to it, which I guess is not possible.
Any comments please?
No, it can't be bound to a specific port, since it's working on a lower level than the Transport (UDP/TCP) layer. However, you could open and listen to all sockets, using regular UDP (AF_INET/SOCK_DGRAM) sockets and select for example and as far as I know you can bind and listen to as many sockets as you want, as long as you don't exceed the limits of open file descriptors for your process.
I have also done the same thing in my application.
in my case i have created sockets as many i need & bind them with the particular port. but i m not listening to any socket. so i created one raw socket
int sock_raw = socket(AF_INET , SOCK_RAW , IPPROTO_UDP);
& then received all the traffic without any ICMP.
So i think u have to bind all the ports to avoid ICMP either you have to some kernel hacking as stoping or removing the code for ICMP in the linux-kernel code & build it again
I have a PC with two network cards connected to different networks (multi homed network setup). I want to send UDP broadcast frames on both networks. The senders IP address of the frames must be the IP address of the adapter, that is used to send the frame. The destination address should be the LIMITED BROADCAST address.
The customer application should not run with administrative rights (UAC is not acceptible).
How can I send these UDP frames to the LIMITED BROADCAST address (255.255.255.255)?
How could I send these frames to the NETWORK BROADCAST address (x.y.z.255)?
I know how to do this with raw sockets. But raw sockets can only be used with administrative rights.
Can't you just open two normal UDP sockets and bind one to each of the interface addresses and then simply send to the broadcast addresses ?
This will, as far as I know, deal with the sending on both networks and it will ensure that the packets sent will have the correct ip address. It wont work if you bind a single socket to INADDR_ANY which, of course, WILL work if there's only a single network adapter in the machine. To create a complete solution it's probably best to iterate over the available addresses and create a socket for each, bind to each and send from each.
I recently turned on Windows Firewall logging on my computer and started tracking incoming and outgoing connections. Something curious about the logfiles is that I have noticed numerous UDP packets (in fact, it constitutes basically all of my incoming traffic) that don't have my host as destination or source showing up in the logs.
I thought this might be a implementation detail for UDP (the packets are hopping over my computer in the subnet) but Wikipedia'ing UDP didn't enlighten me any more, and I don't see why my computer should be forwarding these packets in the first place.
Any ideas?
Edit 1: Here is what a log file line with the mysterious UDP packet looks like:
2008-10-11 16:04:31 ALLOW UDP 18.243.7.218 239.255.255.250 49152 3702 0 - - - - - - - RECEIVE
Is 239.255.255.250 a broadcast address? Now that you mention it, the UDP packets I'm seeing have very specific destinations, basically 224.0.0.252, 239.255.255.250, 18.243.255.255. I also get phantom ICMP pings addressed to 224.0.0.1.
The packets addressed to IPs starting with 239 and 224 are multicast packets. This is a way to address traffic to a group of computers without broadcasting it to an entire network. It is used by various legitimate protocols.
224.0.0.252 is the address used by the Link Local Name Resolution protocol.
239.255.255.250 is the address used by the Simple Service Discovery Protocol.
224.0.0.1 is the all hosts address, used by your router to see who on your network is willing to participate in multicast conversations.
The ones addressed to 18.243.255.255 look like broadcasts, again this is used by many legitimate protocols such as Bonjour.
As recommended by Luka, a good protocol analyzer like Wireshark will tell you precisely what each of these packets are and what they contain.
It depends on the type of connection you are on.
On most cable modem ISP's you are basicly on the same LAN as your neigburs, and can usualy see some of their traffic (like brodcast).
Id recomend you install packet sniffer and see what is realy going on.
Good multiplatform packet sniffer is Wireshark
Hard to say without analyzing the log data, but they could be broadcast packets on the segment, in which case you're system would listen to them. This is possible in IPv4 and IPv6.
Your system should not be forwarding them unless it's set up to route, but it can certainly be listening to packets all the time (various network protocols use UDP).