Omni IIe network repair

There is no intelligence in the Omni ethernet port. 
 
I can ping and arp the IP here of the port via SSH firewall even though it's a dumb interface.
 
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=64 time=15.181 ms
64 bytes from 192.168.1.2: seq=1 ttl=64 time=2.900 ms
 
root@ICS-HAI:~# arp 192.168.1.2

IP address       HW type     Flags       HW address            Mask     Device192.168.244.172  0x1         0x2         28:d2:44:c3:84:7e     *        eth0.2192.168.244.171  0x1         0x2         74:d4:35:e1:13:c1     *        eth0.2192.168.1.2      0x1         0x2         00:07:88:00:33:66     *        br-lan
Did this just occur recently after years?
 
The email board is using a separate ethernet port connected to one of the serial ports.

I have my PCA configuration set to TCP. May be try setting yours to UDP?

Windows 10 by default blocks a bunch of stuff.  Do you have an RPi around or a way to utilize Linux.  You could boot up in a Linux live ISO and use ping there too to give it a try.
 
Also check you IP or maybe change it in PCA and make sure that you are on the same subnet when testing the PINGs.  Note if your laptop is configured to get a DHCP address this will not work.  For a laptop to Omni connection you need to configure a static IP on your laptop and not use DHCP.

Here still in the legacy way of doing my network and have a very small DHCP scope.
 
I think I will try a Pi, just in case Windows is messing with me and I don't know it.  Besides, I can update the ARP table on it.
 
But to answer your questions, this worked when installed (2007) and I used it off and on for some number of years with no trouble.  It has been idle now for another number of years, exactly how many I don't know.  I got interested recently when I found out about the email notifier, since I would like to get notified of events and not pay for monitoring.  And of course, I try to connect over the network and it no longer works.  I did get everything set up, but had to use the serial port instead.
 
What bums me about sending the board to Leviton is it is not the cost, it was the hassle of completely disassembling the unit and making sure I could hook it back up exactly the way it was.  Hopefully, they will let me send it in again and this time pay more attention to it.
 
If it is just a matter of replacing the ethernet chip, I can do that.  Probably cheaper and quicker than sending it back in...
 
Thanks,
Bill
 
I am sure you are aware relating to the cabling / wiring that you can just lift the terminals up and off to do all at once in groups (with the battery and power supply disconnected).  Here upgraded my OmniPro 2 panel board doing it this way which was faster than disconnecting each of the terminals (well too have two zone extenders over main board).
 
Yeah over the last 20 years have only sent one board in for repairs.  It was a new board and I fat fingered it initially powering up and it went up in smoke.
 
I have seen a couple of boards with the large capacitor next to the power pieces of the board leaking or exploding.  Only two boards over the last 20 years.
 
The network chip is surface mounted (I think) and old.  You can remove it carefully using a hot air gun and solder a new one using a tiny tip soldering iron under a magnifying glass with some flux on it (using a flux pen). I have though never heard of any owners of the OmniBoard doing this with their panels.
 
It would be much easier to have a chat with the support folks and concurrently send them your pings to show them what the issue is and then when they repair it having them send the same ping stuff to your. 
 
Had to step away and lost my train of thought here...
 
OK, tried the same experiment with a Pi.  The Pi goes through a network tap, then a crossover cable to the Omni.  No other devices.
 
Initially, attempting to ping the Omni, the only thing the Pi was sending was arp request for the Omni mac address.  I then tried updating the arp table on the Pi, and then the Pi would send pings.  In neither case would the Omni reply at all.
 
I found some of the ethernet controllers at Future Electronics for $3.49, so I could not resist.  I should hear back from Leviton before they arrive, but seems like a very simple experiment to just swap that chip.  I am all setup for surface mount repair here, so it is no big deal to change that chip.
 
I took another look at the terminal strips on the Omni.  I did not know they unplugged, and I still could not see how to do it.  When I removed the board last time, I transferred each wire to some other terminal strips, one by one.  Then reversed the procedure when I got the board back.  Not too painful, but it keeps me from making mistakes.
 
