Replacement for Omni Pro II

Some troubleshooting questions from a networking point of view (I don't have an Omni panel):
  • Can you confirm you have the proper subnet masks on every interface on every device?
  • Are you using any Jumbo frames anywhere?
  • Is UPnP disabled on the GL-iNet router (in general, this really should be disabled everywhere)?
  • Does rebooting just the GL-iNet router fix the issue as well?
  • How old is the modem? I've seen some weird behavior with older DOCSIS 2.0 modems
  • Do you see any errors on the LAN or WAN interface on the GL-iNet router using ifconfig -a, netstat -i or netstat -s? Feel free to share the interface counters. I've seen similar behaviors in the past due to firmware/OS bugs where large values may cause this type of degradation.
  • If you have a spare switch, I'd consider plugging it into the LAN side of the GL-iNet router, plug the Omni into the switch, and check if you see this same behavior when pinging from a test machine plugged into that switch.
 
The router feature of the modem is turned off

Are you writing about the WAN combo router, modem, firewall, wireless device that you get with an ISP?

What MFG and model number is your combo ISP modem, WAP and switch.

BTW before connecting to the OmniPro panel Ethernet port you should do a cold reboot of the panel disconnecting the battery and power supply as the NIC port issue affects the serial bus on the panel. The original issue of the OP2 Ethernet port being too promiscuous initial fix was always a cold restart of the panel and a disconnect of the Ethernet port depending only on the serial consoles way back. Think of the promiscuous Ethernet port needing a buffer cleaning of sorts which does muck up the serial bus. (very primitive early design when there were only 1-2-3 Ethernet devices on your home LAN)


Using the same IP on the WAN side of the router as the original Omnipro panel IP shouldn't make a difference in any settings on the ISP router.

The microrouter installed between the OmniPro panel and the home LAN shouldn't have anything to do with the ISP modem / router et al with the same port # open for the panel ethernet use.

Here the Ethernet LAN transport goes to Omnitouch screens, Homeseer Omni and Home Assistant Omnilinkbridge.

Access to the LAN from the Internet (WAN) is provided by an OpenVPN server running on PFSense and Windows, Linux and Android clients (years now). I used to open ports up on the firewall many many years ago. Typically enable OpenVPN client to home then run Snaplink with standard LAN IP to access the OP2 panel (or microrouter WAN IP).




Wondering if you would have or have similar results or worse without the GL-iNet in place. It could be a bad OmniPro or GL-iNet NIC port.
I purchased a few of the same GL-iNet Mango routers a few months ago refurbished like new on Ebay. Only tested one of them so far.
That said still using same Nexx 3020 microrouter from a few years ago with WiFi radio off on the Omnipro 2 panel. Tiny thing. Never found any more of these.

The settings are basic. I did shut off IPv6. You are doing only a L2-L3 conversion routing the traffic.

Is the microrouter getting warm or hot? Are you using a bucky transformer from the panel to the microrouter for power?

Did a similar test here...

BusyBox v1.28.4 () built-in shell (ash) _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M ----------------------------------------------------- OpenWrt 18.06.4, r7808-ef686b7292 ----------------------------------------------------- root@ICS-HAI:~# ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: seq=0 ttl=64 time=3.280 ms 64 bytes from 192.168.1.2: seq=1 ttl=64 time=12.521 ms 64 bytes from 192.168.1.2: seq=2 ttl=64 time=63.162 ms 64 bytes from 192.168.1.2: seq=3 ttl=64 time=2.840 ms 64 bytes from 192.168.1.2: seq=4 ttl=64 time=2.720 ms 64 bytes from 192.168.1.2: seq=5 ttl=64 time=4.000 ms 64 bytes from 192.168.1.2: seq=6 ttl=64 time=2.860 ms 64 bytes from 192.168.1.2: seq=7 ttl=64 time=14.520 ms 64 bytes from 192.168.1.2: seq=8 ttl=64 time=95.362 ms 64 bytes from 192.168.1.2: seq=9 ttl=64 time=9.880 ms 64 bytes from 192.168.1.2: seq=10 ttl=64 time=28.041 ms 64 bytes from 192.168.1.2: seq=11 ttl=64 time=2.860 ms 64 bytes from 192.168.1.2: seq=12 ttl=64 time=39.321 ms 64 bytes from 192.168.1.2: seq=13 ttl=64 time=2.761 ms 64 bytes from 192.168.1.2: seq=14 ttl=64 time=19.480 ms 64 bytes from 192.168.1.2: seq=15 ttl=64 time=3.540 ms 64 bytes from 192.168.1.2: seq=16 ttl=64 time=18.540 ms 64 bytes from 192.168.1.2: seq=17 ttl=64 time=2.900 ms 64 bytes from 192.168.1.2: seq=18 ttl=64 time=2.720 ms 64 bytes from 192.168.1.2: seq=19 ttl=64 time=2.840 ms 64 bytes from 192.168.1.2: seq=20 ttl=64 time=2.780 ms 64 bytes from 192.168.1.2: seq=21 ttl=64 time=2.920 ms 64 bytes from 192.168.1.2: seq=22 ttl=64 time=111.503 ms 64 bytes from 192.168.1.2: seq=23 ttl=64 time=5.721 ms 64 bytes from 192.168.1.2: seq=24 ttl=64 time=3.080 ms 64 bytes from 192.168.1.2: seq=25 ttl=64 time=2.960 ms 64 bytes from 192.168.1.2: seq=26 ttl=64 time=42.341 ms ^C --- 192.168.1.2 ping statistics --- 27 packets transmitted, 27 packets received, 0% packet loss round-trip min/avg/max = 2.720/18.720/111.503 ms root@ICS-HAI:~#

Send me your configuration file and will give it a go over here. Do not worry about the private IPs being a security issue.

I am going to change them over to the IPs I am using here...

OmniPro 2 panel is IP: 192.168.1.2 and LAN IP is 192.168.1.1 and WAN side is 192.168.244.182 configured with a static IP versus doing DHCP.

pic-1.jpg
pic2.jpg
Firewall is PFSense box with Intel Gb interfaces.

I updated firmware on these using the GLi-Net interface to most current. Will post what I see here.

There is an OpenWRT GUI for testing transport and graphing it...go to advanced to get to the OpenWRT Luci web interface.

You should see the link up at 1/2 duplex 10Mbs.

root@ICS-HAI:~# dmesg | grep eth0 | grep up [ 1.700020] mtk_soc_eth 10100000.ethernet eth0 (uninitialized): port 0 link up (100Mbps/Full duplex) [ 1.718218] mtk_soc_eth 10100000.ethernet eth0 (uninitialized): port 4 link up (10Mbps/Half duplex) root@ICS-HAI:~#
 
Last edited:
BTW here yesterday decided to update the Nexx 3030 OpenWRT firmware to 20.XXX. I have updated a few times over the years and never have had issues. A router is a router is a router. It was a mistake this time as I lost all connectivity with this update even though my configuration was the same. Something in the new firmware blocked all traffic from LAN to WAN interface which was odd and first time I have seen this. I downgraded firmware to where I was and all was fine.
 
Last edited:
Some troubleshooting questions from a networking point of view (I don't have an Omni panel):
  • Can you confirm you have the proper subnet masks on every interface on every device?
  • Are you using any Jumbo frames anywhere?
  • Is UPnP disabled on the GL-iNet router (in general, this really should be disabled everywhere)?
  • Does rebooting just the GL-iNet router fix the issue as well?
  • How old is the modem? I've seen some weird behavior with older DOCSIS 2.0 modems
  • Do you see any errors on the LAN or WAN interface on the GL-iNet router using ifconfig -a, netstat -i or netstat -s? Feel free to share the interface counters. I've seen similar behaviors in the past due to firmware/OS bugs where large values may cause this type of degradation.
  • If you have a spare switch, I'd consider plugging it into the LAN side of the GL-iNet router, plug the Omni into the switch, and check if you see this same behavior when pinging from a test machine plugged into that switch.
Thanks for the reply.

This is not a Cable modem, it's AT&T Fiber (PASSTHROUGH).

I don not allow UPnP anywhere, due to security risks.

I'm short on time today to research further, and will review your questions and @pete_c post. Just wanted to acknowledge I appreciate the information and will be getting back to you both.
 
BTW here yesterday decided to update the Nexx 3030 OpenWRT firmware to 20.XXX. I have updated a few times over the years and never have had issues. A router is a router is a router. It was a mistake this time as I lost all connectivity with this update even though my configuration was the same. Something in the new firmware blocked all traffic from LAN to WAN interface which was odd and first time I have seen this. I downgraded firmware to where I was and all was fine.
@pete_c

Don't you hate that?

My Zyxel router has two firmware images, good thing because newer version broke WiFi calling on iPhones, and I had to switch back to previous firmware image at 11:30 PM Friday before Labor Day weekend to make a Cell Call to owner (I'm local point of contact) of Short Term Rental (renters were very loud). I had worked with Zyxel and they wanted me to run newer firmware, meanwhile since we have no cell service on big-3, I can't afford to be out of touch for them to monitor Router, umtil I'm in the office long enough to call forward my cell to AT&T VoIP (which is also having issues due to NVEnergy changing out Power Poles in the area). I just can't keep up with all the issues with utility companies.

I'll get back to you and PM my router backup file. Thanks as always for your help, glad they finally updated COCOOTECH website to SSL, I thought we lost the site for ever (panic).
 
Yes because the Nexx 3020 micro router is sitting between stacked board on the right side of the OmniPro media panel with the cables running down and between the stacked boards. Using the new flat Cat6 short cables for the micro router. The GliNet travel is twice the size of the Nexx WT 3020 microrouter. Never have found another one. That said I have a few hardware modded GliNet routers and use them for my automobile internet these days.

Does AT&T let you bridge to your Fiber connection?

I used to have Verizon FIOS when it was first introduced in FL. Used it for phone, TV and Internet. Two networks. One direct connect to the TV boxes and bridged an Ethernet port for a Linksys WRT router back then all mounted in a closet. I did work with the installer when it was installed as it was a new house and he was going to drill through the master bedroom wall. The comm closet was in the middle of the house. I had run catXX and RG6 cable from that side of the house to the closet during construction. Linksys was in the attic at the time.

So what model of Zyxel router are you using?

Does it have multiple NICs on it? Can you do two WAN ISP connections with it?

A few years ago purchased an LTE modem (with external antenna) which has an RJ11, network ports and WAP built in. I use this as my aux Internet failover connection. Works for me. T-Mobile service.

Also using GV voice with a second VOIP OBI VOIP box which rings all cells and or house phone these days.
 
So after getting the snaplink to work, most of the time, after setting up a micro router, now I get an unrelated error which is a false alarm here and there. It started about two weeks ago with a constant beep telling me all my zones were not ready. After I reset the system, it seemed to work fine. Yesterday at around 7:00 am and then again this morning at 3:54 am I received false alarms (different zone for each). At this point, I have decided to switch to a new brand and have narrowed the choices down to the ELK M1 or DMP. Anyone have any experience with either of these alarm brands and can offer an opinion on which one I should go with?
 
Any specific zones generating false alarms? Is the zones associated with Main Board, or Zone expander? I recently added a new expander, but haven't wired to it yet but one thing I noticed is the headers were never Gold Plated, just wondering if this might be a potential cause. Otherwise possibly a component failure.

I would be curios if it is a specific zone or range of zones.
 
Any specific zones generating false alarms? Is the zones associated with Main Board, or Zone expander? I recently added a new expander, but haven't wired to it yet but one thing I noticed is the headers were never Gold Plated, just wondering if this might be a potential cause. Otherwise possibly a component failure.

I would be curios if it is a specific zone or range of zones.
These were zones off my main board
 
Sounds like a intermittent component on Main Board. I always had problems with Output 1 never working, and even after sending in to HAI around 2004, they made some upgrades to board, never fixed Output 1.

One other suggestion, you might pull EPROM (or EAROM) and re-seat. Again, sockets are not Gold Plated, which was a short cut in my opinion (any time I ever specified a socket in one of my past designs, always used gold plating). During my last go around updating Firmware (4.0b), I accidentally bent a pin, and suffered from intermittent issues, and when I planned to downgrade to previous firmware, I found it (most embarrassing), but not hard to do with the cheap sockets.

Might want to re-seat all chips in sockets, just be careful.
 
Following up on the same thread. I have an OMNIPro II, which the AD didn't want to properly deliver in all its functions. So I'm trying to learn on my own. From the beginning the AD was complaining about the "network". Strangely enough the only device that would ping very slow was the OMNIPro II. All other network devices were fine, including complex remote access via SSH/SSL and LT2P VPN.

The question I have is the following: Judging from the OMNIPro II ping response time, does it make sense to install it behind a local router with a different subnet and configure the port forwarding as advised? Notice the cyclic response going from 3 ms to 344 ms!

OMNIPro II ping times inside the Home LAN:
64 bytes from 192.168.178.7: icmp_seq=0 ttl=64 time=232.378 ms


64 bytes from 192.168.178.7: icmp_seq=1 ttl=64 time=284.918 ms


64 bytes from 192.168.178.7: icmp_seq=2 ttl=64 time=344.160 ms


64 bytes from 192.168.178.7: icmp_seq=3 ttl=64 time=7.145 ms


64 bytes from 192.168.178.7: icmp_seq=4 ttl=64 time=2.952 ms


64 bytes from 192.168.178.7: icmp_seq=5 ttl=64 time=17.721 ms


64 bytes from 192.168.178.7: icmp_seq=6 ttl=64 time=65.175 ms


64 bytes from 192.168.178.7: icmp_seq=7 ttl=64 time=95.027 ms


64 bytes from 192.168.178.7: icmp_seq=8 ttl=64 time=177.758 ms


64 bytes from 192.168.178.7: icmp_seq=9 ttl=64 time=215.674 ms


64 bytes from 192.168.178.7: icmp_seq=10 ttl=64 time=275.758 ms


64 bytes from 192.168.178.7: icmp_seq=11 ttl=64 time=335.171 ms


64 bytes from 192.168.178.7: icmp_seq=12 ttl=64 time=2.959 ms


64 bytes from 192.168.178.7: icmp_seq=13 ttl=64 time=5.343 ms


64 bytes from 192.168.178.7: icmp_seq=14 ttl=64 time=14.278 ms


64 bytes from 192.168.178.7: icmp_seq=15 ttl=64 time=52.446 ms


64 bytes from 192.168.178.7: icmp_seq=16 ttl=64 time=94.134 ms


64 bytes from 192.168.178.7: icmp_seq=17 ttl=64 time=167.216 ms


64 bytes from 192.168.178.7: icmp_seq=18 ttl=64 time=233.011 ms


64 bytes from 192.168.178.7: icmp_seq=19 ttl=64 time=272.441 ms


64 bytes from 192.168.178.7: icmp_seq=20 ttl=64 time=355.871 ms


64 bytes from 192.168.178.7: icmp_seq=21 ttl=64 time=2.970 ms


64 bytes from 192.168.178.7: icmp_seq=22 ttl=64 time=4.804 ms


64 bytes from 192.168.178.7: icmp_seq=23 ttl=64 time=7.925 ms


64 bytes from 192.168.178.7: icmp_seq=24 ttl=64 time=41.689 ms


64 bytes from 192.168.178.7: icmp_seq=25 ttl=64 time=80.647 ms

64 bytes from 192.168.178.7: icmp_seq=26 ttl=64 time=169.391 ms


_______
Comparison with the internal ping to the Windows workstation, hosting PC Access:

64 bytes from 192.168.178.25: icmp_seq=0 ttl=128 time=0.953 ms

64 bytes from 192.168.178.25: icmp_seq=1 ttl=128 time=0.817 ms

64 bytes from 192.168.178.25: icmp_seq=2 ttl=128 time=0.970 ms

64 bytes from 192.168.178.25: icmp_seq=3 ttl=128 time=0.935 ms

64 bytes from 192.168.178.25: icmp_seq=4 ttl=128 time=0.817 ms

64 bytes from 192.168.178.25: icmp_seq=5 ttl=128 time=0.834 ms

64 bytes from 192.168.178.25: icmp_seq=6 ttl=128 time=1.061 ms

64 bytes from 192.168.178.25: icmp_seq=7 ttl=128 time=0.927 ms

64 bytes from 192.168.178.25: icmp_seq=8 ttl=128 time=0.772 ms

64 bytes from 192.168.178.25: icmp_seq=9 ttl=128 time=1.061 ms
 
Here are comparison pings using a micro router with OpenWRT


Code:
BusyBox v1.28.4 () built-in shell (ash)


  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06.4, r7808-ef686b7292
 -----------------------------------------------------

SSH to micro router and ping to HAI OmniPro2 Ethernet interface.

Code:
HAI:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=64 time=4.760 ms
64 bytes from 192.168.1.2: seq=1 ttl=64 time=4.380 ms
64 bytes from 192.168.1.2: seq=2 ttl=64 time=4.460 ms
64 bytes from 192.168.1.2: seq=3 ttl=64 time=4.800 ms
64 bytes from 192.168.1.2: seq=4 ttl=64 time=57.682 ms
64 bytes from 192.168.1.2: seq=5 ttl=64 time=4.400 ms
64 bytes from 192.168.1.2: seq=6 ttl=64 time=4.841 ms
64 bytes from 192.168.1.2: seq=7 ttl=64 time=27.121 ms
64 bytes from 192.168.1.2: seq=8 ttl=64 time=5.741 ms

Main LAN ping from Linux Laptop to Ubuntu server:

Code:
ping 192.168.244.173
PING 192.168.244.173 (192.168.244.173) 56(84) bytes of data.
64 bytes from 192.168.244.173: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 192.168.244.173: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 192.168.244.173: icmp_seq=3 ttl=64 time=0.299 ms
64 bytes from 192.168.244.173: icmp_seq=4 ttl=64 time=0.185 ms
64 bytes from 192.168.244.173: icmp_seq=5 ttl=64 time=0.188 ms
64 bytes from 192.168.244.173: icmp_seq=6 ttl=64 time=0.266 ms
64 bytes from 192.168.244.173: icmp_seq=7 ttl=64 time=0.292 ms
64 bytes from 192.168.244.173: icmp_seq=8 ttl=64 time=0.316 ms

Main LAN ping from Linux Laptop to router connected to OP2

Code:
ping 192.168.244.182
PING 192.168.244.182 (192.168.244.182) 56(84) bytes of data.
64 bytes from 192.168.244.182: icmp_seq=1 ttl=64 time=0.632 ms
64 bytes from 192.168.244.182: icmp_seq=2 ttl=64 time=0.408 ms
64 bytes from 192.168.244.182: icmp_seq=3 ttl=64 time=0.402 ms
64 bytes from 192.168.244.182: icmp_seq=4 ttl=64 time=0.407 ms
64 bytes from 192.168.244.182: icmp_seq=5 ttl=64 time=0.411 ms
64 bytes from 192.168.244.182: icmp_seq=6 ttl=64 time=0.442 ms
64 bytes from 192.168.244.182: icmp_seq=7 ttl=64 time=0.424 ms
64 bytes from 192.168.244.182: icmp_seq=8 ttl=64 time=0.383 ms


Judging from the OMNIPro II ping response time, does it make sense to install it behind a local router with a different subnet and configure the port forwarding as advised?

If you have any Ethernet port issues with your OmniPro 2 panel then a router will help.

I have done this now for over 5 years and have not had any issues relating to the OP2 Ethernet port and serial connections and loss of time sync.

Best to give it a try with any old SOHO router you may have around.
 
Last edited:
Here are comparison pings using a micro router with OpenWRT


Code:
BusyBox v1.28.4 () built-in shell (ash)


  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06.4, r7808-ef686b7292
 -----------------------------------------------------

SSH to micro router and ping to HAI OmniPro2 Ethernet interface.

Code:
HAI:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=64 time=4.760 ms
64 bytes from 192.168.1.2: seq=1 ttl=64 time=4.380 ms
64 bytes from 192.168.1.2: seq=2 ttl=64 time=4.460 ms
64 bytes from 192.168.1.2: seq=3 ttl=64 time=4.800 ms
64 bytes from 192.168.1.2: seq=4 ttl=64 time=57.682 ms
64 bytes from 192.168.1.2: seq=5 ttl=64 time=4.400 ms
64 bytes from 192.168.1.2: seq=6 ttl=64 time=4.841 ms
64 bytes from 192.168.1.2: seq=7 ttl=64 time=27.121 ms
64 bytes from 192.168.1.2: seq=8 ttl=64 time=5.741 ms

Main LAN ping from Linux Laptop to Ubuntu server:

Code:
ping 192.168.244.173
PING 192.168.244.173 (192.168.244.173) 56(84) bytes of data.
64 bytes from 192.168.244.173: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 192.168.244.173: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 192.168.244.173: icmp_seq=3 ttl=64 time=0.299 ms
64 bytes from 192.168.244.173: icmp_seq=4 ttl=64 time=0.185 ms
64 bytes from 192.168.244.173: icmp_seq=5 ttl=64 time=0.188 ms
64 bytes from 192.168.244.173: icmp_seq=6 ttl=64 time=0.266 ms
64 bytes from 192.168.244.173: icmp_seq=7 ttl=64 time=0.292 ms
64 bytes from 192.168.244.173: icmp_seq=8 ttl=64 time=0.316 ms

Main LAN ping from Linux Laptop to router connected to OP2

Code:
ping 192.168.244.182
PING 192.168.244.182 (192.168.244.182) 56(84) bytes of data.
64 bytes from 192.168.244.182: icmp_seq=1 ttl=64 time=0.632 ms
64 bytes from 192.168.244.182: icmp_seq=2 ttl=64 time=0.408 ms
64 bytes from 192.168.244.182: icmp_seq=3 ttl=64 time=0.402 ms
64 bytes from 192.168.244.182: icmp_seq=4 ttl=64 time=0.407 ms
64 bytes from 192.168.244.182: icmp_seq=5 ttl=64 time=0.411 ms
64 bytes from 192.168.244.182: icmp_seq=6 ttl=64 time=0.442 ms
64 bytes from 192.168.244.182: icmp_seq=7 ttl=64 time=0.424 ms
64 bytes from 192.168.244.182: icmp_seq=8 ttl=64 time=0.383 ms


Judging from the OMNIPro II ping response time, does it make sense to install it behind a local router with a different subnet and configure the port forwarding as advised?

If you have any Ethernet port issues with your OmniPro 2 panel then a router will help.

I have done this now for over 5 years and have not had any issues relating to the OP2 Ethernet port and serial connections and loss of time sync.

Best to give it a try with any old SOHO router you may have around.
Thank Pete you for your quick feedback. I'm located in Europe and soon enough a Fritzbox router will be redundant. In the cellar there is a big rack that houses the Patch Panels, Switch, Servers etc. That router is currently used as an access point. When a professional grade AP will be installed, that router will "firewall" the OMNIPro II.
 
I finally firewalled the OMNI with an Apple Time Capsule. It used to be in bridged mode. I configured it as a router with own IP-range and did setup the port forwarding. I also discovered that the FritzBox would connect in the central LAN with static ip 192.168.1.1, that is the range I did set up for the TC. Obviously this is nonsense and I reset the Fritzbox to DHCP with the master.

Overall the OMNIPro II seems to have a more stable connection and I was able to update it to the latest firmware 4.0b over UDP connection only.
 
Back
Top