VeraConcierge to Vera Local Connectivity Check Failure

ntynen · February 10, 2019, 7:41pm

Hi,

We recently upgraded our Raspberry PI to Raspbian GNU/Linux 9.

I have installed and configured Vera Concierge. However, when I test connectivity locally between the server and the Vera I get a message saying I must be running a firewall on the local Vera Concierge server.

When itables was installed it was default accept everything. To be sure I uninstalled iptables. Still getting that error.

Then I tried to telnet to ports reported in the error message: 8998 and 8989. Sure enough I can’t connect.

Running nmap against my VeraLite I only see this:

[code]pi@pifi:/usr/local/vera_concierge $ nmap xxx.xxx.xxx.xx

Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-10 11:25 PST
Nmap scan report for xxx.xxx.xxx.xx
Host is up (0.0011s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
[/code]

The only thing I can see on the Vera is to enable UPnP which I did but that still didn’t open those ports.

VeraLite firmware version: 1.7.1040
Raspberry PI: Raspbian GNU/Linux 9
Vera Concierge Version: 2.0.31

From the logs:

Exception:java.net.SocketTimeoutException: Read timed out java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:170) at java.net.SocketInputStream.read(SocketInputStream.java:141) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at com.rtsservices.veraconnect.access.VeraGateway.URLConnection(VeraGateway.java:115)

Feb 10, 2019 12:14:08 PM I:VeraConnect.VeraGateway:URLConnection:http://xxx.xxx.xx.xx/port_3480/data_request?&id=variableget&Variable=PK_AccessPoint

This URL call returns the ID of my VeraLite, however,

Feb 10, 2019 12:14:08 PM I:VeraConnect.VeraGateway:URLConnection:http://xxx.xxx.xx.xx/port_3480/data_request?id=lr_VCSProxy&Request=%2FQuery%3FDiscovered

This URL call returns

Handler failed

I searched the forum and couldn’t find anything specific to this issue. If I missed a post please provide the link. I’ll continue my search.

Thanks,
Nicci

Catman · February 11, 2019, 11:01am

Did you drop all the rules before you un-installed iptables? If not, they’ll still be active as (at least by my understanding) iptables is only a tool to modify the firewall that exists in the kernel.
You might find a reboot clears it, but I doubt it.
If not, re-install ipdatbles then:
iptables -L

Will list all the rules. That will at least confirm the issue

iptables -F

Should flush them all

C

ntynen · February 11, 2019, 4:20pm

Hi,

I did iptables -L and the rules were all ACCEPT.

So flushing the rules should have had no affect. I can try it though.

Catman · February 11, 2019, 5:14pm

[quote=“ntynen, post:3, topic:200577”]Hi,

I did iptables -L and the rules were all ACCEPT.

So flushing the rules should have had no affect. I can try it though.[/quote]

What happens on the pi if you telnet 127.0.0.1 on the ports specified?

Also what do you get if you telnet from Vera to the Pi on the ports specified?

You could post the result of iptables -L as well

C

ntynen · February 12, 2019, 9:16pm

OK I finally gained ssh access to my VeraLite to do more testing.

Here is the output of iptables -L on the raspberry pi ; you can see it was ACCEPT before, but I ran a flush just in case

pi@pifi:~ $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
pi@pifi:~ $ sudo iptables -F
pi@pifi:~ $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

root@MiOS_35026097:~# telnet 192.xxx.xx.xx 8998 Connection closed by foreign host

But I can telnet to the ports on the Raspberry Pi from another host on the same network.

ntynen@penguin:~$ telnet 192.xxx.xx.xx 8989 Trying 192.xxx.xx.xx... Connected to 192.xxx.xx.xx. Escape character is '^]'.

ntynen@penguin:~$ telnet 192.xxx.xx.xx 8998 Trying 192.xxx.xx.xx... Connected to 192.xxx.xx.xx. Escape character is '^]'

I’ve stopped the firewall completely on the VeraLite, no change in behavior. I do not have “Secure Vera” enabled.

Any more ideas where to look?

Catman · February 12, 2019, 10:03pm

So only the Vera can’t get access to those ports? Have I got that right?

Back up another step then: Can the Vera ping the pi?

Can you do ifconfig on the pi and the plus? See if anything screams odd?

Also it’s slightly possible (although not much help) that the root telnet is being rejected because it’s root. Which won’t be the root issue but…

/var/log/messages on the pi might shed some light as well

C

ntynen · February 13, 2019, 12:27am

[quote=“Catman, post:6, topic:200577”]So only the Vera can’t get access to those ports? Have I got that right?

Back up another step then: Can the Vera ping the pi?

Can you do ifconfig on the pi and the plus? See if anything screams odd?

Also it’s slightly possible (although not much help) that the root telnet is being rejected because it’s root. Which won’t be the root issue but…

