Aloha Networking....Specifically cross subnetting.

[Clemonsak]

I have numerous stores that I support, and I've never tried using multiple subnets until now.

I have a Catering company that needs terminals setup at a different location than the server.
Server is set up in the managers office, and the terminals need to be setup in a conference area...

I have the network setup and working properly on the OS (windows 2008 server, and windows xp embedded on terminals)

Here is my example. Server ip is 192.168.0.50 and the terminals ips are 192.168.1.1 amd 192.168.1.2.

There is network connectivity between the 2, I can map a network drive, view/modify files on the terminal from the server
and on the server from the terminal. However once I start ibercfg.bat (Table Service, version 6.5) It will stall at looking for file server.

Is there anyway to make this work across these subnets (I have no control over the network)?


Thanks in Advance.

PS.(I can connect the terminal to the server in the same building (it will then pull a 192.168.0.1) and everything will work fine)

 

[coorsman]

I don't know of any way to get it to work in that configuration. I've seen it done using a VPN of sorts but it's been a while.


Cheers,
Coorsman

 

[360fish]

Aloha relies so heavily on netbios and netbios does not work properly across subdomains... take a look at this post (just found it with a quick google) for a bit of information.

Setting up a vpn tunnel is something I was going to try for a somewhat similar problem but I came up with a better solution - netgear plus series switches and VLAN. You said you have no control over the network but maybe you could talk to the people who do? Also, some simple routing would work but, again, you need to work with the network people.

OR you could try server --> wireless bridge<->wireless bridge --> terminal. That should work but you have to have a very strong signal to ensure you don't start getting issues like crossed masters and other ugly. I've been using Ubiquiti hardware and absolutely loving it - they have many products that should be able to connect through most noise and at least a few walls and ceilings just be mindful that 5.8 looks great for clear(er) spectrum but doesn't penetrate walls nearly as well as 2.4. Depending on distance and materials between server and terminals (remember wireless does not like to go through metal or ... thick concrete) a pair of Nanostation series radios might work (about $140 for a pair). The ubiquity forums are an excellent place to get advice and help.

It's an interesting problem let us know how you resolve it?

 

[Clemonsak]

When I said I don't have control of the network, it really meant, my boss is stubborn and doesn't want to change his network policy....and wanted a work around.

We will end up putting them on the same vlan and trunking it across the network, no reason to buy new devices in order to save some networking configurations.

Thanks for the input.

As a follow up question I was reading this:

http://www.abacuspos.com/features-7-0.html

and it mentions that Aloha 6.7 uses an XCOM networking service, but I can find nothing about this anywhere else...including from Radiant themselves...have any of you heard of this XCOM service that the above site mentions? or anyone have experience with 7.0 and the ACL it talks about?

 

[Clemonsak]

Ohh ya, as a side note, I've lurked around here alot and got the answers (or at least the direction in which to look) to all aloha problems I've come across mainly from this site, and mainly from Coorsman....so...Thanks

 

[eburks]

Why not just add another NIC to the server and set it to the 192.168.1.x subnet

You would have to use lanacfg and set that nic to lana 0 and then aloha will work just fine

other ideas would be Windows ip forwarding google it but here is 1 of the links

http://www.home-network-help.com/ip-forwarding.html

or a proxy server like freeproxy might help

But.... these are going to require another NIC anyway


For security it would be best if your Aloha Nics (server and terminals) are not setup for dhcp and have static ip's like 10.100.110.xxx If dhcp is enabled for your aloha network then any rogue device on the network can get an ip in that subnet and talk to your Aloha computers which is not a good thing

speaking of multiple NICS
I have a server with 3 nics in it 1 is the aloha and has no internet access in it's subnet, 1 has ATT DSL and handles EDC when ATT is up the 3rd is connected to a clear cellular 4g modem and takes over if ATT goes down (my ATT at this location goes down whenever it rains :-(

just in case something like this might help you......

I use Realvnc Enterprise with encryption to manage my terminals and all the computers I have access to.... not quite 2 factor authentication but it is fairly secure

Locally at 1 location I manage computers from one subnet to another without major routing or the use of the internet by using a program on the Aloha server called passport. (it's free) It has forwarding rules you can setup so that any activity on a particular port forwards to another ip/port for example:

source port 192.168.0.222 port 40000 target port 10.10.10.101 port 5900

so if my terminal has vnc setup to listen on 5900 I can use vncviewer on the 192.168.0.xx subnet pointing to 192.168.0.222 and port 40000 and vnc into the 10.10.10.xxx subnet computer

 

[coorsman]

Aloha POS v7.0 Aloha Communication Layer (ACL) handles communication across the Aloha network as a single, network communication solution. As soon as you install or upgrade to Aloha POS v7.0, the Aloha Communication Layer is active full-time across your Aloha network, requiring no configuration for this feature. XCom gives you the ability to resolve connections across subnets, simply by assigning a unique network name to each device.




Cheers,
Coorsman

 

[Clemonsak]

Coors, where did you get the info on XCom? and is that available in 6.7 or just 7?












/

 

[coorsman]

just 7.0 and not released yet. It will be another part of RFS. I couldn't find any other doc's on the subject.

Cheers,
Coorsman

 

[360fish]

7.0 has been in "beta" stage for at least a year. As I understand it they're doing a complete code re-write, which was needed since Aloha 6.x is basically the same code from 5.x which is the same code they bought from ibertech in ... 99? I'm exaggerating, but only a little.

I have a copy of it and a key authorized for 7.0 but never got it working ... to be fair I didn't try all that hard. On paper 7.0 will be pretty excellent - I hope the long "beta" indicates they'll be releasing a robust and well-tested product.

I hope XCOM isn't part of RFS as it exists now... that was a buggy-as-hell bandaid they built using some russian-made code written, again, in the late 90s.

This is just by memory, I could be totally wrong, I usually am. Anyway kind of off-topic at this point.

Coorsman, props as always for your great help. I thought you were off Aloha and into squirrels or something? It's great you're still lurking around here.

 

[coorsman]

Funny 360Fish.
Like the maytag man, with squirrel, very few support calls or problems. Keeping my mind fresh, still have all my old Aloha tools and AKB's - willing to help as always.

Isn't 7.0 was just a BOH interface for the old Aloha system. The FOH program still relies on dbf files created by the SQL manager. From what I heard the rewrite wouldn't be finished until 2020.

Cheers,
Coorsman