The date has been changed to 18 October 2014 because of SET weekend. Please RSVP via https://www.eventbrite.com/e/gota-2-mesh-prince-georges-aresraces-training-update-tickets-8342626019

Ok, that does not appear to be OLSR restart related as OLSR doesn't control the local LAN interface.

I would more suspect it to be a bad cable usually.

I haven't seen OLSR watchdog make the network interface unreachable, and it shouldn't   All it does is write to a file (in ram) every 5 seconds to say "I'm still alive as of  the current time" and then another script reads the file to be sure it isn't dead. Unless some crazy something is happening in the watchdog script or the watchdog module causing excessive CPU usage to cause the node to dump data (top on the node itself)   but even that would be rare as a IP/ECHO is handled low in the kernel, out of user space, its the least likely to be affected.

ipkg was discontinued years ago by upstream (OpenWRT)

Since the Ubiquiti builds are built on recent versions of OpenWRT (12.09 released in 2014 for 1.1.x builds)  it will use opkg instead of ipkg.

ipkg is still used by Linksys builds (based on OpenWRT 7.09 released in 2009)

Here's a newbie problem on UBNT FW1.1.2.  Trying to install asterisk and get this:

-ash: ipkg: not found

Googling it points to the Optware package as MIA.  Looking at my UBNT's root I don't see a directory for opt.

Can someone point me in the right direction?  Thanks for the help

I will try to aim my node your direction as soon as I get my firmware updated. Everyone else in the bay area is going to need to update firmware as well so we can all stay compatible. Also make sure you add your node to the map: http://www.broadband-hamnet.org/googlemapped-mesh-nodes.html

Thanks for the explanation of the update protocol. We use a similar methodology in our work, makes sense. I have seen some strange degradation to the point I can barely get into my Rocket now. Maybe I should re-flash. Looks broke now. See ping loop screenshot attachment below.

Bob AF5RS

Attachments
 PingLoop-20140818B-AfterStorm.JPG [94 KB] ::

4-5 seconds sounds too quck for an OLSR restart.  Should take on the order of 30-90+ seconds average to re establish links on a reboot by my estimates to reestablish routing.

If your OLSR is rebooting you should see an incrementing OLSR restart count on your status screen. If that is the case then yes the watchdog is triggering and keeping the node online. A watchdog however is just a "patch" it's not a fix to the ultimate issue.

As for "closed without a release" this is normal for our dev cycle. When an issue has been "fixed" it is closed out to get it out of the developer queue so that way only "unfixed" issues show up (since I'm the only person working tickets this is very important to keeping track of what is going on. Fixed simply means it's been commited to the DEVELOPMENT branch and that it is belived to be working and is ready to go through further testing.  If a bug exists in any implementation (or combined implementation) it shows up in beta (and yes sometimes 2-3 patches interact on ways not seen independently )

It should also be noted I commited the patch VERY close to leaveing the country for work. Very hard to build beta builds while I'm nowhere near my gear, and that I've just returned back to the gear.

Eventually I hope to see the lab servers build untested "development" releases and publish builds automatically, but if I work on that than other bigger issues like OLSRD crashing (which is a much bigger issue) would have to go unworked on.

If anyone wants to step up and devote the resources to debugging (20 node lab environment looks to be the sweet spot right now) help is always welcomed.  

To to give an idea of what it takes to build an official release currently.

1) An intenrnal to me only build gets run. (This takes 15 minutes by itself to do each time by the way)

2) The build is tested in my lab (this can take a couple hours EASILY and the test list gets longer each time)

3) Any issues found in step 2 are resolved and steps 1-3 are repeated.

4) Once I find all the issues I can it gets releases to the BETA test team to double chexk me (step 1 gets ran again as a beta build this time).  Any issues they find are resolved (this takes a lot of time, each person has to dedicate hours to testing). and we start at step 1 again to be sure we are good if they find a bug.

5) only after it's been vetted does a public release get made (again another 15 minutes).  I should mention the above is just the Ubiquti procedure, Linksus requires me to run the steps again for building images.

