InsideOutsideMesh

Category:Sasecurity
=== Inside the mesh and outside the mesh ===
One point - you can only SshMesh to the box on it's 1.x.x.x address if you are inside the mesh. If you are on the outside LAN, then your default router won't know how to route to the 1.0.0.0 subnet. Only meshboxes know how to route to the 1.x.x.x subnet. Consequently, you need your client to be using a meshbox as the default route if you want to hit a 1.x.x.x address.
Otherwise, you need to use the LAN address of the GateWayNotes meshbox, and then ssh from that meshbox to the others.
Also, one other gotcha - if you haven't authenticated on to the mesh, you can only ssh to your local meshbox from your client. You won't be able to ["ssh"] directly to the next hop meshbox until you have authenticated. But you can ssh from the meshbox to any other meshbox.
Try puttying into either box and view ReporTer. Does it show the other box under mesh boxes detected? If so, it at a reasonable signal ie greater than 89-90 and (100% @ 0) ? If it is poor the gateway may block it after a short while as being a bad link and refuse to mesh. If it has lots of updates waiting it could be rebooting repeatedly after each arrives. Try both boxes as routers together plugged into ICS box,allow them time to settle, then when they have successfully meshed pull the lead. This might help you get accustommed to meshing. It took us monthes to reach the point you are at with dialup... keep going! ---
Wiana defaults the 2nd interface to ad-hoc. Change it to infrastructure (only do this in cases where you have a 2nd radio installed) and set your channels up so that one interface on each box is on the same channel and same ESSID and it should do the rest.
=== Edit me ===
It appears that the new version trashes the wiana.setting file. In addition it turns off the DHCP server and will not allow anyone to connect unti it has done an update. The channel had also been reset back to default. To resolve the issue I went back to the closest node. Set its channel to 1 and SSID to LocustWorld then waited for the two boxes to mesh. When they did I then edited the wiana.settings file and changed the settings to channel6 and back to our SSID. I then rebooted the box and reset the settings on the box I did this from. They remeshed and I was then able to do a remote management. Everything seems to be working well again. Regards Andrew > 
> Subject: RE: [MeshAPuser] Build25 dev88 released (but broke > our network). I have just updated the first node and after a reboot is has > failed to come back up. Looks like the new DEV version may > have issues as the node it was updated on was a stock > standard node running dev81 and has been up for months > without any issues. > > I will let you know if it comes back but if it has not come > back up im going up there to replace the flash with the Dev81 > and continue to use that. > > I did check that there were no additional modules loaded > before doing the update as well, so it was not a space issue. 
The latest development release is now ready for testing. > > > > New features in this release include: > > > > Support for the new Wiana options "Preferred Gateway" and > > Walled Garden > > support. > > > > Preferred gateway is similar to lock to gateway except that > > if the gateway is > > not available then it will move to the next preferred gateway > > or revert to > > the default behavior. Of course "Lock to Gateway" overrides > any other > > settings. > > > > Walled garden support allows you to specify any number of IP > > addresses or IP > > ranges which are not restricted by the captive portal. > > Typical uses would be > > for an intranet, advertiser url or to facilitate handing off > > to a remote > > billing provider website. > > > > To specify an IP just enter the address, to specify a range > > define it for > > example: > > > > 192.168.1.0/24 > > > > For a class c network (netmask 255.255.255.0) > > > > To update to the latest build, login to the node and issue > > the command: > > > > getandverify tobuild25dev88 > > 
=== asdfasdf asdf ===
Yes, they're on the same channel. I've changed the SSID back to > LocustWorld and completely rebooted both (cold boot from CD). They can > communicate via device ppp0 immediately upon startup, up until either > one checks in and picks up the Gateway Tunnel setting, which is "IP" > (per the wiki documentation). > > FWIW, I just booted them both and verified the internet connectivity on > both by pinging google.com by name. I ran remotemanagement on node 2 > repeatedly. All it did was tell me there were no MII interfaces, synch > the time, show the hardware key and ultra key - it didn't appear to > actually check in with Wiana. The GW node checked in, retrieved new > settings, and rebooted. Now node1 can't communicate with node2 since > it > doesn't have ppp0 in it's device list (node2 still wants to do pppoe, I > think). > > This is all getting to my second question below - is it possible to > strand a unit in the middle of nowhere based on a Wiana setting, > forcing > you to have to go lay hands on the device with keyboard and monitor? > Can you totally cut off a node accidentally? Do you just power cycle > it > and have it recheck its Wiana settings (which you've hopefully fixed)? > > 
Subject: Re: [MeshAPuser] Second MeshAP won't connect to >> first... What to check?
>> Are they on the same channel? Can you change the ESSID of the >> first one to LocustWorld? This will make things much easier >> in the initial stages. >> >> Also, check to make sure that WEP isn't on with one and not the other. >> >> Check to make sure you can ping the 2nd one as well. The >> easiest way to do this is set your laptop to ESSID of >> LocustWorld and try to associate with it. If you can't >> associate with it, then your problem is the Orinoco card. >> >> Best regards, >> Kenny >> >> On Oct 17, 2004, at 7:05 PM, Schuhmacher, Bret wrote: >> >>> Hi all, >>> >>> I've got one Mesh node working fine, uplinked, handing out DHCP >>> addresses, etc. However, I can't get the second box to find it and >>> use it as it's gateway. Reporter just says it's looking for a GW. >>> Second node is a Dell laptop booting off the CD (can't >> install to HD :-(). >>> It's got an Orinoco Gold card in it. The link light on the card is >>> lit and ifconfig says the device is up and everything seems to look >>> pretty good, AFAICT, but honestly, I don't know what a good setup >>> looks like yet :-(.
>>> What types of things can I check to determine what, if any, errors >>> there are? Since I booted off the CD, I don't have any error logs, >>> and I cannot see all the bootup messages since they move so fast, >>> scrolling offscreen.
>>> Could this be a Wiana setting? I have "mesh with any AP" >> on right now >>> since my GW AP is called "MeshAP" and the second box is >> "LocustWorld". >>> Are there any other settings or programs I can run to find >> out why it >> cannot ping the GW?
>>> On a more general note, is it possible to change settings in Wiana >>> such that a node out in the middle of nowhere loses ALL >> connectivity >>> and you wind up going to it, plugging in a monitor and >> keyboard just >>> to get some access to the node?
=== adfaf a ===
 Node not meshing [BR] do the nodes in town see the node with the panel antenna directly? [BR] if so, run sigspy from both town and panel ends and see what values you [BR] get for signal and for noise [BR]
- the diff should be at least +7dB and stable, otherwise it won't work [BR] reliably. [BR] What does reporter say also? [BR]
what does cat /proc/aodv/monitor say? [BR] You have changed out the antenna, but have you checked out the pigtails [BR] and antenna RF cabling and connectors? [BR] Did you use self-amalgamating tape to properly seal these RF [BR] elements? [BR]
If not then water can get into the cable and intermittently short out [BR] the signal so it fails to reach the panel! [BR] Otherwise, bite the bullet and upgrade to a more recent release - been [BR] running nodes on version 1274 (getandverify tobuild25dev90) for a good month now [BR] hereabouts and it works well [BR]
- there are all kinds of issues with some of the earlier releases of [BR] the meshap code [BR]
- just remember if you do upgrade to work from the outside of your mesh [BR] inwards and do your gateway/s last :) [BR] Lastly, all your nodes in the same mesh are on the same ESSID and [BR] channel otherwise they won't be a mesh (there is also an option to [BR]
"mesh with any ESSID" but this makes for a major security hole so best [BR]
avoided unless absolutely essential!) [BR]