hbe02

hi all,
I am about to embark on a projectthat involves creating a program that accepts packets from an interface and outputs them after a certain amount of delay and jitter on another interface. Kind of like a simulation of the internet.

Now so far, I know that when u want to recieve somehting u open a socket on a certain port. Now in my case how should the sockets be different? and how can i retain the destination IP so that i can forward the packet. This should be the same socket operation of a firewall i think.

can anyone suggest any reading material or google keyword or similar project for me to look at.

thanks

Jimbo

What do you mean, be different? A socket is basically an ear on the network. If you want to hear more, you need more sockets. If you're just simming, you could use an extra later of abstraction to break your single socket into a couple virtual sockets.

Are you imitating a firewall or a router? Most routing of packets only have the final destination and the original source of the packet. The steps in the middle use MAC addressing to get around, and only read the IP to figure out whether to turn right or left.

For a firewall, though, you [can] read up a little further into the packet and decide whether to accept it based on other traits, such as port number, source IP address, etc...

With NAT your router keeps a mapping of inner IP addresses to outside facing IP addresses (e.g. you have the 212.13.49.0/24 network, and you remap each one into 192.168.0.0/24). With PAT, your router keeps a mapping of inner IP addresses to outside facing ports (e.g. you have 212.13.49.0/24 and you remap it to 192.168.0.3:80, 192.168.0.3:115, 192.168.0.4:12345, etc...). NAT and PAT are not necessarily firewall functions.

Back when I took Cisco classes in high school, there was a kinda similar thing to simulate a multi-router network, but it was on one computer, no need for sockets. I can't remember the name though

__________________
<insert disclaimer here>
<insert shameless plug for Visual Studio here>

hbe02

does that mean that when programming a firewall or a router, u have to open 65,000 sockets for all the possible ports? because as i recall u need to specify the port a socket is listening to? is that correct?

In terms of networking functionality both. I just want to accept any packet and forward it to its destination. a router forwards on a certain port, a firewall decides whether to forward it or not. im going to be delaying it for a certain period of time, then forward it.

Dameon

No, you definitely wouldn't do this by opening a bunch of sockets.

Promiscuous mode is commonly used for sniffing. Getting the packets is not the hard part in your case. Linking two interfaces together as you want brings in a lot of subtle, lower level stuff.

Thankfully, you probably don't need to worry about it. Bridging interfaces is supported by most any OS you'd care to use. This is in the C# forum but if you intend to put something like this on an actual network - as in, two physical interface cards, one in, one out, handling what ever network traffic happens to pass through, Linux and iptables would be a good choice. It's amazing what you can do with iptables rules. A quick search revealed this solution. Packets incoming on a particular interface are, by an iptables rule, handed off to a usermode program which holds on to them for some defined period. You'd want to bridge two physical interfaces and apply a similar rule to your bridge device. Should work. If you want to test stuff just on the one machine without multiple interfaces, you could also apply the rule to the loopback device (think localhost).

If you really need to do this on windows, things might be much uglier.

Do you really need to delay *all* traffic going through this segment of the network? You say "simulation"...if you plan to use this to test your network applications, why not just implement it as a simple proxy? Your app connects to your delay tool, which then connects to the predefined "real" target and fondles the data as it wishes.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270

hbe02

Its very impressive what you can do under linux. i will definitely keep that in mind for future work. Unfortunately, yes i have to do this under windows. what i want to do is basically simulate WAN delay jitter...etc. I guess doing it through a proxy on the sending PC is a neat idea. But in that case, what about the traffic comming back? how can i delay that too?
what about the ports issue? does this mean i have to specify a port for my proxy to listen on?

what im trying to do should look like this:

SENDER(e.d LIVE UDP VIDEO) ---->>> INTERMEDIATE PROgRAM -------->>>>> RECIEVER

the scope of my work is this intermediate program, which simply captures the data and delays it before it sends it off to its specified location. you can think of the three systems above as 3 different PC's, perhaps on 2 subnets with the Intermediate have 2 ethernet interfaces. unless i go with the proxy idea?

Ooble

Just route the entire damn program through Tor and watch the slowdown begin. No need for fancy programs.

__________________
Me :: You :: Them

hbe02

That would be cool... but this is just brainstorming for a project im supposed to propose and implement myself for a course in multimedia networking..

Dameon

You mentioned UDP video

Start intermediate program
Listen on port 123
Target host: my_remote_server
Target port: 456

Start server
Listen on port: 456

Start client:
Connect to localhost:123

Anything sent to localhost:123 will get delayed by the intermediate program. When the server replies to sender address as is common in UDP, the intermediate program will get it, delay once again, and then send it to the client. This requires just a little bit of logic for the intermediate program. You have to know where the real server is (since there is no proxy protocol like SOCKS involved here, the client doesn't tell you), you have to track what client is sending you stuff (to send replies from the server) and need to make sure that check up on both sockets (can't just block on one of them - the other might get something).

If you are comfortable with threading, this can be easy.

Threads 1 and 2 each handle a socket. They loop until they are supposed to exit, receiving a datagram and adding it to a shared queue. Store with each datagram the time in which it should be sent (current time + latency). In threads 3 and 4, loop such that you check the first item in the queue, send it if at or past the send time, and sleep for 1-2ms. (Not terribly efficient, but much easier. You could improve this for fun). 1 and 3, 2 and 4 are effectively paired, with a queue for each pair. One pair handles the client, the other handles the server.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270

hbe02

Thats a pretty cool formulation, thanks Dameon.
although, your suggestion implies listening/sending/recieving on specified port for which i have to open a socket. I
s there anyway i can make this completely dynamic. i.e no specific ports, listen to any port, recieve any packet, delay it, look at the destination ip and port, then forward it to its destination. kind of like a gateway?

Dameon

If that's what you need to do, investigate what I said about Linux/iptables.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270