Bill
 
Yes there are little clips that pull away from the terminal strip (8 screws).  Just go slow the grab the entire terminal strip and pull up.
 
Good news on the NIC chip.  You will be the first doing this.
 
I am guessing too that you have tested the cable too.
 
Please take pictures if you do this.
 
After some more experimenting, I have gotten very different results.

From my laptop, Wireshark sees no return traffic from the Omni, although it did get a reply to its arp, and it was able to send pings. None of the pings were answered.

From the Pi, it gets replies to most of its pings, losing 5% or of the packets. This is actually pretty good.

I am starting to suspect that the Omni input is not recognized. Maybe it needs a bit more amplitude than my laptop outputs. The Pi has a 100M interface, the laptop has a Gb interface and maybe its output levels are a bit higher. Now I think I need to redo all my experiments, as I don’t trust any of my previous conclusions.
 
Well, I am going to chock this up to getting old.
 
What I found is that nothing with a Gb interface, whether a laptop, desktop, or switch can talk to the Omni.  Even when these devices are manually set for 10M half duplex.  They all can auto negotiate and all find the interface to be 10M half duplex, but still cannot be heard by the Omni.  I am not sure I have any way to verify this, but I suspect that the amplitude of the Gb interfaces is lower than that of a 100M/10M signal.
 
I don't have any 10M switches here, nor any 100M switches.  I have tried my main 24 port Netgear (unmanaged), a Dell 16 port managed switch, an 8 port D-link unmanaged and a 5 port Zyxel managed switch.  None of them work.  I believe this is why I initially would get some responses to pings like 1 out of 50 or so.
 
I found I could ping the Omni from a Pi when directly connected via crossover cable.  So, I installed IPFire onto a different Pi.  It has wireless on its WAN side and the wired side goes to the Omni.  Even though this is a different Pi than I originally used to ping the Omni, its network has what it takes to be seen by the Omni.  I set the IPFire to port forward and now I can connect from both of my main computers.
 
Just to complicate matters though, apparently Leviton felt they needed to change my encryption keys.  But getting the message that my keys did not match was a very good sign!
 
I wonder if the other threads about firewalling the Omni were really the same issue I had.  In other words, would a Gb firewall work or not?
 
Maybe I can find an old 100M switch to try.  At any rate, end of a very long story.
 
Good news!
 
The router (IPFire) trick is a bandaid fix. (layer 2 to layer 3 to layer 2).

The old NIC on the board is too promiscuous and sees everthing which is bad when you have many devices on your home LAN.
 
I tried fixing my networking issues with a managed switch, vlan, old 10Mbs hub.  Nothing worked until I used a router. Then just updated a Nexx travel router with OpenWRT, disabled IP6, disabled WLAN and I was good to go.

You can power the router from the panel or use a POE connection.
 
That said though the NIC problems were slow to start and initially just saw my time going off by the hour, then saw serial issues with my OmniTouch screens and my Omnistat thermostat and finally the network port would just disconnect. 
 
sshing to router see:
 
/sys/class/net# dmesg | grep -i duplex
[    1.694697] mtk_soc_eth 10100000.ethernet eth0 (uninitialized): port 0 link up (100Mbps/Full duplex)
[    1.712893] mtk_soc_eth 10100000.ethernet eth0 (uninitialized): port 4 link up (10Mbps/Half duplex)
 
 
The ethernet standards evolved pretty quickly back in the 80s and 90s. Back then, there were often problems with 10 mbps chips that couldn't communicate with newer, 100 mbps chips, even though they were configured for the slower speed. Although there was a "standard," different designers interpreted some the language a little bit differently, and the result was incompatibilities. Often between one brand and another, but sometimes even with two products from the same manufacturer. This still happens sometimes, even today. They are getting better at writing clearer language in the standards, but it's still not easy.

