My Obi110 recently started going off line. It's fine for 10 minutes or so after cycling the power but then the phone light goes dark and it looses it's connection. I can still call in to the device from the phone tough. I replaced both the phone and ethernet cable and have tried a different port on my switch. So I ordered a new Obi100 and the exact same thing happens. So I have replaced 100% of the hardware except the switch and the router. I have made no configuration changes to either my router or my switch. The reply I get from a ping is "destination host unreachable". Where do I begin?
Begin at the beginning.
Do you configure the device using the Obitalk portal or via the device's own web server GUI?
Do you run your OBi with a static or dynamic IP address.
An OBi will give dial tone and respond to *** numbers from an attached phone even if there is nothing plugged in to its ethernet port.
Does power cycling you router have any effect?
I'm using the portal.
It has a dynamic IP.
Power cycling the router doesn't help.
I would like to emphasize that the device works for a few minutes after power cycling and then goes dark. During this process the IP address does not change.
Quote from: S--F on June 30, 2015, 12:25:44 AM
So I ordered a new Obi100 and the exact same thing happens.
Did you use the old power supply from the original Obi100? The power supply is a known failure point (especially) for older devices.
No. At first I used the old power supply but then moved to the new one when things didn't stabilize. So The power supply has been removed from the equation.
No phone led AND no communication with the outside world. The power and network led's are still alive and kicking.
The phone LED will turn off when SP1 is un-registered to a service provider, so it is functioning correctly if your OBi100 is losing contact with the router.
Try a different router. If you don't have an extra router, can you take the OBi100 to a friend's house and try their router?
I tracked the problem down to a network intrusion monitor that is part of my home automation system. It pings every address on the subnet every minute. Once I disabled this everything works fine. I will try to work with the author of the utility, but does anyone have an idea why a simple ping would do this to both an Obi100 and an Obi110?
I'm having this same issue, see this post.
https://www.obitalk.com/forum/index.php?topic=10056.0
Even after disabling all the Obi provisioning settings got off line after several days.
Quote from: S--F on July 02, 2015, 08:09:22 AM
I tracked the problem down to a network intrusion monitor that is part of my home automation system. It pings every address on the subnet every minute. Once I disabled this everything works fine. I will try to work with the author of the utility, but does anyone have an idea why a simple ping would do this to both an Obi100 and an Obi110?
A simply ping would nominally not take an Obi device offline. Does your monitor also attempt additional detection (such as running port scans), or move beyond monitoring to active blocking attempts?
Quote from: RFC3261 on July 02, 2015, 05:48:15 PM
A simply ping would nominally not take an Obi device offline. Does your monitor also attempt additional detection (such as running port scans), or move beyond monitoring to active blocking attempts?
This is what the author of the utility has to say on the matter:
QuoteIt's just a ping but I do send multiple pings out at the same time (to different IP addresses) rather than sequentially.
You could try pinging your obi's IP address from a windoze command prompt & see what happens.
ping -t xxx.xxx.xx.xx
-t : Specifies that ping continue sending Echo Request messages to the destination until interrupted. To interrupt and display statistics, press CTRL-BREAK. To interrupt and quit ping, press CTRL-C.
Quote from: zorlac on July 03, 2015, 10:50:58 PM
You could try pinging your obi's IP address from a windoze command prompt & see what happens.
ping -t xxx.xxx.xx.xx
-t : Specifies that ping continue sending Echo Request messages to the destination until interrupted. To interrupt and display statistics, press CTRL-BREAK. To interrupt and quit ping, press CTRL-C.
Well I tried this. I let it ping the Obi100 over 1,000 times. It's still up and running fine. So it's gotta be something else. This is really weird.
Quote from: S--F on July 02, 2015, 08:09:22 AM
I tracked the problem down to a network intrusion monitor that is part of my home automation system. It pings every address on the subnet every minute. Once I disabled this everything works fine. I will try to work with the author of the utility, but does anyone have an idea why a simple ping would do this to both an Obi100 and an Obi110?
Well, if you've proven that the above is the cause, then why do you expect that the problem would go away, as long as you're using that system?
You can take your OBi adapter to some other location (friend or family member's house for example) and confirm the theory.
Quote from: SteveInWA on July 11, 2015, 02:41:43 PM
Well, if you've proven that the above is the cause, then why do you expect that the problem would go away, as long as you're using that system?
You can take your OBi adapter to some other location (friend or family member's house for example) and confirm the theory.
I'm not sure I'm following you here. The first part, I don't expect the problem to magically disappear. I would like to understand why it's happening though. If it's just a ping then my experiment today would have crashed the device since I was pinging it once a second and the network intrusion monitor only pings once per minute. For the second part, what would I gain by bringing the device to a different network? What theory would I be confirming? Sorry. I'm not trying to be difficult. I really just don't quite understand what you're getting at.
What am I getting at?
You said:
Quote
I tracked the problem down to a network intrusion monitor that is part of my home automation system. It pings every address on the subnet every minute. Once I disabled this everything works fine.
We don't know what other things, pinging or otherwise, that your network monitor may or may not be doing, only that the network monitor is definitely the cause of the problem. We don't know if the true, root cause is the constant pinging by the monitor, or something else it does - that was your assumption, which you then disproved by running manual pings. But, you proved that disabling the monitor stopped the problem, so it's incompatible with your OBi device. Nobody else here on the forum has chimed in to report that they happen to have the same system, and here is
why it is incompatible; we have no idea.
So: it's like going to the auto mechanic. You say, "I have a moat around my house. When I try to drive through it, my car's engine dies. The mechanic replies: "Well then, don't do that."
Well yes, of course. I have disabled the network monitor. The phone is more important to me. But! I'm sure the developer of the utility would like to know what's going on so it can be addressed. I removed the ip of the Obi from the eyes of the network monitor and it still took down the Obi. And of course, the ping experiment today showed that pinging it doesn't kill it. So it must be something to do with the rest of the network.
Aren't you curious as to why this happens? No other devices on the network fall over like this. Not the Unifi APs or the switch or anything. If I can't get to the bottom of this I'm probably just going to toss the Obi on a VLAN and call it a day so I can keep using the network monitor. But it seems odd that simply pinging a bunch of ip addresses on the network would make the Obi go south.
If I were that mechanic I would have said something along the lines of "build a drawbridge". If you want your moat and to put your car in the garage we have time tested technology to get you there. In my case, I can't see the moat to know it for what it is. All I know is that my car stalls when I try to come home. :(
Oh. And I should add. The network monitor does absolutely nothing more than ping. It does send out multiple pings at once but it doesn't do anything else.
It might be worth starting a syslog & enabling the Obi to report to it:
https://www.obitalk.com/forum/index.php?topic=707.0 (https://www.obitalk.com/forum/index.php?topic=707.0)
You'll need another device (such as a windows PC) running on your network to run the syslog - once the syslog is running & reporting enabled on the Obi, re-enable the network monitor & see if anything interesting is reported before the Obi becomes unresponsive to the network.
If the network monitor can be so configured, try reducing the ping frequency to every 5 minutes & see if that has any affect.
Your router's own system log might also have some clues, though this depends on the router.
Quote
But it seems odd that simply pinging a bunch of ip addresses on the network would make the Obi go south.
No, you proved that this is
not the cause of the problem.You
have proven that some other function (not the pings) of your particular network security product is causing the problem. Nobody here has that same equipment, which is what would be required to perform more in-depth testing.
Quote
But! I'm sure the developer of the utility would like to know what's going on so it can be addressed.
That company's engineers would be the only ones who could determine what's going on. They'd need to obtain an OBi, or work with you, to enable detailed debugging/logging on their product, and then study what behavior (ports being opened, protocols being used, etc.) are being interpreted by their equipment as an intrusion that needs to be blocked. You claim that their product is merely pinging the network, but you haven't instrumented your network to truly know that's the case. Modern network security software/hardware uses a variety of (sometimes proprietary) techniques to attempt to protect the network. I had suggested taking the OBi to some other network location as another data point to confirm that your network gear is, in fact, the culprit.
Quote
Aren't you curious as to why this happens?
I'm curious about a lot of things, among them:
- What causes Alzheimer's disease, why do some people get it and not others, and what can be done to prevent it?
- How many other planets have intelligent life? Why haven't we found one yet?
- Why do house cats mysteriously go into a frenzy sometimes, running around the house aroused, and then calm down?
- Why are so many people interested in the Kardashians?
I'm not curious why your particular network gear disrupts OBi use, since this has not been a widespread issue impacting OBi users. Perhaps somebody else is curious.
Since you have apparently found a compromise solution that will enable your devices to coexist (put the OBi in a VLAN), then I'd say it's a non-issue.
Nice idea! I already run a syslog server here. I capture logs from the router as ell as the WiFi access points. I'll be sure to add the Obi100. Though I have yet to look at your link :/
Quote from: S--F on July 11, 2015, 05:33:08 PM
Nice idea! I already run a syslog server here. I capture logs from the router as ell as the WiFi access points. I'll be sure to add the Obi100. Though I have yet to look at your link :/
The link is to a post from Obihai describing how to set up a syslog for Obi & pointing to a syslog program that they provide - provided in case you (or anyone else interested) needed that info.
Is the OBi the only device that goes off-line when the network monitor is run?
Perhaps your router interprets constant pinging as an 'attack' and takes some defensive action. What happens if you run your 'manual pinger' against the router's IP address?
Quote from: drgeoff on July 12, 2015, 05:19:35 AM
Is the OBi the only device that goes off-line when the network monitor is run?
Perhaps your router interprets constant pinging as an 'attack' and takes some defensive action. What happens if you run your 'manual pinger' against the router's IP address?
Yeah, the Obi is the only device that crashes. I am planning on some more experimenting later today and pinging the pants off the router is already on the menu. I'll report back with my findings later today.
One more bit of info on how the network monitor operates. It pings 10 addresses at a time. So, all it does is ping. Nothing else. And it pings all 256 addresses sequentially, 10 at a time.
I turned the network monitor on and then captured all of the logs until the device went offline. The only ting interesting to me was that about every 30 seconds I get the message "Err:MissingReqHdr". Here they are:
2015-07-12 09:32:17 0 Debug 192.168.1.114 syslog TCP:Except state=1(pnn) 5
2015-07-12 09:31:02 0 Debug 192.168.1.114 syslog PNN:NewUDP[3]:10060
2015-07-12 09:30:54 0 Debug 192.168.1.114 syslog PNN:NewUDP[2]:10052
2015-07-12 09:30:46 0 Debug 192.168.1.114 syslog PNN:NewUDP[1]:10045
2015-07-12 09:27:22 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:26:51 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:26:21 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:25:51 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:25:21 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:24:50 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:24:20 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:23:50 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:23:20 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:22:50 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:22:19 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:21:49 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:21:19 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:20:49 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:20:19 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:19:48 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:19:18 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:18:48 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:18:18 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:17:47 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:17:17 1 Notice SIP/2.0 syslog 200 OK
2015-07-12 09:17:17 0 Debug sendto syslog 340a2311:8891(347)
2015-07-12 09:17:17 1 Notice NOTIFY syslog sip:3523@xx.xxx.xx.xxx:xxxxSIP/2.0
2015-07-12 09:17:17 0 Debug 192.168.1.114 syslog RxFrom:340a2311:8891
2015-07-12 09:17:17 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:16:47 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:16:17 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:15:46 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:15:16 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:14:46 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:14:16 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:13:46 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:13:15 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:12:45 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:12:15 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:11:45 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:11:15 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:10:44 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:10:14 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:09:44 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:09:14 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:08:43 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:08:13 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:07:43 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:07:13 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:06:43 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:06:12 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:05:42 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:05:12 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:04:42 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:04:11 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:03:41 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:03:11 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:02:41 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:02:10 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:01:40 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:01:10 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:00:40 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 09:00:10 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:59:39 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:59:09 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:58:39 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:58:09 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:57:38 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:57:08 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:56:38 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:56:08 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:55:38 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:55:07 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:54:37 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:54:07 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:53:37 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:53:06 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:52:36 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:52:06 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:51:36 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:51:06 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:50:35 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:50:05 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:49:35 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:49:05 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:48:34 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:48:04 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:47:34 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:47:04 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:46:33 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:46:03 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:45:33 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:45:03 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:44:33 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:44:02 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:43:50 0 Debug [PR] prompt transcoding done!!
2015-07-12 08:43:32 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:43:02 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:42:32 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:42:02 0 Debug [CPT] tone compression done - 12403 !!
2015-07-12 08:42:02 0 Debug SIP syslog Err:MissingReqHdr
2015-07-12 08:42:00 18 Informational Same version Skipped
2015-07-12 08:42:00 18 Notice 192.168.1.114 PROV Auto Provision is disabled!
2015-07-12 08:42:00 18 Informational 192.168.1.114 PROV Update Config Now, ITSP: 1...
2015-07-12 08:42:00 17 Emergency XML_parse_prov 0
2015-07-12 08:42:00 18 Informational 192.168.1.114 PROV Update Config Now, ITSP: 1...
2015-07-12 08:42:00 19 Error Set Overall Timeout 600 seconds
2015-07-12 08:42:00 0 Debug 192.168.1.114 syslog TCP:Connect OK(HTTP GET)16
2015-07-12 08:42:00 18 Informational 192.168.1.114 PROV Start to download files ...
2015-07-12 08:41:57 0 Debug [CPT] syslog --- FXS s/w tone generator (sit_1) ---
2015-07-12 08:41:51 1 Notice SIP/2.0 syslog 200 OK
2015-07-12 08:41:51 0 Debug sendto syslog 340a2311:8891(379)
2015-07-12 08:41:51 0 Debug +++ mwi notify state 0
2015-07-12 08:41:51 1 Notice NOTIFY syslog sip:3523@xx.xxx.xx.xxx:xxxxSIP/2.0
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog RxFrom:340a2311:8891
2015-07-12 08:41:51 1 Notice SIP/2.0 syslog 202 OK
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog RxFrom:340a2311:8891
2015-07-12 08:41:51 1 Notice SUBSCRIBE syslog sip:3523@sms.intelafone.com:8891 SIP/2.0
2015-07-12 08:41:51 0 Debug sendto syslog 340a2311:8891(636)
2015-07-12 08:41:51 1 Notice SIP/2.0 syslog 407 Proxy Authentication Required
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog RxFrom:340a2311:8891
2015-07-12 08:41:51 1 Notice SUBSCRIBE syslog sip:3523@sms.intelafone.com:8891 SIP/2.0
2015-07-12 08:41:51 0 Debug sendto syslog 340a2311:8891(426)
2015-07-12 08:41:51 1 Notice SIP/2.0 syslog 200 OK
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog RxFrom:340a2311:8891
2015-07-12 08:41:51 1 Notice REGISTER syslog sip:sms.intelafone.com:8891 SIP/2.0
2015-07-12 08:41:51 0 Debug sendto syslog 340a2311:8891(739)
2015-07-12 08:41:51 1 Notice SIP/2.0 syslog 401 Unauthorized
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog RxFrom:340a2311:8891
2015-07-12 08:41:51 1 Notice REGISTER syslog sip:sms.intelafone.com:8891 SIP/2.0
2015-07-12 08:41:51 0 Debug sendto syslog 340a2311:8891(540)
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog REG:Create 0
2015-07-12 08:41:51 0 Debug 192.168.1.114 syslog [SLIC]:Slic#0 ON HOOK
2015-07-12 08:41:50 0 Debug 192.168.1.114 syslog BASESSL:Load certificate ok
2015-07-12 08:41:50 0 Debug 192.168.1.114 syslog BASESSL:load cert:8
2015-07-12 08:41:50 0 Debug [CPT] syslog --- FXS s/w tone generator (ringback) ---
2015-07-12 08:41:50 0 Debug [SLIC] DAA command with wrong id 0, 2, 0, 0, 0, 0
2015-07-12 08:41:50 0 Debug Voice syslog Main
2015-07-12 08:41:50 0 Informational Start Main Service Now
2015-07-12 08:41:48 0 Emergency SLIC & DAA is initialized
2015-07-12 08:41:46 18 Informational Setup Provisioning for system start! 1400
2015-07-12 08:41:46 0 Emergency Reset syslog SLIC...
2015-07-12 08:41:46 0 Emergency SLIC_init syslog ...
2015-07-12 08:41:46 21 Notice 192.168.1.114 ZT CustomID 1
2015-07-12 08:41:46 0 Error SYSTEM REBOOTED (Reason 4, lifecycle: 585)
2015-07-12 08:41:46 0 Emergency Netmask = 255.255.255.0
2015-07-12 08:41:46 0 Emergency Gateway = 192.168.1.1
2015-07-12 08:41:46 0 Emergency IP Address= 192.168.1.114
2015-07-12 08:41:46 0 Informational ==== Networking is ready ====
Is this enlightening to anyone?
Quote from: S--F on July 12, 2015, 06:45:22 AM
I turned the network monitor on and then captured all of the logs until the device went offline. The only ting interesting to me was that about every 30 seconds I get the message "Err:MissingReqHdr".
Which sort of suggests that something (perhaps the network monitor software) is doing more than just a "ping" every minute as you were promised. Perhaps you should run a network span port (or tcpdump on the host running the monitor software) to see if that software is the cause. If so, you might want to reevaluate the statements from the author and whether that is the software for you.