Is there a command or configuration setting that will put a WRT54G/S/L, Ubiquiti RocketM2, BulletM2 or Nanostation into a "test mode" that emits a steady signal in order to measure the power output?  I am putting a new Rig Expert IT-24 Universal Tester through hoops in order to write a review to submit here but the output of all the nodes I have are transmitting/receiving so fast, it's hard to lock on to a single "carrier", so to speak, for a reading.  Thanks for any help/guidance.

Boyd Prestwood, K5YKG Near Houston, TX

[Posted wit Post A Reply, this time; as opposed to Quick Response] [Cut/Past no longer works for me, which make typing much slower]

Hi Conrad (KG6JEI),

I'm pretty sure that Node-S is a Bullet; and at the time of the test, it may have been using a 24 dBi directional (screen-dish type) antenna.  I'll have to check with its owner to be sure about the antenna, as it is not my node, and he was making configuration changes a couple days prior to our test.

LQ values weren't constant or even very stable; but were typically in the 63-100% range at the times that I noted them in this test sequence.  Node-S indicated Node-850 at 100%, with Remote Node-101 ETX=3.12 and Node-851 ETX=2.97.  One of the captures I have for Node-850 shows Node-101 at LQ=82%, Node-851 at LQ=68% (even though they were next to each other), and Node-S at LQ=63%.  Other evidence seemed to indicate that the two bullet nodes may have been de-sensing each other a little (e.g., numbers improved when I moved them farther apart, and when I turned off one of them). 

Thank-you for the extra information, I'll try to capture more statuses the next time I test there.  Hopefully that will paint a more complete picture.

Is there any document to tell us how to read the OLSR status screens, and how to interpret ETX and LQ information?  There is so much information on the Web-site I haven't found it yet.

I was unaware that I could telnet to the other nodes, thus far, I have only been selecting the other nodes via the Mesh Status, then traversing their menus.  Is that functionally the same?

Thanks again for the info.  Next time I go up to test, I'll try to get more screen captures.

de Vern (W6NCT)

Just posting this in case it helps anyone...

Picked up a WRT54GS V1 this morning.  It was in unknown shape when I got it (it lit up, but wouldn't give me an IP address).  I decided to hard reset it, but afterwards when I plugged in the power the lights would flash one time and it was dead.  After trying everything I could think of I inspected the power cord, and it was 12v 800ma (non-linksys).  After plugging in a proper power source it booted right up (odd that it was working, lights flashing and all, before the reset...)

It looked like it had default firmware so I tried installing the mesh firmware, but it wouldn't take.  Tried resetting it again, rebooting, no go.  Finally did the 30/30/30 reset and the firmware update WORKED!  I'm up and running now.

So, my new procedure for setting up nodes (I have 3 routers on the way) will be to inspect the power supply, do a 30/30/30, and then install the firmware.

73,

-Tyler

k7fru

Glad to see you got it to work!  Other switches I have had good luck with is the Netgear GS108E (8 port) or the GS105E (5 port)

Clint, AE5CA

I finally got the VLAN stuff setup and working properly using the D-Link switch I linked in my previous post.

For anyone that's having issues or wishes to duplicate my settings, once I assigned the switch a static IP address to use the management console from, I setup the 802.1q VLAN settings as follows.  Port 1 on the switch is the uplink port to my Internet gateway.  Port 2 on the switch goes to the Rocket.  Ports 3-8 are not currently used but will pull an IP address from the Rocket via DHCP (so they're effectively on the HSMM node's LAN) when connected.

In the management console, I created a new VLAN with an ID number of 10 since 1 is reserved for BBHN-WAN. I also created a VLAN with ID 2 but I am not currently using it since I do not have more than one node.

The VLANs are assigned as follows:

• VID 1 (BBHN-WAN)
• Untagged: port 1
• Tagged: port 2
• VID 2 (BBHN-D2D)
• Not used in my implementation
• VID 10 (BBHN-LAN)
• Untagged: ports 2-8

Here's a screenshot of the switch's VLAN management settings. Click here for the full-size version.

I set the node up to have NAT on the LAN side (with DHCP enabled) and a static IP on the WAN side.  The LAN side of the node is on a different subnet from the rest of my network. It's also separated by a firewall from the main portion of my network (the 254 subnet).

Here's my network topology:

Now all I need is a node within range to connect to and I'll be good to go.

What sort of hardware is Node S?  Without that we are just taking shots in the dark.

"Node-850's Mesh Status indicated Current Neighbors to be Node-101, Node-851, and Node-S; but No Remote Nodes. I was under the impression.... was under the impression that this meant that Node-850 could talk (directly and bi-directionally)" This does not necessarily mean the connection is bi directional., just that Node-850 can see packets from Node-S. 

Ubiquiti hardware has a better receiver, it is very possible that even without any noise from wifi devices that Node-850 can see Node-S's beacons even if it can't establish a bidirectional iink,  This would show up as having an LQ value in the Mesh Status screen, you would need to look at the OLSR Status to see if its bi directional or not.

"but could communicate indirectly (yet bi-directionally) to Node-101 and Node-851 (i.e., via Node-850). Correct?"  Generally true, of course its possible contact may not be possible if a link in the path is overloaded, or a high ETX path.  An single hop ETX of 2.0 means a 50% chance the packet won't make it . A ETX of 4 is up to 75% chance of loss on round trip.  LQ can be high in one direction and very low in another direction. (one way UDP streams wouldn't have an issue with this for example)

