|
|
In this project you will hack on the WRT54GL wireless routers to
create an ethernet bridging service for all applications that locally
broadcast packets on the router's local area network. We will provide
a server that uses a paricular protocol to communicate with your
service running on the router. Any packets that you send to the server
will be sent to all other routers connected to the server. In this
way, application packets sent on the local area network will
be tunnelled across the internet to other routers in the class.
|
|
If you would like to get your router online, the lab in 003D ("Special
Topics Lab" which sits in the back of the Baxter Hardware Lab, and is
protected by cardkey access) is now setup for your use. Please follow
the following instructions to guarantee a pleasant experience for
everyone:
What you need to bring with you to the lab:
- Router with OpenWRT installed
- Blue Ethernet cable, which came with your router
- Router power cord
- Laptop (preferably)
Step 1. Enter the lab using your keycard.
If you have a laptop, and would like to connect to your router via
WiFi do Steps 2-7. If you do NOT have a laptop, do
steps 8-13.
|
|
Step 2. Connect your router to your laptop with the blue
ethernet cord you've brought with you, and power your router.
Step 3. Enable wireless on your router:
$ uci set wireless.wl0.disabled=0
$ uci commit wireless && wifi
Step 4. Modify the /etc/config/wireless file using vi
(see this for
vi help)
$ vi /etc/config/wireless
and change the line that says:
option channel 5
to use a channel value between 1 and 14, that is NOT 5, of your choice.
and change TWO of the lines that say:
option ssidOpenWRT
to use an ssid name of your choice, e.g. IvanWRT.
Save the file and quit vi and do:
$ uci commit wireless && wifi
Your router will now change it channel and use the ssid you specified
(use the "iwconfig" command on the router to verify the router's wl0's
(wireless) interface ssid value).
Step 5. Unplug your router and bring it to the corner of the
lab labeled with a sign on the whiteboard as "The switch is Here"
(please do not erase this :)
Step 6. Plug one end of the blue ethernet cable into the switch
on the table -- using any of its free ports. Plug the other end of the
blue ethernet cable into your router's port labeled as "Internet" (the
one to the left of the 4 ports labeled 1,2,3,4.)
Step 7. Power your router using one of 6 available power
sockets.
You should now have visible on your laptop the network ssid name
you've created on the router and you should be able to connect to the
router using IP 192.168.1.1 as usual. Additionally, the router will
now have access to the internet and your laptop (once you connect to
the router's wireless network) will also have internet connectivity
via the router
|
|
Step 8. Sit yourself in front of one of the following three
computers in the lab (diagram of where these are is on the whiteboard
in the lab): Figaro, Truby, or Ernesto.
Step 9. For Figaro and Truby, plug in the orange ethernet cable
into the "Internet" port on the router. For Ernesto, use the gray
cable. Each machine has this cable somewhere in their vicinity.
Step 10. Plug the blue cable from the computer you're using
into one of the four remaining ports on your router.
Step 11. Power up the computer (if the computer was already
booted, reboot it and make sure the CD drive contains a CD labeled
"Knoppix").
Step 12. Use the computer to do your work (router's IP will be
192.168.1.1 as usual) -- NOTE: these computers run Knoppix -- an
operating system on a "live" CD. This means you should NOT attempt to
save any data locally on the computer -- scp all your files to another
machine, or bring a USB stick.
Step 13. After you are done using the computer. Do a shutdown,
and push the CD tray back in for the next person to use.
|
|
|
In this part of the project you will write an incomplete version of a
tunneling client program which will run on the router. This program
must capture broadcast packets destined to the local subnet broadcast
address. It must then forward these captured IP packets over a TCP
connection to a centralized server.
|
Requirements
|
- Capture IP broadcast packets on your router
- Forward these captured, unmodified, packets over TCP to a server
|
Capturing IP broadcast packets
|
To capture IP broadcast packets you will use pcap. This will be
similar to what you did for Project 2, Step 3. Note that in this step
you will forward IP broadcast packets, not ethernet broadcasts. An IP
broadcast address depends on the address of the host sending the
message, and the subnet mask. To determine the broadcast address, you
take the bit complement of the subnet mask and then perform a bitwise
OR on the result and the IP address of host address.
Once you capture a broadcast packet you will then need to forward it
to the server. This is the second requirement for this step of the
project.
|
Forwarding captured broadcast packets
|
Download, take a look at, and use in your testing proj3_server.c. This file implements a
server which listens on TCP port 8083 and accepts a single
connection. Once a client connects to this server, the server does not
generate any data, and only waits for and prints out messages from the
client that are in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| payload of length packet_len |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where packet_len is an unsigned 32bit integer in network byte
order which specifies the length of the following payload field. The
payload field contains the packet captured by the router. This
packet must include the IP header and the IP payload.
|
Notes
|
|
For step 1 of this project you can get away with not having your
router online. You can do so by running
the server code on the computer you use
to connect to the router, and have the router send the encapsulated
broadcast packets (it would typically forward to attu/bicycle) to the
server running on your computer. However, your code will be tested on
a router with internet connectivity, so for a more realistic grading
setup please connect your router to the internet.
|
Part 1 Due Date
|
|
Part 1 is due at 11:59PM on Friday, November 21, 2008. You should
handin all code that is necessary to compile and run your program on
the router. Do not hand in the server code. All submissions must be
made via catalyst.
|
|
In this (final) part of the project you will augment your tunneling
client from part 1 to additionally receive messages from the tunneling
server, and to re-broadcast these messages on the router's local
network. To test your tunneling, you will write a chat application
(BChat) that uses broadcast packets for communication. You will have
two weeks to complete this part of the project, so we also provide you
with numerous extra credit options in the case that you complete the
requirement early.
Below is a conceptual diagram that illustrates the relationships
between the BChat client, the tunneling client, and the tunneling
server. For this project you are responsible for coding and handing in
the BChat and tunneling clients. The tunneling server, which your
tunneling client will connect to will be provided for you. For a more
detailed illustration of how these three pieces fit together, see the
discussion section slides.
|
Requirements
|
- A tunneling client that interoperates with the tunneling server
and runs on the router.
- A Linux BChat client that interoperates with other BChat clients, and
with tunneling clients on the same network.
- An interface to the BChat client that allows one to send new chat
messages, and to see previously sent chat messages. This could be done
using, for example, raw stdin/stdout, libcurses, or a web
interface.
|
BChat : Broadcast chat application
|
|
The BChat application uses subnet broadcast packets to send and
receive chat messages. All chat messages are sent as payload of subnet
broadcast packets (these are UDP packets), and all participants that
are running BChat will see all messages. Your BChat client must run on
Linux.
|
Tunneling BChat packets
|
|
All BChat messages will be tunneled transparently by the tunneling
client. The tunneling client (from part 1 of the project) will forward
all BChat messages originating from the local network to the tunneling
server. The tunneling client will also re-broadcast packets that it
receives from the tunneling server on the local network.
|
BChat Client protocol
|
BChat clients receive subnet broadcast messages on port 52368, and can
use any port for sending these messages. That is, the UDP destination
port of the message must be set to 52368, but the source port can be
an arbitrary value. The BChat message UDP payload should contain a
string of format: "name: message". This string should not exceed 1024
bytes.
Note that BChat client implement a decentralized chatting service.
This chat service does not need a BChat server because all chat
messages are broadcast to all the other BChat client by the
client that originates the message.
|
Tunneling protocol
|
|
The tunneling client and the tunneling server will send and receive
the same type of messages as defined in Part 1 of this project. These
messages must be transmitted over a TCP connection. The tunneling
server is running on
bicycle.cs.washington.edu, and is listening for new connections
on TCP port 8083.
|
Re-broadcasting strategies
|
Packets received from the tunneling server by the tunneling client
need to be re-broadcast on the local network. You can accomplish this
in at least two ways:
Using a persistent UDP connection (similar to BChat client):
- Open and maintain a UDP connection to the local subnet broadcast
address
- On a new packet from the server, send just the UDP payload of the tunneled packet on the open UDP connection
Using raw sockets:
- Translate src IP to router's IP
- Translate dst IP to local subnet bcast IP
- Send translated IP packet on a raw socket
|
Extra Credit
|
- Use a multicast address instead of subnet broadcast address for
BChat messages
- Use your web-server from Project 2 to snoop, and show a log of all
chat messages in a browser that connects to the router
- Use your web-server to provide a web interface to the BChat client
-- this will involve crafting an html page with a simple form and
parsing GET or POST arguments in an HTTP request generated by the
form
- Following up on extra credit option 2 -- esides snooping (), add a
way to inject chat messages from the web-server on the router thorough
a web-interface. Note that BChat clients on the local subnet have to
see these messages too.
- Create a new application that uses the tunneling protocol in a
novel manner. For example, tunnel BitTorrent's TCP connections, or
connections of other software, such as Apple's iTunes or iChat.
|
Part 2 Due Date
|
| Part 2 is due at 11:59PM on Friday, December 5,
2008. You should hand in all code that is necessary to compile and
run your tunnel client on the WRT54GL router; and to run your BChat
client on Linux. All submissions must be made
via catalyst and include usage instructions.
|
CSE Home 
