[OT] WiFi serving non-web pages.

Uh, someone with more expertise than me. Ask on Stackexchange. Or contract with me to do it and I'll subcontract the parts that I don't know (which should be easy to find out if you ask in the right places).

You need a name server and a web server on the PC. The web server you almost certainly want is called "Apache", and I know how to deal with it, but I've never done the nameserver part.

Alternately, you could post the IP address of the PC on the wall.

With the name server, someone would type in the name (e.g. "bob") in their browser, and they'd be talking to the PC. Without the name server, they'd type in the IP address of the PC (e.g. 192.168.1.42), and they'd be talking to the PC.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

That will depend a lot on what you mean by "WiFi router" (and the actual device in question).

The basic issues of serving up web pages boil down to:

- connectivity (i.e., can packets get back AND FORTH from point A to point B)

- addressing (i.e., how does the user know where to *find* the server)

- protocol (i.e., having a server that can serve up HTTP)

Some "devices" (avoiding the term "router" for the time being) treat inward-facing and outward-facing ports differently. I.e., a "node" on a inward-facing port might be blocked from (explicit) access from an outward-facing port (e.g., on the assumption that outward-facing ports TYPICALLY provide services to inward-facing ports and not the other way around).

Often, inward-facing ports are forced to be "private internets" (RFC1918) and may even enforce this requirement in the device's configuration (e.g., prevent tech-unsavvy users from misconfiguring an IANA allocated address to their own private internet).

As a result, the address you are "stuck with" won't be available via any resolvers that the user might have access to (from The Internet). I.e., "Clives-Place.com" won't resolve to an IP in the RFC1918 space (so,

won't make sense to the user's web browser).

As a result, you'll have to publish the IP address of *your* web server (more later) in numeric form (one of the RFC1918 addresses). *Or*, set up a name server that will be able to resolve the names you choose

mail.Clives-place.com, etc.) to the IP addresses that you've established for the services that you want to provide (WWW, Mail, etc.). Then, tell the user to use your name server when he connects to your WiFi (SSID, passphrase, etc)

In addition to the private address space, many "devices" will use Network Address Translation to make the device appear to The Internet (the outward facing port) as a single IP address (often assigned by the ISP as a static address or "leased" via DHCP). The private addresses on the inward-facing ports are then never exposed to the outward-facing port (this makes sense: given that EVERYONE can freely use ANY of the RFC1918 IP addresses, how could anything on The Internet know *which* node was intended for packets addressed to 192.168.1.1??)

Inward-facing addresses (on the wired and wireless nodes supported by the device) are typically leased via DHCP. So, a machine (i.e., web server!) connected to this router/device might have a different address tomorrow than it does, today (unless you go to lengths to force it to have a fixed address).

[So far, we've just noted the issues that affect *addressing* the web server! Note that all of these are relatively easy to handle; but, knowing how they need to be handled for YOUR choice of "router device" and server isn't something that can be stated without more specificity on your end]

The pages that you want to serve up need to reside somewhere. The "router device" typically has a built-in web server -- to address

*its* configuration pages. There is usually no way to augment the pages that it serves up.

So, you have to set up a machine that acts as *your* server and "connect" it to the "router device" (via a wired or wireless port). The protocols that you serve are up to you. You'd just need to ensure you had software that understood requests issued in those protocols.

The semantically cleanest way of doing so is probably to locate that server on the WAN port (outward-facing) of the router. I.e., *it* looks like The Internet to your users... just a very SMALL version of The Internet! :> This allows the typical traffic from machines/nodes located on inward-facing ports to reach *out* to that "faux Internet" without caring where *they* reside (IP addresses). It also allows any protections afforded to the internal nodes to remain intact -- in much the same way that your computers at home would be protected from malicious traffic sourced *from* The Internet in a more traditional router deployment.

A WiFi router is also known as Wireless Access Point (WAP). WAPs typically assign an internal address of 192.168.1.1 to themselves. WAPs assign the next available address, 192.168.1.2, to the first device that connects to them, 192.168.1.3 to the next device, and so on.