/var/log/messages on the pi might shed some light as well

C[/quote]

Correct, only the Vera can’t get access to those ports.

I can ping from the vera to the Raspberry Pi and I can ping the gateway.

I looking in /var/log/NetworkMonitor.log on the VeraLite and this looks weird but it could just be a red herring

network.lan.ipaddr=192.yy.yy.yy ---> This is what I think is the getvera IP for proxy network.lan.netmask=255.255.255.0 network.lan.macaddr=d4:21:22:53:0b:61 network.lan.device=eth0 network.lan.up=1 network.lan.connect_time=37 network.wan=interface network.wan.ifname=eth0:0 network.wan.proto=dhcp network.wan.macaddr=d4:21:22:53:0b:61 network.wan.device=eth0:0 network.wan.ipaddr=192.xxx.xx.xx ---> This is my internal IP - my local net

so my internal IP schema is being applied to the WAN network and I would expect it to be assigned to the LAN network.

I’ve run /sbin/ifconfig and I see eth0 and eth0:0

eth0 is the external IP
eth0:0 is the internal IP

The routing table looks good, everything is routing to the default gateway which is my local net gateway.

I see nothing helpful in any of the logs on the Pi, it’s like it’s not routing the telnet to that port on the VeraLite.

I ran a traceroute from the VeraLite to the Pi and it was successful as well.

Catman · February 13, 2019, 6:44am

Very odd.

I don’t have eth0 and eth0.0 I have
br-wan (which has my LAN IP address statically assigned)
eth0 which has the same MAC address and is therefore the same physical interface
eth0.2 as eth0

Are you using your VP as a gateway / router / something? Or just as a host on your LAN?

My suspicion is there’s a problem (either obvious or not) on the VP config which (as you suggest) is preventing the routing of the telnet to the pi (although I’m struggling to see how)

So a couple more questions:

What does the traceroute VP > Pi show? Single hop?

Can you see the the connection coming to the pi in the logs? Really should something in there somewhere.

C

ntynen · February 14, 2019, 12:17am

[quote=“Catman, post:8, topic:200577”]Very odd.

I don’t have eth0 and eth0.0 I have
br-wan (which has my LAN IP address statically assigned)
eth0 which has the same MAC address and is therefore the same physical interface
eth0.2 as eth0

Are you using your VP as a gateway / router / something? Or just as a host on your LAN?

My suspicion is there’s a problem (either obvious or not) on the VP config which (as you suggest) is preventing the routing of the telnet to the pi (although I’m struggling to see how)

So a couple more questions:

What does the traceroute VP > Pi show? Single hop?

Can you see the the connection coming to the pi in the logs? Really should something in there somewhere.

C[/quote]

Traceroute returns in a single hop. So nothing odd there.

I hit up a buddy and he suggested my problems could be systemd related. When we updated the PI the upgrade had us using systemd instead of init. I might try that.

Catman · February 14, 2019, 6:07am

Can’t think why, but I have no better ideas at this point

C

ntynen · February 16, 2019, 9:57pm

I’m beginning to think the telnet issue is a red herring. I think that is related to the version of BusyBox running on the Pi. I can telnet to the host/port using a linux server with the telnet application installed. However, if I try to telnet from Termux (which using BusyBox) it hangs. So that isn’t the problem.

I think the root of the is issue is the

Handler failed

error message I get when VeraConcierge is making the bi-directional check on the local network

http://xxx.xxx.xx.xx/port_3480/data_request?id=lr_VCSProxy&Request=%2FQuery%3FDiscovered

I found one other person having this same issue in 12/2018 but no solution.

I really think this may be a bug in VeraConcierge.

Catman · February 17, 2019, 10:01am

[quote=“ntynen, post:11, topic:200577”]I’m beginning to think the telnet issue is a red herring. I think that is related to the version of BusyBox running on the Pi. I can telnet to the host/port using a linux server with the telnet application installed. However, if I try to telnet from Termux (which using BusyBox) it hangs. So that isn’t the problem.

I think the root of the is issue is the

Handler failed

error message I get when VeraConcierge is making the bi-directional check on the local network

http://xxx.xxx.xx.xx/port_3480/data_request?id=lr_VCSProxy&Request=%2FQuery%3FDiscovered

I found one other person having this same issue in 12/2018 but no solution.

I really think this may be a bug in VeraConcierge.[/quote]

Could be!

C

der3b · October 30, 2022, 11:48pm

strong textHi, did you fix your problem back in 2019?

I’ve been using veraconcierge on a synology nas until 2020. Tried to move to a rbpi but got stuck in the same corner.

As far as i have come the request fails as it is over https instead of http.
This url works, as lr_VSCProxy2 is calling the http handler instead of the https

http://xxx.xxx.xx.xx/port_3480/data_request?id=lr_VCSProxy2&Request=%2FQuery%3FDiscovered