Tcp passthrough ssl problem with a Korner Home Security stick

Hi, I’m trying to connect a Korner security system, this is the last issue in converting from a Comcast WiFi router, everything else including Bryant thermostat, Neurio energy monitor, home brew PV monitor… just worked.

When I connect the Korner stick, I can see that it gets an IP address, and is presumably sending requests out to its server (some Heroku service on AWS). Any replies are getting filtered out somewhere.

The last comment I got from Korner support was: Try making a TCP pass-through for TCP and SSL connections through the router. Make sure it is set to allow IPv4.

I would assume that this is already true in the default Turris configuration. Does anybody have any ideas on how to proceed from here? Thanks.

To be clear: the Korner stick works when connected to the Comcast modem in router mode. I first just connected the Turris to a port on the modem and moved everything to Turris ports or WiFi - no problems except the stick. Then I switched the modem to bridge mode and finally replaced it with a new modem.

BTW: the Korner stick is an ethernet to Zigbee bridge with a piezo buzzer. Sensors are door and window mount tags. It’s simple and needs a bit more development, but seems to be pretty robust.

have you tried together with domoticz?

No, I haven’t. It looks pretty interesting, but I don’t see how it addresses my issue at all.

I think that the Korner firmware is basically trying to open an SSL socket and it’s not working on the Turris, but does on most other routers.

You can use tcpdump to see what is going on. Just log on to your omnia using ssh (or putty) and install tcpdump:

tom@debian:~$ ssh root@192.168.1.1
root@192.168.1.1's password: 
root@turris:~# opkg update
.
.
root@turris:~# opkg install tcpdump
.
.
Configuring tcpdump.
root@turris:~# 

If you known the IP address of Korner device (e.g. 192.168.1.122), then you can limit output of tcpdump to see only interesting parts.

root@turris:~# tcpdump -n -i br-lan host 192.168.1.122
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 65535 bytes
20:30:42.354806 IP 192.168.1.1.22 > 192.168.1.122.42961: Flags [P.], seq 1833673588:1833673776, ack 3420286618, win 317, options [nop,nop,TS val 141394 ecr 152772], length 188
20:30:42.356571 IP 192.168.1.122.42961 > 192.168.1.1.22: Flags [.], ack 188, win 1440, options [nop,nop,TS val 152783 ecr 141394], length 0

Then force device to make a connection and see what is happening.

Good idea - here’s what I’m seeing. I’ve never used tcpdump before … I’ll send this to korner as well

root@turris:~# cat korner.log
14:04:01.890831 ARP, Request who-has 192.168.1.1 tell 192.168.1.192, length 46
14:04:01.890845 ARP, Reply 192.168.1.1 is-at d8:58:d7:00:3f:0c, length 28
14:04:02.379523 IP 192.168.1.192.18046 > 192.168.1.1.53: 0+ A? secure.kornersafe.com. (39)
14:04:02.469797 IP 192.168.1.1.53 > 192.168.1.192.18046: 0 5/0/0 CNAME fukui-1745.herokussl.com., CNAME elb065252-1496439641.us-east-1.elb.amazonaws.com., A 54.225.184.141, A 54.243.176.57, A 23.23.254.98 (337)
14:04:07.472933 ARP, Request who-has 192.168.1.192 tell 192.168.1.1, length 28
14:04:07.474306 ARP, Reply 192.168.1.192 is-at dc:e0:26:00:07:46, length 46
14:04:36.219568 IP 60.240.5.214.5916 > 192.168.1.192.23: Flags [S], seq 4378, win 14600, length 0
14:04:36.221134 IP 192.168.1.192.23 > 60.240.5.214.5916: Flags [R.], seq 0, ack 4379, win 14600, length 0