While there is thought being done to switch over to using FQDN links  it still has a bit of a ways to go before it can be ready for rollout.

(The subject just came back up last night actually and I need to create a thread for on the dev forum to run across the idea to make sure nothing being missed)

In the mean time, this is actually a failure of your web application IMHO. 

The fact its redirecting to another domain name without respect for the fact it has set a cookie is the real issue.  The program should be smart enough to handle the fact it may be accessed from multiple domains.

This can be done as one of the following:

The program can use the request details to construct all links back to the exact same URL that was access. (This is the more common method when the program doesn't always know how it will be called)

The webserver can be configured to redirect all requests to http://mailserver to http://mailserver.local.mesh so the user always visits the correct URL.

A minor "nit".

I have setup an email server and advertised it on the "Advertised Services" screen. 

1.  The Fully Qualified Domain Name (FQDN) of the email server is "webmail.local.mesh"

2.  The link that appears under the services column of the mesh status redirects the browser to "http://webmail".  Since the network's search domain is "local.mesh", the redirection works OK.

3.  Here's the problem:  The home page of the email server asks the user for a login name and password, sets a session cookie, and then redirects the browser to the user's mail file "http://webmail.local.mesh/username/mailfile". 

4.  Since the session cookie is set for "webmail" and the redirect is to "webmail.local.mesh", the user is prompted to login again because the first session cookie doesn't match the name of the server.  After they login again, they are granted access to their email.

If there is a way to use the FQDN in the advertised services, the cookie would have the correct information and the user would not be prompted to login again.  But I don't see a way to put the FQDN of the email server in the Advertised Services form; the form only has a drop down to select the host name.

Am I missing something?

Glenn All depends what route and what hardware he goes with.

If he does what I think he might do (Atheros chipset)  for the WIFI modem  it actually becomes very trivial to make OpenWRT work with it.   Atheros chips have a wide design range (You can almost go from DC to Daylight with their chipsets)  and they are designed to do such (though much more heavily used in the ISM bands)  or if it uses a different method all together it just has to be implemented into Linux user space

The biggest factors from my standpoint as a developer whom has actually worked on the code when taking in the context of Atheros is calibration data. Over the past year I understand now that going away from the preset calibration channels means we switch to an extrapolated calibration and not calibration for each channel.  We would want to embed this into the new devices (to provide wider access)  if such a device required it.  Patches would then need to be submitted to us (not necessarily OpenWRT)  to be able to pull that caldata into the system.

The same holds true for Operating System, as long as we can get patches to make the firmware work (which is much easier to do when the "vendor" is willing to say "RF chip is on I/O pins 1,2,3,4,  LED's are IO pins 5,6,7,8    Power feedback control is done via blah" vs the reverse engineering that normally has to be done (still not that easy, but easier at least)

I will +1 the weather resistant side, maybe not MILSPEC but these need to be able to handle the similar range as a Ubquiti for me to be able to use them in my personal network.

And yes probably don't go Broadcom, Atheros is much more open source friendly (to the extent they actually publish code)  Glenn forgets this is part of the reason the Linksys had to EoS'ed because it was far too closed to actually fix anything bugs with (Like wifi: the modem was its own independent module, all you could do was tell it was basic things, it actually if you look at the hardware design is a fully self contained ethernet to wifi bridge chip aka its own wifi device inside a wifi device design)

Ultimately though it could be any vendor, or even a 100% custom design, as long as the drivers got written for the Linux kernel and patches provided to integrate it into the OpenWRT buildroot.

Hello:

Using a Linksys WRT54GSv4, I have successfully loaded 1.1.2 HSMM firmware and configured the node call sign and "password" (using the default root/hsmm login to get in). Upon reboot, I see the node ID, but I can not get past setup:login. What is the username for my configured setup, and is the login password the one I defined in config after firmware load?

Thanks,

--

Jeff Marden

KB1TJI

There have been several people asking how to restore the Linksys firmware to their nodes.  I have successfully done it may times.  This ability is not available in the Administration screen due the limitations in the Linksys User Agreement for the firmware.  Basically the Linksys Firmware is copyrighted and the Linksys does not permit others to distribute their firmware.

What this means to the BBHN user trying to return a node to factory firmware is they need to go to http://linksys.com go into the support sections and download the firmware for your make a version of node.  When you download the firmware, make sure you note where on your computer you put it.

The basics of how to upload the firmware are covered in the bottom of the Linksys firmware installation instructions at http://www.broadband-hamnet.org/documentation/68-firmware-installation-instructions.html.

The basics of installing the factory firmware on your node are:

1. Download the firmware from the Linksys Web site.
2. If you have not already done so enable TFTP on your computer.  To enable TFTP open Control Panel > Programs and Features > click Turn Windows features On or Off in left side > enable Client TFTP then click in OK.
3. Disable the WIFI on your computer.
4. Set the LAN Port on your computer to use a static IP in the 192.168.1.xxx range.  Do not use 1, 2 or 20 for xxx.  I normally use 100.
5. In order to keep the LAN connection open on the computer it is best to use an Ethernet switch between the node and the computer.  Connect a Cat 5 cable between a LAN Port on the node and the Switch and a second Cat 5 cable between the switch and the LAN Port on your computer.
6. In windows explorer navigate to the directory where you placed the firmware file.  Right click on the file name and select properties.  Highlight the file name and type control-v to copy the file name to the clipboard.
7. Open a command prompt (Start, All Programs, Accessories, Command Prompt) on your computer.
8. In the command prompt window, type but do not press enter TFTP –I 192.168.1.1 put.
9. With the cursor in the command prompt window right click your mouse to paste the name of the firmware file into the command.  Do Not Press Enter yet.
10. Here is the tricky part.  Remove the power from your node, wait a few seconds and plug it back in.  About ½ second later, hit enter on the computer to run the TFPT command.  You are trying to hit about a small window in the boot up sequence that is about ½ second long. If the TFTP command times out, repeat steps 8 -10 waiting just a little bit longer or shorter to hit enter.
11. Once you hit the window with TFTP command, the node will upload the new firmware and reboot.  It should come back up with the factory firmware on it.

I hope you will find these instructions useful.  This same process can also be used with a BBHN .bin file to reload the firmware on a node that you have lost or forgotten the password.

Hello Ron, Shawn ( et all )

On the very favourable comments from Ron and Shawn I have treated myself to a couple of Nanostation M2 and a Bullet M2.

I have to say that I am very impressed so far with the testing I have done.  Thanks for the "hot tip" on these devices.

I will keep you posted on further testing

73, Bob

The cost of the hardware is a non-trivial factor to consider. While there is great appeal to extend bbhn image support for the features that ubiquiti lacks, the hardware will inherently be higher cost--from $100 to $100s for a node-antenna--particularly for support in the non-ISM bands. The hardware designed for and supported in the ISM bands has economies of scale to drive down the cost.

If the more capable hardware/device being considered is supported by the OpenWRT community, then this could be considered for bbhn support. If the hardware was not supported by OpenWRT, then it is unlikely to ever be a candidate for bbhn. The effort to port bbhn to a non-OpenWRT device would be exponentially more.  If OpenWrt community doesn't extend support to any hardware you are considering, there may be a reason why they wouldn't.

Joe AE6XE

config:

NSM2

Netgear gs108e

Linksys/Cisco SPA941 4 line phones.

IF IF I get the phones set up properly should I be able to dial one from the other when they are BOTH on the same GS108E switch?

Anyone I can look for at Quartzsite with a MESH mind? 

Technically even the onboard switch still can do Linking with Ubiquiti devices but it has to be enabled manually (and need to understand he issues of doing so) as Ubiquiti gear was not caught up in the flaw (it was Realtek chips used by a LOT of devices) and would always link, but in order to ensure  user laptops an devices still worked it had to be disabled on Linksys hardware by default but can be re-enabled (per the release notes) manually. Ubiquiti of course was fin with it all and the feature is still enabled "out of the box" on Ubiquiti.

NOTE NOTE NOTE

Just in case someone read my post and got the Idea that V.3 

only supports 1 device that is not true.............it still supports 5.

this from my more learned friend: 

"the part that was disconnected in V.3 was the ability to direct link 

two nodes using an Ethernet cable. with v.2 you could connect any other 

node's Ethernet port directly to the Linksys...and force all traffic between those 

nodes to go through the cable, Vs. through the RF link. you could also crossband 5.8

nodes with 2.4 nodes, simply by plugging LAN port of the 5.8 into one of the LAN ports on the Linksys.

THAT no longer works.....NOW you have to use an outboard switch...and make the

direct link Ethernet connection through the outboard switch." 

I am truly sorry for putting out false information, BUT I truly thought from reading 

that the 5 devices had been changed to one 1, I was wrong!

Larry KB8EMD

One of these days you might catch up to my count Andre :)

See you at the meeting!

(Hey I'm actually going to make it it seems! this is unheard of, everything has conspired against me for months....)

Well...

• Power adjustable in 1dB increments up to 1watt
• Coverage throughout the 900MHz, 2.4GHz, 3.4GHz, 5.8GHz ham band (not limited to ISM bands)
• Supports both CSMA and TDMA protocols
• Supports MIMO
• Configurable parameters down at the RF protocol level
• Military environmental specs
• PoE powered
• Easily tower mountable
• Remote reset via Ethernet cable

 That's a start.  Interesting proposition.  Can't be an easy assignment.

Andre, K6AH

Monday, January 12, is our next San Diego Mesh Meeting.  If you are not in the lobby by 7pm, then email me at callsign@arrl.net and someone will escort you to the meeting room.

Qualcomm Bldg Q,
6455 Lusk Blvd.
Sorrento Valley (San Diego)

Talk-in 445.640 (-) 107.2 PL

See you all there.

Andre, K6AH

The release notes carry more details on supported hardware.

The Nano Loco M2 is a smaller sized unit with both lower power and lower gain antenna than the Nano M2. 

We don't support the non M series.

Hi,

I am looking at the different versions of nano station available and a bit confused over what the difference is between the models.

Locally I can purchase:

NanoStation LocoM2 200mw
NanoStation M2 500mw 
NanoStation2 NS2

Is there much difference in compatibility in the BBHN firmware?
Is the Loco version just a low powered version of the NSM2?

Thanks