When newer standards come along, there are often plugfests to allow manufacturers to bring their latest products and test them out when connected to other equipment. It helps to weed out problems, but there is so much hardware out there, it's impossible to test everything against everything else. One thing that does help is that today, designers can buy a fully designed ethernet interface as a logic library component and plop it down on a new chip that is being designed. So there are fewer designed-from-the-ground-up instances, which greatly improves compatibility.

It doesn't surprise me that an interface chip in something as old as the Omni might have trouble connecting with newer hardware. I suspect that's the source of the problems and not anything to do with signal levels.
 
Leviton got back to me and offered to send me a replacement board for $150.  I could try the replacement before sending mine back to them.  This sounded like a pretty good deal.
 
However, in my search for a simple solution, recognizing that it looked like any interface that was 1G capable could not negotiate a 10M link with the Omni, I decided to try one more experiment.  I bought a really cheap TP-Link TL-SF1005D 10/100 switch ($10).  If I put it in line with the Omni, it talks just fine, even on my main network.  At least in my case, it appears that the traffic on the network has nothing to do with why I could not talk, it is the type of ethernet that was connected to it.
 
So, I have tried and failed with:
  1. Netgear ProSafe 24 port unmanaged switch, model JGS524
  2. Dell PowerConnect 2716 16 port managed switch
  3. D-Link DGS-1008D unmanaged switch
  4. Zyxel GS1200-5 managed switch
  5. Dell Latitude E5520 computer
For the managed switches and the computer, I could force the interface to 10M half-duplex and yet neither would work.
 
I tried 2 different Raspberry Pi computers, and both of them worked fine (their interfaces are 10/100).  Also the TP-Link switch works fine talking from a variety of computers (its interface is also 10/100).  I even turned one of the Pis into a router and could run PC Access through it.  So, I guess I conclude it is some kind of electrical incompatibility with the 1G interfaces that the Omni just does not like.  Now I wonder if way back when, I had it connected to a 10/100 switch and just did not realize how important that was.
 
For me, the cheapest and dirtiest solution is the $10 switch.
 
I provided all my information to Leviton to see what they think.  My question to them is whether my unit is performing the way it should or whether there is still a hardware problem.
 
Thanks all for your help.
Bill
 
fitch said:
Leviton got back to me and offered to send me a replacement board for $150.  I could try the replacement before sending mine back to them.  This sounded like a pretty good deal.
 
However, in my search for a simple solution, recognizing that it looked like any interface that was 1G capable could not negotiate a 10M link with the Omni, I decided to try one more experiment.  I bought a really cheap TP-Link TL-SF1005D 10/100 switch ($10).  If I put it in line with the Omni, it talks just fine, even on my main network.  At least in my case, it appears that the traffic on the network has nothing to do with why I could not talk, it is the type of ethernet that was connected to it.
 
So, I have tried and failed with:
  1. Netgear ProSafe 24 port unmanaged switch, model JGS524
  2. Dell PowerConnect 2716 16 port managed switch
  3. D-Link DGS-1008D unmanaged switch
  4. Zyxel GS1200-5 managed switch
  5. Dell Latitude E5520 computer
For the managed switches and the computer, I could force the interface to 10M half-duplex and yet neither would work.
 
I tried 2 different Raspberry Pi computers, and both of them worked fine (their interfaces are 10/100).  Also the TP-Link switch works fine talking from a variety of computers (its interface is also 10/100).  I even turned one of the Pis into a router and could run PC Access through it.  So, I guess I conclude it is some kind of electrical incompatibility with the 1G interfaces that the Omni just does not like.  Now I wonder if way back when, I had it connected to a 10/100 switch and just did not realize how important that was.
 
For me, the cheapest and dirtiest solution is the $10 switch.
 
I provided all my information to Leviton to see what they think.  My question to them is whether my unit is performing the way it should or whether there is still a hardware problem.
 
Thanks all for your help.
Bill
 
Good that you've got an inexpensive solution.  I strongly suspect that if you took Leviton up on their offer, the new board might not work any better, assuming that they are still using the same ethernet interface chip.
 
Back
Top