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.
Related
Im new to socket programing . I wanted to send few data from Kernel to userspace. I wanted know socket of which family and protocol is suitable to create?
UDP,
TCP,
RAW,
NETLINK,
It will be better if anyone explains usecase of socket types.
Thanks in advance
Check the following socket API
int socket(int domain, int type, int protocol);
1)Netlink sockets are used for communicating between Userspace and the kernel space. Check the following link for example.
2)TCP(of type SOCK_STREAM) and UDP(SOCK_DGRAM) are used mostly for communicating over network. These sockets are of the domain AF_INET. TCP is used for file downloading like application, where delivey and order is guaranteed. UDP is used in cases where latency is important, than delivery or retransmission. Like in the case of Live Video stream. Even a frame of video is skipped, it still should not go for retransmission and slow down the 'LIVE' effect.
3)Then there is usage of sockets for IPC(Inter process Communication). In that case the domain is AF_UNIX and the type used can be SOCK_SEQPACKET(similar to TCP)
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
Imagine I have Windows TCP socket. And the application connects this socket once on startup. And then sends/receives TCP traffic for long time.
Windows has ability to route IP traffic. Imagine you have multiple network adaptors and you have to set static routing for your application that the traffic goes to a particular NIC.
The question is - will Windows waste CPU cycles to route TCP socket connection only or will it route every IP packet?
I am counting microseconds and I need to know precisely - will be there CPU overhead on sending / receiving the traffic or connection only ?
I assume by "routing" you mean the process of looking at the local routing table to decide where an outgoing packet should be sent. This is decided first by which router to use, and second which interface to use to get to that router.
If you have established a static route, "routing" must still occur for the system to see that route. This consists of a table lookup which takes just a few dozen machine instructions. It is absolutely negligible compared to the cost of copying the packet around.
Keep in mind that binding a socket to a network interface is not the same as entering static rules into the routing table, and that a network interface is not the same as a Network Interface Controller (NIC). This is important when considering overhead, because the effect of binding or routing to a particular network interface, may be that the packet gets copied extra times which will create substantial overhead.
It is possible to contrive a scenario in which a packet is transmitted on the LAN, re-read by the same computer that transmitted it, then transmitted again through a different NIC to the correct router. Most often, the best performance will be had by binding to INADDR_ANY (address 0.0.0.0) and letting the routing tables handle the optimization for you.
Binding to a particular network interface should only be done if you need to ensure that a particular IP address is used for sending and receiving. Static routing to a particular NIC seems unlikely to produce useful results unless the local routing is already broken in some way. Otherwise, interfering with the normal routing process just risks adding to the overhead.
I discovered almost accidentally that my machine was sending and receiving UDP packets to a machine in Poland. Not that I have any problem with Poland, I just don't know why my laptop has the need to communicate with a server there. Reverse DNS shows just the ISP providing the address to some end user. Using Wireshark, I can monitor the messages, which were indecipherable as they were probably encrypted. All packets sent from my machine had the same source port, so clearly the application that sent them opened this UDP socket to use it. I am searching for ways to:
1) enumerate all current sockets open in the system, including the process that created it and, for both TCP and UDP, what ports and addresses they are current bound to.
2) because applications can open these sockets, use them, and close them right away, I would love to find (or perhaps even write) a program that once started would somehow get notification each time a socket gets created, or really more importantly when bound to a source and/or destination address and port. For UDP, I would love to also be able to monitor/keep track of the destination IP addresses and ports that socket has sent messages to.
I don't want to monitor the traffic itself, I have Wireshark if I want to view the traffic. I want to be able to then cross reference to discover what application is generating the packets. I want to know if it is from a process I trust, or if it is something I need to investigate further.
Does anybody know of any applications (for the Windows platform) that can do this? If not, any ideas about a .NET or Windows API that provides this capability, should I want to write it myself?
Edit:
After further research - looks like the APIs to use are GetExtendedUdpTable and GetExtendedTcpTable, CodeProject.com has some samples wrapping these in .NET (see http://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G). So a combination of this API and some sniffer code would be needed to monitor and keep track of what hosts at what ports using what protocol any particular application on your machine is talking to. If I ever get some free time, I'll consider creating this, if you know of an app that does all this, please let me know.
Try SysInternals TCPView. Despite its name, it handles UDP as well.
netstat -b to enumerate all ports along with the process names.
You can try using SysInternals' Process MOnitor (ProcMon.exe or ProcMon64.exe).
It allows for filtering of Processes by "UDP Send" Operation - and provides detailed UDP Connection data, including source and destination addresses(IP) and ports etc.
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).