Talk About the Latest in Home Automation/Home Electronics -
Home Automation Forum

Smarthome Forum
Insteon Home Automation
Login or Register
 
Home | Profile | Register | Active Topics | Search | FAQ | Smarthome | Security and Privacy | Do Not Sell My Info
 All Forums
 General Discussion
 Insteon
 Insteon Hub: Unexpected data seen coming from 2242
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

azbullrider
Starting Member

USA
6 Posts

Posted - 06/27/2014 :  11:50:24 PM  Show Profile  Reply with Quote
UNEXPECTED DATA SEEN IN DATA FLOW FROM 2242-222 INSTEON HUB.

ANALYSIS ACCOMPLISHED USING WIRESHARK (VERSION 1.10.7), on Windows 7 Ultimate SP1 64-bit.


My 2412N failed recently. So, I ordered a replacement, at which time I discovered the Insteon Hub was the only option.

In trying to discover what was wrong, I found the 2412N was sending "odd" network messages. (see below)
At times, the 2412N would cause the network light on the router to flash constantly. I discovered the 2412N was sending continuous streams of DHCP/DNS discovery messages. Unplugging and replugging the device helped for a while.

I ordered, and quickly received my brand new Insteon Hub (2422-222). Naturally, I wanted to know if the new hub was sending the same "odd" messages. IT WAS (is)!

In the data below, the "Source" ip address 192.168.0.100 is the new (just out of the box) Insteon Hub I just bought.
The Destination ip address of 192.168.0.1, is the D-Link route/hub.
The D-Link router/hub, had only TWO devices connected to it:
The new Insteon Hub, and my computer, which had IP address of 192.168.0.10.
The D-Link router/hub is not connected to an Internet (public) source, this network is private, with no Internet access.

You will noticed the (Insteon) hub sending RST,ACK messages every few seconds TO port 80.
The "FROM" port increases, beginning at port 1024, though 5000; that is, all the standard-model "ephemeral" ports.
(In the example below, I only show one data packet [for port 1026], but it is typical)

The "common name" of the application which normally uses the port being scanned is presented in the data below:
For instance, MXX Remote Login, or mxxrlogin uses port 1035.
I do not have MXX, and do not see why the hub would be sending an RST/ACK message to the router/hub (192.168.0.1) for this port.

I called technical support on 06/25/2014, and the tech consulted with three other support people, all of which said:
"The hub is not capable of sending/scanning ports".

Further, when I unplug the network cable from the Insteon Hub (going to router), the "scanning stops", (in the data stream) confirming the hub is the source of the RST/ACK messages.

In fact, the network light (amber) on the Insteon Hub continues to flash at approximately 5 second intervals, which is the same interval the RST/ACK messages are sent.

Note, the reason I purchased the Insteon Hub was because the 2412N, I currently used as my controller was sending the same data/requests to the to the network, and the radio failed.

Another tested possibility: Is the data coming from the "Power Line" side, through the Insteon Hub(s)?
While my local power company does use "Smart Meters" and collects data via their power lines, I have confirmed this problem is not coming from the outside power lines, by disconnecting the commercial power, and running the house on my own generator.
During this test, both the 2412N and the 2422-222 continued to send the data (indicated below), proving it cannot be coming from the power-line.

I also preformed the same test using another router, a NetGear Security Router, and got the same results, so the data cannot be coming from the "router" somehow.

I ask others to test their devices with a data analysis device/application (WireShark is free) and confirm if you see the same thing?

The only remaining possibility is, the data is coming from the chip installed in your hub(s) 2412N & 2242-222.

Please help me understand how/why your hub is sending these data.

*********

The 2412N has the following chip installed:
Microchip #PIC18F97J60
-1/PT
(in a circle) "e3" (a version number?)
1234K2P

I have not opened the Insteon Hub, which would void the warranty, so I cannot say what chip(s) are installed in this device.

Fact is, I know the data is coming from the hub. It does appear to be benign, but I see not logical REASON for this to happen.

*******

Here is a C/P of one data packet:
No. Time Source Destination Protocol Length Info
248 2014-06-25 19:28:13.289275000 192.168.0.100 192.168.0.1 TCP 60 cap > http [RST, ACK] Seq=1 Ack=1 Win=200 Len=0

