I'm working on an Ethercat master written Go. The underlying library is at http://github.com/distributed/ecat and contains one link level driver, using UDP and multicast. I'm having trouble to get this link level driver to work consistently across multiple platforms (OS X, Windows, Linux) and different networking configurations.
For those not familiar with Ethercat, here's how it works. Ethercat is an industrial bus system based on Ethernet. There's one bus master and potentially many slaves, which are connected into a logical ring. The master can be built from off-the-shelf hardware, i.e. with normal Ethernet interface cards. The master sends a packet on its Ethernet interface, the slaves modify the packet on the fly and after passing through all the slaves, the master receives the packet on the same network interface that sent it. Depending on the number of slaves, the network interface might start to receive the packet while it is still transmitting the very same packet. There are two possible formats for Ethercat frames. The first is an Ethernet packet with a special ethertype. The second is a UDP packet destined for port 0x88a4.
Depending on the commands contained in an Ethernet packet, the slaves may or may not modify the packet's Ethercat data. Apart from changing Ethercat data, the only thing about the packet that is changed is that bit 1 of the Ethernet destination address is set to 1. The IP header of the packet is not touched by the Ethercat slaves.
My code works as follows. I join a multicast group, say 239.255.65.10 on interface xyz, where I connected my Ethercat slaves. To exchange data with the bus, I send a packet, let's call it pA on this interface to 239.255.65.10. The OS fills in the source address, say the IP address 192.168.5.2 of interface xyz. After the packet passed through the bus and was possibly altered, it's now packet pB. The IP header still has a source of 192.168.5.2 and a destination of 239.255.65.10. Depending on the host's networking settings, this packet might or might not reach my application. In the cases where it does not reach my application, say when rp_filter is set, on Linux, packet pB is rejected because it looks like it originated from my machine, but we shouldn't be receiving our own packets over the network.
What steps can I take to reliably receive the processed packet pB? Please note that I'm not speaking about loopback - loopback is about receiving packet pA, my question is about receiving pB.
Related
I can't wrap my head around how packet-sniffers can be used by anyone on the network.
I know very little about how networks work, but let me put it this way: suppose the mailman comes around delivering a package to my doorstep. Why is is that I'm able to rifle though all his other packages and look around? Shouldn't the mailman only hand me packages that are mine?
To quote William Pursell's comment, which he should have made an answer and should have expanded:
The mailman does not deliver the letter your doorstep. Instead, he opens your mail and shouts out: "this letter is for <name>. No-one else should listen" and then proceeds to read the letter out loud. –
In the original Ethernet network, there was a shared cable to which all hosts were attached; if a host wanted to send a message to another host, it would transmit the packet on the shared cable, with an Ethernet header with the destination Ethernet address of the other host. All hosts on the cable could, in theory, see the packet. (This was in an era where security was less of a concern; for cases where security was a concern, the packets were encrypted in a fashion that the other host could fairly easily decrypt but that other hosts would have to decrypt in some other more difficult fashion.)
In addition, a packet can be sent to the "broadcast" Ethernet address (all 1's) or a "multicast" Ethernet address (which several hosts are configured to handle); broadcast packets are intended for all hosts on the Ethernet to see, and multicast packets are intended for all hosts in the address's "multicast group" to see.
Normally, an Ethernet adapter would ignore packets that aren't sent to its Ethernet address, to the broadcast Ethernet address, or to a multicast address for which it's configured to receive packets. Most can, however, be put into "promiscuous" mode, where they pass all packets to the host; that mode is used for packet sniffers.
Most current Ethernets are "switched"; instead of a shared cable, there's an Ethernet switch, and hosts plug into the switch with a cable. Packets sent to a particular host's Ethernet address will only be sent out the switch port for that host (unless somebody's configured the hosts to have a "mirror port" on which all traffic is sent, or unless the switch hasn't yet determined which port is the port for that Ethernet address). Broadcast packets are sent to all ports, and multicast packets may be sent to all ports or, if the switch can determine that, to those ports that have adapters configured for the multicast address in question.
Wi-Fi networks are similar, but they're usually protected with encryption, as it's easier for somebody to bring in a laptop and put it into "monitor mode" to sniff on a given channel than it is for somebody to bring in a laptop, configure a switch to have a mirror port (or use some other mechanism to get access to the traffic), and plug the laptop into the appropriate port on the switch.
Generally speaking, with switches you are correct. However the person who owns the switch can intercept your traffic at will (in your example that would be the mail service). Also, sometimes the switch can be fooled into rerouting traffic (someone accepts the package on your behalf and then goes through it).
Furthermore, certain kinds of packets need to be broadcast. For instance ARP packets (where one computer is asking for the ethernet address of another computer specified by IP) get broadcast to all ethernet addresses and therefore can get sniffed.
Generally speaking man-in-the-middle requires someone in the connection chain to be compromised. For instance, your ISP or the company they buy transit from could create a man in the middle attack. (This is also why security in countries oppressive regimes is so difficult, they control the internet and therefore can sniff/man-in-the-middle attack whatever they please). This can also be done by compromising the DNS server you use to point you to a different site that can grab your data and forward your data (or a modified version thereof) on to the true site.
In the good 'ol days hubs were quite common (or even older, everyone shared a piece of coax). In this case it's more like the package gets dropped on the first door, the occupant looks to see if it's theirs, if not, passes it on, if so, copies what's inside and passes the package along. In other words, packet sniffing is actually quite easy.
Yes or more simple way packet sniffing not is good, while you login on the web page you normal use a secret password for verify this is you.
But in case we has a packet sniffer she/he can also see and read what you password is.
And laiter login in the web page as you.
Or in she/he can also modify you data on the road to do something other.
And in the case of internet, the normal way is more the one computer is use to
send a message from in this case Alice to Alice bank.
And in each of this computer ( right side of image ) is this possible
for the use to edit the message if the use want as in this image.
Eva is use for deliver the message to Alice Bank, but she can
can read the message/order and in some case edit this to get the bank
to think Alice want to transfer money to Eva instead of Bob.
In short for protect us against eva to modify the message we can use
hash-algorithm or cryptographer algorithm.
In the client-server environment, when client sends a packet (with source ip / dest ip / ports ... etc) requesting "GET /index.php ... etc",
at the server application (daemon) arrives the whole packet (the whole bits of data) including mac, IPs, ports, tcp flags, payload ? Or just the payload ?
Because I don;t understand how the scripts can read remote address (like echo $_SERVER['REMOTE_ADDR']; )
The server machine gets the whole packet. Its kernel and TCP/IP stack receives and processes it. The application server is using a socket to talk to the kernel, which is a higher-layer interface than raw packets; therefore it has a different view. Assuming we are talking about TCP, you will find among other things:
Information from the physical or datalink layer (such as source and destination MAC addresses) is not available on the socket (unless you do very fancy and probably non-portable things).
Some information from the IP & TCP layer is made available so the application can retrieve it using special system calls such as getsockname() and getpeername(). This includes the IP addresses and ports.
The application is not concerned with most of the rest of the information from the IP & TCP layers and it is not made available on the socket. For example, options, window size, checksum, fragment offset.
The application sends and receives data on the socket as though it was a continuous stream of bytes. It does not know or care how the datastream is broken up into small packets each containing a piece of the data.
for the specific case of $_SERVER['REMOTE_ADDR']; which you highlight, this information comes from the aforementioned getpeername() system call. PHP calls this for you and makes the information available.
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).
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).