The boards are both running in ad-hoc mode (5GHz, Outdoor band) with no special configurations made. They both use the dd-wrt v24 (svn 9517) firmware.
I encounter the following problems:
1. The connection between LAPTOP1 and LAPTOP2 isn't stable. Sometimes the link between a LAPTOP and "his" BOARD goes down. (Or even the whole board deactivates itself? I'm not sure.) I then can get the Ethernet-link up again if I shutdown the wifi0 Interface of the other BOARD. When I sniff what's going on on the Ethernet-link that goes down i see strange gratuitous ARP packets coming from the BOARD that went down, announcing the IP address 192.168.3.2 (!). This is kind of strange because I never entered this address anywhere. Could the breaking up of the connection result from a IP address conflict happening on the 802.11a link? I had the impression that the connection runs more stable if I shutdown the br0:0 interface. What is it actually used for?
2. When I somehow get the connection running, the performance (measured with iperf) between LAPTOP1 and LAPTOP2 is very poor (less than 1 Mbit/s). This also happens when testing the connection between a LAPTOP and the remote BOARD. The performance is fine when testing the connection between a LAPTOP and his local BOARD. Interestingly it's also fine when testing the connection between the two BOARDS. Again in short:
LAPTOP1-BOARD1-BOARD2-LAPTOP2: bad
LAPTOP1-BOARD1-BOARD2: bad
LAPTOP1-BOARD1: fine
BOARD1-BOARD2: fine
While sniffing the connection I noticed warnings concerning a full tcp window. The performance problems happen only in ad-hoc mode. So I guess the tcp window wasn't full in other modes. Can you give me some advice what I can do about this issue?
What I (actually we) try to do, is to set up a protoype for a system where railway waggons should be able to connect to each other, building a large network over a whole train. The waggons should be able to interconnect without prior knowledge of their peer. Especially, it should be possible to insert waggons the other way round without reconfiguring anything. Because of this, a system with uneven peers (AP<->client, WDS-AP<->WDS-Station) didn't seem feasible. (Radio links are planned to span just to the next waggon, i.e. only about 2m.) The whole thing is being done for a semester thesis. And yes, we also thought using a cable would save much of the trouble. :wink:
Would upgrading to a newer version fix one or more of the mentioned issues?