Using lo interface for testing

[kk_davey]

Hi - I'm a new Linux gal fighting with my computer on a daily basis

I've installed a kernel module that was written to enhance the TCP protocol for wireless networks by calculating network congestion at a wireless access point and passing this value on to the receiver.

To implement this enhancement I install a module at the router, and another at the receiver. I'd like to be able to test this on a stand alone computer, which I assume I use the lo interface for. Can my stand alone computer simulate a TCP connection using lo, meaning it would have to act as the sender, the router, and the receiver?

I.e. can I set up lo to simulate a connection (with limited transmission rate) whereby the packet travels down the protocol stack, to the wireless access point (where the router adds the congestion value to the TCP options), to the receiver, where it travels back up the stack, and the inserted congestion value can be interpreted appropriately.

Is this possible to simulate using lo?

[starfish]

This is not my expertise, but I'd think that to do this you would need each one of your applications / modules on the same server listening on a different TCP port. That way there would be no confusion between each of them and the TCP/IP stack.

I hope you can modify your modules to do this.

[kk_davey]

Thanks for your response.

How would I set your suggestion up (given that the modules use netfilter hooks and a scheduler for the receiver and the router respectively)?

The modules themselves test to see that the packet is TCP and, if so, process them. If they're not TCP then the receiver does nothing, and the scheduler simply schedules the packets (FIFO) without adding a congestion measure.

When you say 'server', my computer is a client (on the university network) so I assume that I can't use my computer for this?

(The problem is that the wireless testbed is a shared resource and I want to be able to test module modifications without having to transfer the code to the testbed every time. I'd like to be able to test that my changes work - in as much as the packets are processed as I'd expect - before I put the code on the testbed and run any real experiments. Do you have any ideas as to how I could achieve this?)

Thanks again.

[starfish]

I'd have the congetion client module communicate with the congestion module on port TCP X and have the congestion module communicate with the application on the remote end of the WAP/router on TCP port Y.

If the client, congestion and WAP modulkes all run on the same box, then using port X and Y will help to prevent the box from getting confused with multiple modules listening on the same TCP port.

When you migrate to the live system, update your code to not check for the TCP port but to just check if the traffic is just TCP regardless of port.

Something like "if server name = myPC, then check for TCP and TCP port else just check if TCP"

Hope this helps.

[kk_davey]

I accidentally submitted this message - please see message below!

[kk_davey]

Thanks again. That sounds like a very useful suggestion.

I didn't realise I had ports TCP X,Y,...How do I use/access these? In my code at the moment I'm doing a protocol check:
if( iph->protocol == IPPROTO_TCP )...

How do I change this to listen to a particular port?

Also, is the above 'if' statement correct? I read somewhere that you can have the protocol set to 0 to ask the kernel to determine which protocol should be used, in which case a TCP packet might fail the condition. Should I be using getprotobyname() instead?

Thanks again,

Katie

[starfish]

Katie,

I'm not the best programmer. This looks like C, or perl checking the Layer 3 information of the IP header.

You'll need to check the Layer 4 TCP header for the particular port.

I searched for "IPPROTO_TCP" and found this example: http://www.cs.princeton.edu/~mhw/raw/api_example.html

It has a part where it uses a layer 4 UDP pointer

udp_header->source = htons(local_port);
udp_header->dest = htons(remote_port);

There should be a TCP equivalent like tcp_header->dest

I hope this helps.

[kk_davey]

Thanks very much for your help. I'll certainly be giving it my Aussie best!