Think of it this way...
You MUST use the .bin if you have stock LINKSYS firmware on the device.
You MUST use the .trx if you already have BBHN firmware on the device.

Also, I'm curious why you are going to v1.0.0 firmware?  Do you have other nodes in your area still on 1.0.0?

Well, at this point, I would suggest just resetting the password.  For the Bullet, hold the reset button for 5 seconds and for the WRT, you would need to do a TFTP reload of the firmware.

This would set everything back to the default of root/hsmm

Make sure that your CAPSLOCK is not enabled when you are setting your password upon setup.

The ticket includes another scenario with the same root cause.  So the ticket will remain open to address it.  

Andre

Hello Shawn VA3MFD and Chris VE3SKH, I see that you 2 are neighbours, only about .2km apart !!  Have you been able to make a link from QTH to QTH ?

Bob

Conrad/Andre,

In looking around in the configuration settings for the mail server, I discovered that there is a setting which uses the incoming URL to build the redirected URL.  So if the incoming URL is "http://KI6MLU-Webmail" the redirected URL is "http://KI6MLU-Webmail/username/mailfile" and the cookie is valid; the user does not have to re-authenticate.

That solves my immediate problem.  You can close out the problem ticket and just keep this in mind as a "feature request".

Russ

Joe,

That's an excellent best practice.  Our 4x4 club is running a land navigation exercise in the Mojave desert this weekend.  We plan to deploy about a dozen nodes and expect to have 4 or 5 webcams, a mail server and an IRC server on the mesh.  We need to make sure we have unique names for each of the services.

Russ

I would recommend as a best practice not to name your mail server, webmail. If you are on a small mesh and you are the only person with a mail server then you can get away with it.

As we start to create larger networks, there is a likelihood of two mail servers on the network if both are named webmail than they will conflict and you will not be able to reliably connect to either server.

Best practice will be to include a call sign for the owner of the server in the name. My email server is ae5ca-node0.  

In testing tunnel software, we have found multiple asterisk servers named RPI on the expanded network. 

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.