WAPs typically host their own webpage at http://192.168.1.1 . You can use the WAP's webpage to assign a static address (eg 192.168.1.2) to the PC. After you connect your phone to the WAP you can access the HTML pages on the PC by using http://192.168.1.2 as an URL in your phone's browser.

Thank you,

--
Don Kuenz KB7RPU

A WiFi router is also known as Wireless Access Point (WAP). Consumer grade WAPs typically guide you through the configuration process. Connect the WAP to the PC and power both on. WAP's typically assign an internal address of 192.168.1.1 to themselves. So, open your PC browser and enter http://192.168.1.1 as the URL.

At some point you will be asked for a SSID. That's the character string that the WAP broadcasts to phones to enable them to connect. You will also be asked to create a password.

Typically the WAP will assign 192.168.1.2 to the PC because it's the first device that was connected. To open a HTML pages on the PC you need to connect your phone to the WAP using the SSID and password that you created earlier, during the configuration process. Then you need to open your phone's browser and enter http://192.168.1.2 as the URL.

Thank you,

--
Don Kuenz KB7RPU

WiFi Hotspot. DD-WRT supports this as well as some higher end Cisco WAPs.

THe local Hospital uses this adn when you connect you get an agreement page. once you agree to the terms your redirected to the html server. I believe the login can be controlled by a Radius server that checks the users credentials, so you dont really need a login page just credentials for connecting to the WAP.

Cheers

What you need is a WiFi router (can be linux desktop or labtop) with the wi red connection to the network and wireless hostap interface. Just ignore t he WiFi port on your modem. Other devices connected to the router WiFi can also point to its default gateway. E.g. 192.128.0.1. You can named alias this to gw.com for example, then browes

Just put files in / var/www/html or whatever default home path. Apache (web server), named (na me server) and hostapd (WiFi server) are in almost every linux distribution . I can do all the configurations in 30 minutes. You might need a few hou rs to go through all the setups, but nothing difficult, just editing text f iles.

I'd bet this will be easier on a raspberry pi than a pc. google "raspberry pi web host"

--

Rick C

Try including the word "intranet" in there. For example,for a rPi you will get this:

--sp

--
Best regards,  
Spehro Pefhany

It's still a website even if it's not on the public internet. It's an intranet website.

Because it's not on the public internet you need a self-hosted solution instead of software-as-a-service solutions (like you-tube)

Mythweb does this sort of thing to stream myth-tv content to users connected to the same LAN. this is how I watch TV while doing the dishes.

--
This email has not been checked by half-arsed antivirus software

dnsmasq is an easy DNS server to set-up. by default it will share your /etc/hosts file. but you'll need to configure the your DHCP server to indicate your dnsmasq server as the DNS server to use.

I just use IP addresses. 10.10.10.10 is easy to remember.

--
This email has not been checked by half-arsed antivirus software

It really isn't clear why you want to do this. Putting it on a cheap web hosting package would be a lot easier and work anywhere.

Intranet is the keyword that will find you what you want.

If it is for your own use or as a mock up make a directory public read access and stick index.html and whatever else you want to see in it.

Log in to your wifi open the PC on the network and you should see the public readable directory containing a copy of the website. Double click on index.html and it will render.

You will get some security warnings if the website design uses scripting or anything exotic server side that requires a proper webserver but basic functionality and javascript should be OK.

Apache webserver will do it properly but the learning curve is steep. Wordpress might be easier to master eg

You might even find a pre canned solution to your problem there.

--
Regards, 
Martin Brown

Wow. Thanks all (and especially Don Y), lots to look at there, far more than my puny Google skills could elicit.

Cheers

--
Clive

This isn't *inherently* difficult. The problem lies in sorting out what you want (end goal) and what you *have* (in terms of hardware, software and skillset).