This obviously doesn't catch every  issue. Some times we can't see issues till networks get bigger. (This issue for exmaple seems

to show up because now 3-5 nodes at a site is becoming the norm when before 1 node was the norm. We have increased traffic to a point where deep bugs are more likely to happen and we find the flaws now to continue growth.

All this keeping in mind I can work anywhere from 40-80 hours in week depending upon how the week goes, that I'm the Repeater Technical Chair and active board for my local club,that I'm regually responsible for planning and running net control for  health and welfare  traffic of endurance runners using Amature Radio (I have a 50k and a 100k that have just begun planning in the last week,  that I'm actice in promoting Amatre Radio to public (Street Fairs, Public Servixe demonstrairons, Scout Merrit Badges, etc)

Since February 2013 I probably have over 20 days (480 hours) of time into this (guesstimate. I hanent tracked the hours. May very well be more) fixing one major security bug last releases took over 40 hours itself in planning and implanting and testing, which shows itself with just a few hundred lines of simple changes as the end result of deep though and testing to be sure it's done right.

I proceeded to patch the firmware per the changeset results from ticket 60 stated as closed. See link below:

http://ubnt.hsmm-mesh.org/products/BBHN/changeset/6036dc3ff67086662dd83b62bc2d63f1f587edaa/bbhn_ar71xx

The patch was done and the link results were in fact better for a longer time, however, with side effects. The router response to pings, web service, telnet, etc, is sluggish. It appears there is a lot more going on under the hood than obvious with the simple watchdog process addition in the OSLR config file. AFter several days of operation, the router seems in a almost constant restart loop. Pings die for 4-5 seconds then resume, die, resume, die, etc. Now what's up? I was a bit disappointed this ticket was closed without a new firmware release committed to, but maybe the side effects have been seen by others to delay such a watchdog workaround fix. Can someone give me an idea what's really going on here and when we might see some relief? Should I back rollback the patch? Still trying....

Bob AF5RS

As you can imagine a "RF Jammer" is not very fondly looked upon by government so such a feather would not be in a stock build.

Linksys: None, and not doable at all due to the closed source nature of the driver.

Ubiquiti: Maybe if you hack the Kernel driver you could make something happen but nothing in the stock code.

Best Chance without modification:  Transmit large packets out the WIFI interface, You will still have spaces. but this will give you longer pulses. Most pulses on the nodes are probably around <100B The MTU is around 1KB so you could make packets around 10x larger than most average packets we transmit without forced data.

 Use of a "packet spammer" may help (there is some code online to make one) but would need something to be compiled by you on your own.

While it may function it is not the ideal deployment.

MIMO (multiple input multiple output) devices really want to see the same input on all antennas and will chooses the stronger of the two signals.

They seem to work best when running in different polarities (H+V)  or at least separated a distance apart from each other (the point is to get a different reflection to one antenna vs another)

In the case of 802.11n devices they actually use the fact that different polarities can be used (30+db isolation between polarities) to allow 2 data streams over the exact same frequency when the channel is useable, and when its not it falls back to 1x2 (1 chain 2 antennas) to cover the fact that one single path may be stronger (at any given second)

2x devices would be better (one on the Omni and one on the directional) and use DTDLINK to link the nodes together, Especially if you use dual polarity on the directional and the Omni.

Signals can change polarity as they bounce , Vertical is the usually noiser polarity. A signal from a field node may leave vertically and end up Horizontal on the other end, or horizontal and end up vertical, or maintain its polarity the entire trip. 

Transmitting both polarities gives best chance for decodes at the other end. (Many of the Ubiquiti devices do this already)

I have found and re-flashed a pair of Linksys WRT54G routers. My question is can I use one antenna for an omni-directional antenna and the other for a directional yagi link to another station? I am not certain if they are separate transmit and receive or able to be completely independent. Any help would be appreciated. Thank you for your efforts.

Hi Matt,

I'm in MPLS and want to do the same here.  We could share some resources. Go to QRZ to get my email address. 

Thanks,

Pete

KA0PHD

Sorry, after re-reading my last reply... it was a little terse.  We are working on an upgrade of the BBHN web services and expect the upgrade to be much improved... including searches of the Forum.  In light of this, and the fact that we didn't write it, it's difficult to justify even looking into the current editor.

Others seem to have gotten around issues with it, so if it continues to frustrate you, then perhaps using another editor would save some of the aggravation.

73,

Andre, K6AH

There is now a node on top of the William Mercer building located at 300 Commissioners Road West.

The node consists of two Ubiquiti units.  A "Bullet M2 Titanium" with a 12db omni antenna as well as a "Nanostation M2" pointing north. The 2 units are linked via their Ethernet connector. A 3rd unit is planned and we ran an extra network cable up the mast. A Cisco switch has been purchased to allow the linking of multiple devices.

According to Google earth, the position is 42 57' 23.97'' N, 81 16' 41.57'' W

The ground level elevation is 870 feet.  The building is 10 stories tall.  We have a mast on top of the mechanical room which is on top of the building (which should add another 100ft to the total elevation).

This is the 1st of many planned "anchor" sites.  We will try to cover the long hauls by linking the various anchor sites with directional antennas and flooding the surrounding areas with Rf using omni antennas.

If anyone in London is thinking about meshing, now is the time to get involved.

FYI: we hope to have more nodes in the near future!

For the next few weeks, I have placed some photos on my web server:   http://hamster.foxhollow.ca/2014-08-09-Hammesh-Mercer-Building.zip

The zip is about 500megs.  It contains random photos from the top of the building including some panorama views of the skyline. If you see a building in the distance that you have roof-access, contact me!

My name is Matt and may call is K7CBY.

I have put up a node near Olive and Citrus Rd. No outside ant. but there is a node. I am new to this HSMM-Mesh so I am still learning about it and what I can do with it.