Frame 248: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Smarthom_xx:xx:xx (00:0e:f3:xx:xx:xx), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
Source: Smarthom_xx:xx:xx (00:0e:f3:xx:xx:xx)
Type: IP (0x0800)
Padding: 000000000000
Internet Protocol Version 4, Src: 192.168.0.100 (192.168.0.100), Dst: 192.168.0.1 (192.168.0.1)
Transmission Control Protocol, Src Port: cap (1026), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: cap (1026)
Destination port: http (80)
[Stream index: 1]
Sequence number: 1 (relative sequence number)
Acknowledgment number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x014 (RST, ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 0... = Push: Not set
.... .... .1.. = Reset: Set
[Expert Info (Chat/Sequence): Connection reset (RST)]
[Message: Connection reset (RST)]
[Severity level: Chat]
[Group: Sequence]
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
Window size value: 200
[Calculated window size: 200]
[Window size scaling factor: -1 (unknown)]
Checksum: 0xb3bf [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]

In the example above, the port number (1026) increments by one ~every 5 second, until it reaches 5000, and then starts over again at 1024.

I should point out, that in hacking circles, scanning ports for RST/ACK resets is common way of determining what services are running on a system.


Please help my understand how/why this is happening.

Tfitzpatri8
Administrator

USA
10955 Posts

Posted - 06/28/2014 :  06:17:55 AM  Show Profile  Reply with Quote
There is a logical reason. Both devices are hard-coded to register themselves with Insteon's servers to allow them to use advertised features.

The 2412n SmartLinc was trying to register itself with the SmartLinc.smarthone.com dynamic dns forwarding service that allowed you to log in even if your ISP changed the IP address assigned to your modem.

The Hub does something similar. It is designed to connect to and work with a cloud service at connect.Insteon.com to support easy setup, online backup and synchronization between multiple mobile devices, dynamic dns forwarding, email and text notification, and control via mobile app and browser interface. It needs an Internet connection to connect to that cloud service. If you disconnect it from the Internet, it will continue to look for a pathway to reconnect.
Go to Top of Page

azbullrider
Starting Member

USA
6 Posts

Posted - 06/28/2014 :  11:54:51 AM  Show Profile  Reply with Quote
Page 6 of the PDF document for the 2412N states:

"These instructions assume the user is familiar with networking setup and firewall management (you will need to refer to your router's instruction manual to determine how to perform the following steps on your specific router)
"User needs to be aware that there are always risks associated with configuring devices to make them accessible to the internet. User takes full responsibility for network management and security"


The PDF document for the 2242-222 does not have this same disclaimer, though I admit it is implied.

Since the user "takes" full responsibility for management and security, it would seem to make sense there would be away to turn this feature off? Say...someone who is not very computer literate, or has no understanding of how the internet works (TCP/IP) purchases a hub with the full intention of only using it with HouseLinc (as I intend). If they connected it to a router with internet access your device would (likley) attempt to contact the cloud, even though the user had no intention of using this feature.
Further, in the disclaimer (above) it is suggested the "user configured" the device to access the internet, which would be incorrect, because it appears the device will attempt to connect regardless of what the user intended?

I will test this, to see what, if any data the hub attempts to send to the cloud.

I would really like to be able to stop the device from trying to access the internet.

Go to Top of Page

Tfitzpatri8
Administrator

USA
10955 Posts

Posted - 06/28/2014 :  12:14:56 PM  Show Profile  Reply with Quote
You can choose whether you allow or disallow an incoming connection to either product by your choice to enable (or not) your router's built-in firewall and to create (or not create) a port forwarding rule. If you do that, be sure to password-protect it. (The SmartLinc shipped with password protection disabled, so it was the user's responsibility to turn it on if they intended to allow WAN access. The Hub app and cloud service set up randomized user names and passwords automatically to help inexperienced users avoid unintentionally leaving their Insteon devices available to remote control by hackers.)

So far as I can tell, there is no way to disable either unit from attempting to reach the Insteon servers, since that would also interfere with dynamic dns forwarding. If you disable outbound access via router settings, the Hub and SmartLinc will continue to attempt to connect to the Insteon servers, but the IP network traffic they generate is minimal.
Go to Top of Page

tyndall
Starting Member

Canada
1 Posts

Posted - 06/28/2014 :  7:29:41 PM  Show Profile  Reply with Quote
quote:
Originally posted by azbullrider
Since the user "takes" full responsibility for management and security, it would seem to make sense there would be away to turn this feature off? Say...someone who is not very computer literate, or has no understanding of how the internet works (TCP/IP) purchases a hub with the full intention of only using it with HouseLinc (as I intend). If they connected it to a router with internet access your device would (likley) attempt to contact the cloud, even though the user had no intention of using this feature.
Further, in the disclaimer (above) it is suggested the "user configured" the device to access the internet, which would be incorrect, because it appears the device will attempt to connect regardless of what the user intended?

People want things to work. The less they know, the more they expect it to work out of the box. If it doesn't, by default, give them all the features it says on the box, they'll scream bloody murder and trash the product in reviews. Any complaint from a techie goes right over the head of an average user and doesn't affect sales.

If the device is set to DHCP, it should try to auto-configure as much as possible. It would be nice to have a full config page dedicated to advanced settings, but that usually causes more problems and creates more support calls.

A true techie wouldn't be running DHCP on a "server" device like a Hub. Or if they were, it would have it's own static lease with it's own configuration. Considering the Hub is designed as an internet device and using it inside a closed network goes against the design principle, some kludges might be necessary. The easiest I can think of is to set a static ip and set the gateway to some unused address. This would stop it from connecting outside the network but still allow access to it from inside or by a VPN into the router.

If the minor traffic going nowhere is still a problem, then the wrong device was bought.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
Smarthome Forum © 2000-2021 Smartlabs, Inc Go To Top Of Page
Powered By: Snitz Forums 2000 Version 3.4.07