If you're comfortable with PC's (Windows), try hacking together some sample page(s) in a folder on that machine. Perhaps pick someplace easy to remember -- like C:\MyWebSite.

You can test/view the pages using a browser running *on* that same computer. Access the page(s) using a URL of the form: file:///C:/MyWebSite/pagename.html

Once you have an idea of what you can do with the page(s), look into setting up IIS (Internet Information Services) on that machine. Move the pages that you've just built into the appropriate folder (see the IIS documentation -- C:\InetPub\wwwroot is a typical location for the "root" of the web site) and then see if you can access them using the web server (part of IIS)

[The file:// syntax accesses the filesystem directly; IIS need not be running for it to operate properly!]

From there, you can try to access the page using the IP address of your machine ("http://IPaddress" will yield the default.htm page in the C:\InetPub\wwwroot folder)

Then, try accessing the web page from *another* computer on your internet.

[Note the IP addresses of your machines may be generated by a DHCP server on your internet *or* could be staticly defined in/on each machine]

I.e., instead of trying to tackle ALL of the issues in one shot, nibble away at the problem in smaller increments so you can focus on just one aspect of the solution at a time.

Once you know that you can serve web pages to a "remote" computer, you can put the server on your wireless router and let other hosts connect to it using the wireless abilities of the router.

The easiest approach is to hardwire the "server" to a particular address. Then, set up the DHCP server *in* your router to offer IP leases to WiFi clients (consider how long you let the leases remain active if you expect lots of transient traffic; you don't want a few clients to eat up all of the IP addresses that you've configured in the DHCP pool!)

You'll have to publish the SSID of the network and pass phrase (if required). You should then be able to access the server using the "hardwired" address that you set aside for it (previous paragraph) from any of the wireless clients.

If you want to get fancy, you can set up a name service on the server (or, on another machine accessible via that network). Then, configure the DHCP server to specify the address of this DNS server when it grants an IP lease to a new client. If you set up that DNS service to map "Clives-Place.com" (or "EatAtJoes", etc.) to the hardwired address, then wireless clients will be able to type "

" to access that "default.htm" page.

Again, this isn't hard. But, it will take you a while of poking at it with a pointy stick before everything falls into place. You may find yourself cycling power to the router often as you make changes to its configuration (and wonder when/if those changes take FULL effect -- like when all the DHCP leases are voided!).

Plan on a weekend of tinkering.

After that, your tinkering will be governed by how fancy you want your web pages to be, etc. You'll also find that different browsers will render the pages differently. And, different screen sizes, capabilities, etc.

[You can make a career out of maintaining even a small web site! :< ]

[...]

When I tried my hand at writing a web server, I was surprised how simple it could be. Mine ended up just 225 lines of C, a 7kB executable on an i686. It even has CGI scripting, which makes for a huge security hole, of course.

Most of the complexity is in the browser.

Jeroen Belleman

In a webserver, most of the complexity is in making it versatile and configurable, while still being secure. A hand written web server that has a single fixed root directory and the same permissions everywhere is easy. However, once you want to add different locations, mappings, permissions, virtual hosts, URL rewriting etc it becomes more complex very quickly.

As you probably don't need that for this simple project, it could be OK to write the server this way. I would probably use Perl and some pre-written modules, though.

This is not the kind of solution the original poster should look for. While Apache may be difficult to master, just getting a Pi, installing the Apache package and putting the html files in /var/www isn't difficult.

And putting a CMS on top of it (like Wordpress and others) makes it even easier to get a nicely looking site where content can easily be published. Of course most CMS have more leaks than a colander, but that should not matter too much on an intranet like this.

Unless you want a super-clean user experience (i.e., if you want grandma and grandpa to be able to log onto it with their smart phones), then Don is way over-complicating things.

OTOH, if you DO want that super-clean user experience -- go with Don's way. As mentioned elsewhere, there are systems that do "gateway to the internet" stuff for the hospitality industry -- one of those should be easy to hack (or perhaps even use by configuration), if you can just figure out which one to use.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!