I get the following message after executing that command

      Firewall rules for tun0 up
      iptables: No chain/target/match by that name
      Adding vtun firewall rules...

I am now able to connect from the client node to the server node but I cannot connect to the other nodes at the servers location.

I cannot physically get to the server location until tomorrow--do I need to issue a similar command on the server node?

It appears the command needs to be reissued after a node reboot.

KE6TIM, It appears that there is an issue on Linksys tunnel nodes.  (Possibly a OpenWRT Kamikaze issue, still researching)

Try this as a temporary fix:

ssh into the the tunnel client node (ssh -P2222 root@nodename)

type the following cmd:

vtun_up tun0 up

Then, try and access the remote nodes.

I just got it setup and am trying to do some testing with K5DLQ and can't get a connection either...

We can't get them connected...  Your setup looks right...  My setup looks right...  There's something simple we are both missing...

I am wondering if it is because I left the DTDlinking OFF after the last upgrade - I can't find the file that describes how to turn DTDlinking back on because it sort of mysteriously disappeared from the net, I keep getting "File not found" when I try to click on any link referencing it.  It makes me wonder if I NEED to turn it back on for it to work.

I am a little unclear as to why it was turned off - probably router looping problems?

I will be watching this thread!

Bill - N5MBM

I have loaded the tunneling software on two GS units.  On both the Server and the Client I can see remote nodes but am unable to connect to them or ping them.  I re-read the instructions and double checked the tunnel set-up screens but I must be missing something or do not understand it--any ideas?

Not sure how well attachments work so here is also a link to an image of my setup

http://www.sonic.net/~howardt/TunnelSetup.pdf

Tim KE6TIM

seems like I get all the strange toys.

page 31 of the manual quote:

To ensure the normal communication of the factory switch, the default VLAN of all ports is set to VLAN 1. VLAN 1 cannot be modified or deleted.

Looks likes I get to buy another toy...

If the switch will not let you set ports of VLAN 1 to tagged there is very little we can do.

The node expects that vlan 1 is the vlan for Internet, trying to change it from the switch side will not work, it sounds like you had correctly configured it if it had been vlan 1 but since it's vlan 2 it will not work the vlan tagging on 1 and 2 is specific and doesn't support remapping.

Honestly this is the first switch I have heard of that does not let you edit the tagging for vlan 1

since I cannot make any changes to VLAN 1, I set up VLAN 2 (I thought) to connect the comast router to the node.

If I delete VLAN 2 there is no way to tag/untag members of VLAN 1 - all ports are untagged by default.

are you saying delete VlAN 2, leave port 3 connected to the node on untagged as VLAN 10 and the Comcast router plugged into port one

From your description your node is not a member of vlan one tagged (the Internet vlan) nor is your router (untagged) VLAN 2 is dtdlink (mesh node to mesh node direct connect only)

Need a class in how to get tun to work with:

COMCAST ISP

NS2 configured as client (3.01) - using TP-LINK TL-SG108E switch

NS5 configured as server (3.01) - using netgear gs108t switch

Configured the netgear via AE5CA.COM/?p=49  the NS5 has internet access as well as localnode.

now the problem child

VLAN 1 on the TP-LINK cannot be modified.

VLAN 1 = PORT 1, 7, 8

VLAN 2 = PORT 2 untagged -- PORT 3 TAGGED - PORT 2 is connected to COMCAST router, PORT 3 is connected to NS2

VLAN 10 = PORTS 3,4,5,6 UNTAGGED -- PORT 3 is connected to the NS2 and PORT 4 is connected to netbook

The netbook has control of NS2, but there is no access to INET.

The NS2 is configured as client and the gateway switch is checked. The NS5 is configured as Server and the gateway switch is checked.

Could use some education on getting the last mile to work...

73 de mike

The calibration data is stored on a part of the 8mb flash eeprom (around 64KB in size) which we never overwrite.

The Ham Bands do not always overlap the worldwide channel specs (For example HAM bands go well below on 2.4GHz and well above on 5.8GHz and in the case of 3GHz with the down converter the majority of the channels lie between the normal channels)   Are there specific channels that are Ham Band that you are thinking of that are in the global channel field?  I would guess you are thinking of a few 5.8GHz channels that are below the current channels that are actually in the USA band plan (but not supported officially by the USA model hardware by Ubiquiti due to legal certification needs) that partially overlaps the highly used US Government Radar band (FCC NAL letters go out often for against anyone in that frequency range with wifi that do not have DFS [we don't and we are not required to but we are required to not interfere] )  The main thing to stop those channels would be the lack of International model hardware board.info files as we would expect those devices to have the CAL data in them for sure. (Think we only have a Rocket board.info in XM series)

This is probably the best explanation I have read on the calibration topic:

http://villagetelco.org/2009/11/rf-hacking/

Each AR2317 chip is a little different and consequently each chips requires individual RF calibration on the production line. This calibration ensures each AR2317 product has uniform transmit power and meets certain performance criteria. The calibration data is stored at the end of the SPI flash chip and loaded by the WiFi driver at boot time. Calibration is performed on the production line using a bunch of expensive RF test equipment connected via GPIB to a host computer running special software. The calibration procedure and most of the data relating to the AR2317 RF section is part of the Atheros “secret sauce”.....

I have a modified version of hamchat I sent to Bill. The major changes were to insert a message each time someone joins the chat, and a timestamp on each message. I also fixed a bug in the HTML page declaration and adjusted the styles a bit to make better use of the page space.

I can share the revised source or the diffs if there is interest.

Thanks to some help from Richard WB6TAE, I got HamChat working! 

http://n5mbm.net:8084/cgi-bin/hamchat

I have the tunneling setup and I will be installing the "other router" at W5TZ's place tomorrow hopefully - I have my fingers crossed everything works like it should!

Bill - N5MBM

Try this Bill:

Link to Hamchat zipfile

It's a little bit of manual work.  It's not mine but I could make an .ipk file for it and that would negate all the file/directory creation.

Have phun!

I have setup a couple of Linksys routers to tunnel a connection across the county...

Does dtd linking need to be turned on?  They don't see each other...

Every place I see someone refer to a webpage that tells you how to enable dtd linking it comes back as "Server Not Found"

Anyone have any idea here?

Bill - N5MBM

I can understand the reasoning for a clean install on a major version upgrade. However, if you want to encourage people to test the beta releases, then this could be a show stopper. If there were just one directory in the file system that would remain untouched, like maybe /var/local, then I could either add that to the search path in scripts, or symlink to it.

It would, of course, have to be made well known that programs and files stored under /var/local might not operate properly after a firmware upgrade. I suspect that those user who would take advantage of such a feature would be those more likely to understand how to use it.

I think the disastrous incompatibility argument is also sort of moot. What difference does it make if I store my data, code, etc. on the node or transfer it to the node after the upgrade.  The incompatibility issue remains the same, regardless of where the files are stored.

I've read the document that k6ah shared with us. It is certainly a fascinating read showing various types of throughput behaviour on meshed networks.

However, as stated in the document, the experiments performed did not consider OLSR, which is the routing protocol that is maximising throughput on ham broadband. Also, since 2009, it is safe to presume that several enhancements have been made since then to the wireless equipment itself.

But as said, it is an excellent read and experimentation done by North Carolina state university.

For multi user VOIP and hd cams to work continously in an emergency setup, we need more data bandwidth.... or more and more nodes. Is our logic correct?

We also experimented with different polarisations and directionality. So far, the results fly in the face of traditional radio where it seems that we are working faster with omni-directoonal than with directional antennas.

As noted the port is not enabled and will not pass any traffic.