As background I'm want to be able to, within a capture access:
what is the protocol within the TCP packets, e.g. HTTP? (specifically I'm after filter on web traffic)
what is the Length of the HTTP part
Q1 - Does WinPCap support getting this?
Q2 - If no, any recommendations re how to?
thanks
WinPcap can help you sniff packets.
In order to know the protocol under TCP you can check the TCP ports and assume that if the server's port is one of the standard servers' ports, the standard port's protocol is the protocol under TCP.
In order to see what is the TCP port you need to parse the TCP, IP (probably IPv4) and the link layer (probably Ethernet) in some level.
The length of the entire HTTP part is the total TCP connection payload. Each HTTP connection is build from requests and responses. Each request and response has a specific length but you have to parse the HTTP to figure it's specific length. If you want the entire HTTP length you can calculate the entire TCP payload length by looking at each TCP packet's sequence number and length.
Q1 - Does WinPCap support getting this?
No. Pcap itself does not parse the incoming packets.
Q2 - If no, any recommendations re how to?
You'd better use a third party parsing library such as libnet.
Related
I'm writing a file transfer server, I'm going to use TLS to secure transmission. If I have a hostname for my server and use https then I can use hostname verification, but what if I don't have hostname and connect directly with ip address using socket?
I haven't said what frameworks you're planning to use of any further details about how it will work, but in a small talk way:
The RFC 2616 describes how a http protocol works, which is huge, but it says as part of this that the source ip should be set on the header section, some reversing dns can be made to get the hostname if it's not set as well
Under the hook a http is delivered by a non-persistent tcp socket connection which transfer a data frame between the client and server
TCP socket, now with some background when you open a tcp socket session from client to server you will get just the source/dest ip address and tcp port used, yes, this is the TCP/IP protocol in action, so from this point you will need to implement a kind of application protocol, because the socket is on transfer layer on TCP/IP model and https: technet.microsoft.com/en-gb/library/cc958821.aspx
PS: sorry about the broken link but stack overflow doesn't allow me to post more than 2 links, but I would recommend you to read about the SIO/OSI protocol model as well to understand more how the magic is done to get the internet working, but you got the ideia
So, I would recommend you to use the http with its beautiful TLS stuffs on a nginx server, it will be easier to manage in the future
but if you are just looking for some knowledge of how the stuffs work so go to create your own application layer like http with a header section, data section, file transfer control, send it by chunk and etc...
I want to develop a P2P Gaming application. What is the fastest and efficient way to implement NAT traversal and Peer discovery. I have read about STUN and TURN server. But what are the Open source parts available and how can I use them?.
1. Does those STUN server work on 3G networks?
2. Does UDP HOLE PUNCHING works on 3G networks?
If you have a videogame, you probably want to have a central server that contains all the game data and allow the users to be clients. You know, like Puzzles and Dragons, where you have a username and password and sign in to a server.
Google "Stun Client" and "ICE protocol". There are plenty of open source implementations
STUN fails on mobile networks because mobile networks have symmetric, large scale NAT. Traversing that kind of nat doesn't work with STUN (see reason below)
Why Mobile Broadband NAT cannot be bypassed?
It boils down to statistics. In order for a connection to be established, you have to send a packet into the port that they are at and they have to send a packet into the port that you are at. If you send to the wrong port number or they send to the wrong port number, you miss and no connection is established. If both of you simultaneously bind to a port and send out a packet directed at the other's ip address, you have a 1 in 65535 (65535 being the number of port on an ip address) chance of sending a packet into their port and they have a roughly 1 in 65535 chance of sending a packet into your port. So the chance of you establishing a connection is (1/65535) * (1/65535), or (1 / 65535^2).
You can't know your port number for any subsequent connection because for every new outbound connection, the router randomly gives you a new port number on the interval between 1024 and 65535. So if you ask a server what you ip and port number is, it may tell you the right ip (your ip address doesn't change very often unless you turn off your phone or something like that), but the port number will change. If you try to guess the port number there is a ( (65535-1024-1) / (65535-1024) ), or 99.998% change of you guessing it wrong, assuming that the number of possible port numbers to choose from is (65535-1024).
So unless the port numbers are predictable (which in many 4G networks they are not), you're hosed - no chance.
Your best bet is to use stun and not support evil routers.
I'm sniffing between two devices which communicate in a duplex fashion via udp. I'm using wireshark to sniff. The config file for the first device (a piece of hardware under test) states that the client port is 54718 and the server is 54717. In the config file for the second device (a simulator written years ago), only one port is specified. That of 54718.
The two devices communicate without any problems.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
In wireshark I can see that the first device is sending to the second device such that the source port is 54717 and the destination is 54718. I can also see that the second device is sending to the first device such that the source port is 54718 and the destination is 54717.
The first device sends first and the protocol is described as that of UDP in Wireshark. The simulator replies, also via UDP. Subsequent exchanges are described as being STUN ChannelData TURN Messages. I've no knowledge of this protocol but maybe it explains why I don't see 54717 in the simulators config file.
Thanks for your help,
Barry
First, in UDP communication, there is no "connect" action. UDP is not connection-oriented.
Second, the second device will get the peer address and port from recvfrom() api call.
In all probability, the first device's use of the terminology "client port" and "server port" do not refer to two different ports within the client device. Instead, the "client port" refers to the port to be used as the point of origin within the first device, and the "server port" refers to the remote destination port on the far device, to which the first device's outgoing traffic will be sent.
The second device, on the other hand, is probably fundamentally a "listening" device. It only knows the UDP port it needs to listen on, and waits for any queries destined to that port to arrive from anywhere.
So, I will refer to the "first device" as the client, and the "second device" as the server.
Each datagram sent from the client to the server contains two sets of address information:
1) The destination IP address and port, and
2) The return IP address and port.
The server can use recvfrom() to extract the complete return address (including port number) from each incoming request.
This way, we really only need one port number to be predfined and agreed upon by both the server and the client ahead of time: The server's port number.
The client could conceivably choose to use any random port number as its origin port (but by convention it would likely choose to avoid any of the well-known reserved ports to avoid potential interoperability problems), and the server could dynamically read the return address information from each incoming request and send its responses to the correct destination dynamically.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
UDP is connectionless, and your program likely gets the 54717 as a default fallback value if nothing else is specified (e.g. in a config file).
I am working on a C++ server/.NET client applications couple in which my server (which runs the c++ on linux) broadcasts a message to show it's alive to the whole network and my .NET program listens for packets and parses to get the uptime of the server.
As I have read, to send a regular UDP broadcast to the broadcast address, I simply have to send a packet to 192.168.0.255 (in my case 192.168.2.255) or 255.255.255.255. Is this right? Can I use the same port address? Are there any other necessities?
I understand the fact that if my .NET program listens on that particular address it is possible to receive packets from other applications than my C++ server program. Is there any method of "signing" the packet on the C++ server-side in order for my .NET program to read the header of the packet and see that it is (almost) the one I am looking for?
Regardless of the language you are using, here is my answer:
Regarding the broadcast IP addresses, both addresses are broadcast addresses but the limited broadcast address (which is 255.255.255.255) won't be forwarded by routers. It is better to use the subnet-directed broadcast address (192.168.2.255).
In order to send/receive a broadcast address, you need to define your broadcast address (broadcast IP address and port number). For example: 192.168.2.255 and port number 3000. The client applications (the senders) MUST enable SO_BROADCAST socket option as follows:
int enabled = 1;
setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &enabled, sizeof(enabled));
where sockfd is the socket descriptor.
The server application will listen on a specific port number (port 3000). Normally, the server will respond to each request using unicast message.
There will be no conflict as long as no application is listening on the same port number. Your server will not run if another application is listening on the same port unless you enabled SO_REUSEADDRESS socket option. However, if there is a conflict, then your signiture is depending on your protocol (message format). So, check the message format and reject the message if it does not follow the message format defined by your application protocol.
For client applications, the received packet is unicast (unless you have another design). So, no conflict at this side.
You also have to enable the SO_BROADCAST socket option in C++ to send broadcast traffic, or you'll get a permission denied error:
int broadcastPermission = 1;
setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, (void*)&broadcastPermission, sizeof(broadcastPermission))
If your .NET program listens for broadcast traffic, it will receive any and all broadcast traffic on the network sent on that port, including traffic not sent by your server. You could put a "marker" in the payload of the broadcast messages sent by your server. This way, your .NET program could distinguish which ones it cares about.
Beyond that, I would recommend using multicast instead of broadcast. Broadcast traffic is usually restricted to hosts on the same subnet. In layman's terms, if you have a router in your network, a host on side A of the router will not see broadcast traffic sent by a host on side B (and vice versa) because the router "blocks" it. Routers will almost always forward multicast traffic if a host has joined the multicast group.
I want to write a simple SMPP Server that basically forwards traffic to another SMPP server (C#, PHP). What are the things I need to know? How do I proceed?
With regards to Goran's comment, one possible solution would be a simple tcp proxy such as simpleproxy.
From the Ubuntu package description:
simpleproxy acts as a simple TCP proxy. It opens a listening socket on
the local machine and forwards any connection to a remote host. It can be
run as a daemon or through inetd.
Olaseni,
I've done something similar in the past, but i used perl. What i did was taking a port forwarding proxy which i downloaded from accordata.com. (port-proxy.pl)
I modified this to use the NET::SMPP module to validate PDU's when reading the incoming socket. Once the PDU was of type "Bind_request" i would validate against a dbase, replace credentials if validation was successfull and than forward or if credentials were not validated, issue a reject to the client and disconnect. Alternatively if the PDU contained anything else, i would forward using the logic that was already existing in port-proxy.pl.
You can write simple smpp lib and forward smpp traffic from many applications to the one smpp connection to the sms provider
I can advice you jsmpp lib, but it's for java. It's very simple and cool lib. Many low level things happen behind the scenes and you can focus on your business logic
Find more here
I have written exactly what you are asking for in vb.net
What i did was listen for inbound PDU (connect, bind, sms, and disconnect too) identifying each inbound connection uniquely - for the authentication bit,
then i forward the traffic onward to the delivery smsc.
Your SMPP service simply needs to listen for inbound PDU packets... as well as send heartbeat packets to the connected clients, if required.