" To test the connection status ambiguity, we powered OFF Node-850; everything else remained the same, physically and operationally. After a delay, we got the following... --- Node-S's Mesh Status indicated NO Current Neighbors and NO Remote Nodes. I was under the impression that this meant that Node-S couldn't really talk (directly and bi-directionally) to either Node-101 or Node-851"

This makes sense if its a VERY low connection (very low LQ -- You don't specify ) which your getting a lot of feed from node 850, and just enough from Node S to know its there. There is some level of bidirectional required for everything to exchange correctly at the low levels  (olsr secure attack prevention code) to get name data, and to exchange some keys. It may be that the traffic is going via 850 for the majority and were just seeing the beacons and able to correctly decode them with the additional data provided via 850.

An output of telnet localnode 2006  and a copy of your olsr status all page may provide some additional details rather than us taking guesses.

"I don't quite understand why Node-S' Mesh Status included itself as a Current Neighbor (?); perhaps you can explain that (i.e., separate from the primary issue/concerns below)."

I didn't see that in your initial inquiry , the output of the above data would also help on this one as well to see what is going on.

This sounds a like its not related to the OP's question if you have a good stable link through the mesh but not outside the mesh.

The fact you can ping one IP address on the remote node seems to say you have a good mesh connection and the issue is local on that side (unless you have a traceroute that shows different)

Relying on the fact that your the only 0.0.0.0/0 route to publish services is a VERY bad idea. As soon as any other user comes on the mesh and publishes a GW you can no longer be sure they will be able to reach your network.  You should add any services you want to publish into your actual network (either NAT mode with redirects OR  as hosts on a direct subnet) 

After that I can understand the filtering, just make sure everyone knows what filters are in place (and be ready to justify them to locals should one of them put up an open gateway --- remember your node will be the preferred gateway for those closer and you can disrupt others traffic) I would personaly suggest looking into transparent proxying and other methods to provide active feedback so users know what is happening and not just blocking.

As for "next hop" router that will not be likely to be put into the code by official builds. The whole point of the check is to be sure a user really does have a route to the internet as whole.  This is what the 0.0.0.0/0 route means "I can get to the internet"

As a WAN link your router shouldn't need a link back because the mesh node should be in NAT mode so not really sure that is needed (Unless your trying this in NAT mode in which case it makes sense as we don't nat the source from MESH to LAN)

Routing Tables in use on a mesh node at this time: (see ip rules  for more details in how each is configured for packet passing)

255 - Local
254 - Main
253 - Default
029 - Mesh Local Network
030 - Table of Mesh Nodes
031 - Wan GW's

OLSR keeps track of all routes to the internet.  Only one route can be active at any time, routing tables do not keep track of packet loss so this concern isn't really a big deal as the mesh node will change the route based on ETX for you when the route is recalculated.

Convergence - This may not be as bad as you think, yes it can take time to propagate, but the main thing is as long as the nodes closest to the GW figure it out  they can re-route the packet mid route.

