I've been searching for a half hour or so with Google advanced search, and although I've seen posts about this in the past, I just can't seem to dredge them up.

I'd like to really simplify initial access to a node, and make it extremely easy to find the advertised services. The simplest thing to do would be to have a splash page that comes up when you initially access the node, in place of the 'redirecting' message. Then, have links directly to various services permanently installed on a node, rather than drilling down to the 'advertised services' on the mesh status page.

For example, telling people to connect to a wifi AP attached to a node should be sufficient to get them started in finding services such as web pages with event information, ftp servers with required software for download, etc. A captive portal comes to mind, but they tend to be restrictive and difficult to set up (for me, a Linux novice). It seems easier to take advantage of the already working Apache server.

I'm about to dig into a node to see what I can see about adding some information pages, possible splash pages, etc. Any suggestions or pointers would be greatly appreciated.

Thanks.

I was poking around a node today and seems if you were to look in the www directory you could edit the HTML files there to add links.

--edit If you edit /www/cgi-bin/status you can add what ever you want to the splash page. It's written in Perl so make you use the right syntax

VE6SAR

I'm with you 100%.  Rather than connect to the status via port 8080 I think there should be a more general purpose and informative HTML page maybe with some simple graphics when connecting via port 80.  It would be nice to have some user information displayed so others know what they're connecting to.  Here is my status page for the node on my tower:

Below is the status page I did for my pedistrian mobile node/WAP I had strapped to my backpack at Hamcom a couple weeks ago.

I didn't have much luck trying to serve up images when I messed around with this.  Not sure if that's a limitation of the node page generation or not. 

I think augmenting the information on the advertised services page would be useful too instead of just a static link.  Not saying the existing pages are wrong or bad, but as the mesh evolves it'd be nice to improve the user experience, so in general use we don't always have to see how the sausage is made just to use it.

Mark K5LXP

Albuquerque, NM

Thanks for responding, Sean & Mark. Mark, your screen shots didn't come through.

Lacking any skill with Perl, I've decided to fool around with the 'index.html' page. There's a 'refresh' meta-tag that does the redirect. By pulling that and building a static page with some links to the node's resources, I can do almost what I want. For example, a link to the node status page to go to the built in web admin system, plus a direct link to a message board (Hamchat) or IRC server on the node. These are link local, so don't require any dynamic updating. Some introductory verbage is nice as well for the uninitiated.

I'd like to see a more user-friendly advertised services page too. The automatic way the links propagate the mesh is absolutely essential to a simple, rapid deployment scenario. So I'm not going to mess with that. But a basic welcome page cueing new users on where to find links to services should be simple.  At a demo recently, just putting 'connect to localnode:8080' on a whiteboard was sufficient to get most people on the right page. From that point, using a  simple captive portal to capture call-signs or email addresses of attendees would be perfect. So far, the captive portals I've found are too complex for me to try at my current level of Linux knowledge. Plus I risk breaking the existing web services.

Onwards...

A couple items to think on.

1) The use of port 8080 comes from when the nodes defaulted to NAT mode, and because NAT mode is still an option.  If the mesh node runs a server on port 80 than users would not be able to run their own server on port 80 and direct to it. This is why the web interface is on a different port.

2) Not saying we can't do better with the services page,  I will say though the thought that this will be used by someone whom needs to look for nodes that doesn't know to look at the status screen is not a good situation for an Emergency deployment.  Ideally you want individuals to be trained.  Modifying the pages on the node itself doesn't make sense in this regard since if they don't know about services they likely wont know about localnode either.

I can see the the concept of captive portal on an Access Point that might be providing a link from local users on non mesh devices into the mesh (with rules,  links to some local services etc) and can understand how that could prove to be an advantage. How that would interact and what it would do  is of course a bigger topic.   It should not run on the Mesh Node  itself it should run on the access point device (now be that a meshap or some other device is a different topic as well.) There may be some OpenWRT based firmware or similar already avalible on the web to create simple captive portal access points. I'm sure I have seen a distro or two, but can't recall off hand the names.

