Quick story.
I used to hammer minecraft but OD'ed on it a little and took a break. Last time I played it I had the computercraft mod but wireless modems were kind of a new thing. I recently saw a youtube video featuring computercraft though and wanted to come back and play with it. Wired modems are awesome is all I can say :D/> Anyway, was playing about a bit and wanted to have some wireless devices and wired devices running on the same network and have given it a quick blast.

Introducing CCBridge.

This is an application I wrote where you take a computer and 2 modems (wired or wireless, although see limitations below) and it simply repeats the messages on one modem on the other and vice versa. No "scrambling" of the message occurs with the exception of the distance parameter so most software continues to function flawlessly without detecting the hop between networks.
It only bridges certain modem channels (defaults are 0-15 and 65535 which is the one rednet.broadcast uses) which to some may be a limitation, but does also allow for the bridge to act as a firewall on wired networks only allowing certain devices to communicate onto an external network (which could then be wireless based). It also allows turtles to communicate with your wired networks in a totally transparent manner or can be used as a wireless range extender (with care, take 2 bridge devices and connect them by network cable, have them bridge onto separate wireless modems outside of each others range).

Instructions
Install the application with:
pastebin run LAhaYUvb
Alternately you may visit http://pastebin.com/c4CwytVz to retrieve the application itself and then create a ports.cfg text file in the same directory you place the application.

A sample config file is installed by the script above but for those without the HTTP API can be viewed here: http://pastebin.com/DpCGutTs Simply add the channel number for each channel you wish to add to the file on a new line. By default channels 0 through to 15 are bridged as is 65535 for the purposes of rednet.broadcast.

Once the application is installed on one machine confirm that it has 2 modems attached. These 2 modems must be placed on the left and right sides, currently other sides are not supported (planned). It is recommended that only 1 of the 2 modems be wireless (my system does not involve routing in particular, there are plenty of other libraries which could indeed run atop my system which allow for routing).

To start the bridge simply run:
CCBridge

Limitations
There are things which my system cannot do.

Firstly, modems can only have 128 channels open at a time. I doubt anyone will need that many open, but as a result I can only forward 128 channels between 2 networks at a time. By default it forwards 17 channels. If you do need to forward lets say 256 channels then you will need to set up 2 bridge devices between the networks, one set to bridge channels 0-127 and the other 128 to 255 (or whatever your requirements actually are), as they are bridging different channels they will not interfere with each other.

Secondly is the reply parameter for modem messages and also the sender ID for received rednet events (namely who it came from). Lets say I am only bridging channel 5 yet on one side of the bridge I have a computer of ID 5 and the other side a computer of ID 6. If I do rednet.send(6,"hello") from computer 5 then 6 will never receive the message, rednet sends to computer 6 are actually modem transmits on channel 6 which isn't being bridged. 6 will be able to send to 6 via rednet though. Both systems can do a modem transmit on channel 5. However lets say 6 does do modem.transmit to 5 with reply set as 6, if the application on computer 5 tries to reply to the received message on that channel then computer 6 will not receive and the communication will be 1 way. I am considering adding a config option which detects the reply channel and opens it for a preset timeout to allow replies to come through but its something to watch out for if you have communication problems in certain software.

Message duplication isn't something I handle at all and leaves you with a problem on either of these 2 configurations below.


Lets take the wireless scenario, label 1 modem as being modem A and the other as modem B. Modem A receives a message, modem B then broadcasts this message where A then picks it up again where B rebroadcasts it again and A picks it up again etc etc, at the same time B picks it up and A rebroadcasts. I havent tested for this scenario because its beyond the scope of what I am trying to do, there are other projects to resolve that issue. My proposition is that you just don't do it. The same scenario applies to linking wired networks with another cable. Link 2 seperate wired networks, link a wired network and a wireless network. DO NOT LINK 2 WIRELESS NETWORKS OR A WIRED NETWORK WITH ITSELF.

As the message is essentially being rebroadcast the distance parameter you receive from os.pullEvent will be the distance to the bridge device not to the original sender. Very very few software seems to use this besides the GPS API. GPS between normal wireless devices should be absolutely fine, but obviously it won't work from the other side of the bridge.

Final limitation and its probably the one that will come up the most often except for self bridging is with peripherals. Network attached peripherals on the other side of the bridge from you will not be detected, they do not use the modem API as far as I can tell so cannot be bridged. Peripherals which are on your side of the bridge continue to function perfectly for wired networks.

Planned for future releases

Optional automatic opening of reply channels with specified timeouts.
Support for varied modem locations.
Optional logging to file.