Yes loss can still occur while network converges depending on the layout. But it may not be as bad as having to go all the way across to the other side of the network (depending upon layout) in some layouts  only a single node would need to learn about the change, in other layouts  a max of 50% would need to find out about it (A long string path of A-B-C-D-E-etc C could be the stall point)

If you first click POST REPLY it opens an editor window which more formatting features... and it's WYSIWYG with a preview feature.

Andre, K6AH

I agree there has to be access to the internet for ICMP to create the default route on the mesh. That is something I hope that can be changed to the next hope router ip on the local network. The mesh network is not something that I may want to have internet access but access to the local network and or limited ports to the internet.

The behavior is interesting. from the furthest mesh node I can ping the IP of the WAN interface but not the router 192.168.20.254 that is part of the same network. Yes on the router I have ip route back to the mesh network. The pings to 20.254 come up and go down on what appears to be a regular schedule. My internet connection is not that bad.

I prefer EIGRP myself.  OLSR is an interesting concept. however it appears that it doesn't keep a table of backup routes to help mitigate packet loss. The time to reconvergence  of new routes and updating the table appears to have a problem that grows exponentially as you add more nodes to the network.

We can talk tables. I dont want to get into a conflict here. Only trying to figure out what is going on. and hopefully find some clues to help fix the problem.

Greetings from Iceland!

You really should not be having this much trouble. The fact that your Ethernet port drops connection when you turn off the router tells me that you very well might still have DHCP enabled on your computer. Please check and make sure that you have set a static IP address of 192.168.1.x (where x can be anything in the appropriate IP allocation range except for 1) and a subnet mask of 255.255.255.0.

Here is what I would do...Unplug your Linksys device, plug in the Ethernet cable between your computer and the device, set a static IP address in the same subnet, get everything setup with the TFTP programme, apply power and start the upload.

If pings to the internet fail the 0.0.0.0/0 route will be removed.

also the route had to exist if you can pig it.  You likely are not looking at ALL the routing tables. Linux computers have multiple tables.

I ran some tests today on my mesh. The first test was with 4 nodes up. All nodes are running the latest  version of code and all are Ubiquity Nano-Stations and Nano-Bridges.

I was able to ping from one end of the mesh to the other just fine. Then I ping the mesh gateway and I I was successful for about 30 second and then I would get a message that the network was unreachable. My internal network is 192.168.20.0/24 the mesh gateway address is 192.168.20.1 the default gateway on the internal network is 192.168.20.254.

From across the mesh network I could ping everything on the mesh including 192.168.20.1 however at time 192.168.20.254 was not reachable and I would also get a message stating the network wasn't reachable and not in the routing table. A telnet session into the mesh gateway revealed 0.0.0.0 to the gateway of 192.168.20.254 . When I telnet into the station I was connected to there was no 192.168.20.0 or 0.0.0.0 in the route statement on that mesh.

A continuous ping showed the 192.168.20.254 was there , wasn't and then the network was no in the routing. Then it would reappear about 1 - 2 minutes later but only for about 10 - 20 seconds.

 I to a trip to the remote end at lunch time and looked at the router and gateway to verify everything looked good. The permit ICMP any any  in the router ACL seem to take care of keeping the 0.0.0.0 route in place. However I really thing that an ICMP of the next hop router off of the mesh gateway would be ideal for the people that want to isolate the mesh from the internet and still connect up to the local LAN.

I took the two extra nodes out of the equation and ran a point to point test. I had the same results. up and down. I had more success with the two nodes over the 4 nodes. I could maintain a telnet session with a router at the far end and when the mesh went down and came backup I still had my same telnet session.

An Ethernet switch might help here. Plug your computer into the switch. Then connect the node to the switch. 

The switch will keep your computer port alive when you power cycle the switch. 

The instuctions Paul sent you has a script for doing the tftp from a Linux computer. That can make it easier as well. Start the script and keep power cycling the node until it takes. 

Sorry you have had this much trouble getting this node up and running. 

Clint, AE5CA

HI ,

I have a 2.4 and a 5.8 node up at 200 feet in the central west end of Spotsylvania Count. two other matching nodes at my qTH

Mike AE4ML