Mark:  Ah Ha! you must be the gentleman with the 2 node backpack.... Hey did any of us get a photo of that?  ( Doh! moment now that I think upon it )

Funny, the screenshot images I posted above show up under Firefox both in windoze and ubuntu, but not under Internet Exploder.

There were a couple of folks out in the fleamarket at Hamcom that took my picture with the pedestrian portable mesh but I don't know who they were. Maybe they'll float up on a ham forum somewhere.  I was stopped and quizzed about mesh by a number of folks and having the WAP capability I was able to connect with my smartphone and demo the various pages on the spot.  Not much activity to see on Friday but on Saturday there were a number of nodes that showed up on the neighbor list.

I don't agree with the premise that if you're not savvy enough to operate the mesh as-is, you shouldn't be operating the mesh.  Consider the many things in our lives that have "no user serviceable parts" yet are incredibly complex.  Something as ubiquitous as a smartphone even children can operate successfully.   For most users of wifi, you connect to a visible wifi network, maybe put in a password and that's it.  I see no reason why there can't be a simple UI as a (configurable) first layer for general users, then if you need to muck with the mesh innards, those facilities are there too.  I don't think there should necessarily be a default interface, but to leave that up to the user to create an index page that makes sense for their mesh and what they need it to do.

An example I would use is the DSL router I have.  When you first log into it all you get is a splash screen with a few plainly obvious function/status icons to click on.  From there you can drill down as deep as you want.  But if all you want is to view or manipulate basic functions, you don't have to go beyond the first layer or two.

I get the port 80/8080 reasoning but I think that's the logic of a programmer/engineer and not a user.  Using port 80 should be the on-node default.  Courtesy of W9YA and the modified files he supplied I have my nodes set up for port 80.  If port 80 needs to go to an external server, it's a simple change.  I believe the use of an external server for port 80 would be the exception in most node deployments.

So in the case of my pedestrian portable node no one had to know to connect to "localnode:8080" which is a foreign concept to casual computer users, it ended up being k5lxp-32 into the browser address line, and that's it.  Much easier to recognize and use.  I know this is kind of picking nits when at this stage there are very few mesh networks in place but the easier it is to use, the more interest it will garner.  Today BBHN looks very "experimental" at this point and possibly intimidating to some who might otherwise try it.

I embarked on the mesh journey for as much an education in networking as the use of mesh itself.  I don't believe most hams would share that reasoning, but might be interested in trying a node that did a few basic functions with little user intervention.    Start with a level of basic functionality and let the user grow into it. 

Mark K5LXP

Albuquerque, NM

Hello Mark,

It sounds like we may be closer to the same thoughts than it sounds.

The situation described of just plugging in a password on WIFI and getting instructions is basically what hotels do when you visit them (Captive Portal) --- This was what was talked about earlier in the thread.   You would not want this on the mesh device itself because it could interfere with traffic from locally connected and automated software and increase the load on the node itself.  On an access point like you had walking around at HamCom though you would.   This also gets away from the need to tell them where the node is at as that page could do everything when it captures them, aka they don't even need to know to visit your callsign  it just happens on first load.

I would also say the BBHN interface, while not having a lot of images (NOTE: we are close on the amount of flash space on nodes --- Images have to be considered carefully as to how they are used to keep us under the 4mb limit on the Linksys devices) is very similar to an existing router  where you get a splash screen (status page)  and can drill down after that to what you need..  Everythign is only 2 clicks deep at the moment. You still need to know how to get to the splash screen (just like a standard router) so no real difference there.

PS:  Please make sure your node also runs on port 8080 as well if its going to be connected to general meshes.  All the links from the interface will push towards 8080 and if the web interface is only on port 80 users will just get could not connect pages.