On the basis that there is some distance involved ; (an assumption)
My understanding is that some of the cheaper (dlink in particular) wireless gear has 'timing issues' when the A/Ps are physically far apart.
In the extreme, you will have to go to a proprietry fix, viz turbocell, or replace the A/Ps with something a little more tolerant of distance.
802.11 was never intended to travel great distances. Indeed it was part of the 802.11 specification to actually prevent (ha ha) this from happening - the reason for the proprietry RF connectors.
In summary, many standard 802.11 wireless cards will do great distances without getting flaky, but I have heard that the dlink gear is not of that category. Other cards such the Orinoco PC-cards combined with turbocell work very well indeed at distances up to 20km, and provide true data rates in the order of 9MBit/sec (I am told). I don't like the idea of proprietry *anything*, and I wish there was an open-source 'turbocell'.
In answer to your question, I do not think there is a device you can put on the ends of a leaky hose - to make the hose not leak.
sorry. I hope someone else has a different version to tell. 8-(
/steve
Charles Steinkuehler wrote:
I've built an IPSec VPN tunnel over a point-point wireless link using a couple of D-Link DWL-900AP+ boxes and some spare ports on a couple of installed LEAF boxes.
My problem is I'm seeing *LOTS* of packet loss, duplicate packets, mangled packets (especially longer packets typical of downloads and web browsing), and other nastiness making performance across the wireless link virtually unusable, despite a fair amount of bandwidth.
It seems to be fairly well known that TCP doesn't handle the bursty packet loss typical of wireless networks very well, having instead been designed for packet loss typical for congested wired networks (where partly garbled packets are quite rare). I have seen a few proposed mechanisms that operate at layer 3, monitoring the TCP traffic, and "fiddling" with the TCP flow to improve TCP performance (by doing things like requesting re-transmissions of packets that look like they got dropped by the wireless link).
Now for my question: Does anyone know of a linux implementation of anything like the above I could possibly get running on a LEAF box? Since I'm tunneling all traffic through a leaf box on each end, it seems like I could implement something to "transparently" deal with the lossy wireless hop, but since I'm kind of new to the whole wireless thing, I'm not sure what software I'm looking for, or if it even exists.
Of course I'm also looking at what options I have for increasing the fundamental reliability of the wireless link as well, but I'd still like to find something that can "tweak" TCP operation for running over wireless.
Thanks for any pointers,
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
