GalaxyGuy

The above is basically 'no ICMP response' from any device at that address - so the device isn't working as expected. If the device responded, it would give number of bytes and a response time. C:\k2>ping 10.226.111.2 Pinging 10.226.111.2 with 32 bytes of data: Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Reply from 10.226.111.2: bytes=32 time<1ms TTL=128 Ping statistics for 10.226.111.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

Okay, I'm forgetting that you don't get to see how many seconds in the panel log. I see this in the self monitoring which gives a more granular time stamp. But within the same minute in your log. I have the same setup here in the office, so will try to replicate your issue. Is the RIO you have fitted in the garage a new (blue PCB) or old variant ? f/w ? I've seen an issue in the protocol used by the panel/portal when a certain bus traffic condition occurs. I thought that this only caused a portal tamper and RF jam at the same time, but it's possible that the issue may manifest differently depending on the bus devices in play. If many customers are seeing this when adding a RIO to the Flex, then it's possible that it's the same root cause. I think the clue is that there's no max noise registered, but a jam is recorded.

Really needed exact times, but at less than a minute I'm assuming more than two seconds, so sounds like a different issue. Since Honeywell have updated that V3.00 firmware, you need to get the latest. The support isn't great these days, as when I asked them about issues, they said that domestic appliances like microwaves Etc. need to be switched off. Have you checked the max noise levels in the diags logs for the module and devices ?

In the log, how much time between the +JAM and the -JAM events ? I am trying to determine if this is the same type of protocol issue that I found with concurrent JAM+Tamper when the portal is fitted with the Ethernet module.

Does the portal report JAM + Tamper in the logs, or just JAM on its own ?

Featured on hackaday: http://hackaday.com/2015/11/26/hacker-uncovers-security-holes-at-csl-dualcom/

According to Matt, the standards were outdated. Nobody needs to get into the arc to take control, so the physical attributes don't matter much in that case. The standards are pretty open on the software side where an attack is far more likely.

What is the new version for the V3.00 based module ? Pretty peeved at Honeywell support, as they did not provide this to me as part of my investigations into RF issues. They only updated on the other two F135 firmwares. Very poor comm's. I also think that the panel firmwares need to at least be adjustable on the 31 second front, otherwise there is no last resort... Just to clarify that there are now three versions of the G2/Flex/Dimension portal available (as far as compatible firmware goes that is): 1. The original C079 which can have rotary address dial or fixed jumpers: V1.08 2. The Rev F2 C079 portal which has pcb trace aerial: V2.11 3. The latest Rev A2 C079 portal with optional Russian frequency and test mode for visual (LED) signal strength: V3.0X -- For those who have purchased one of my G2 USB leads - As well as programming the G2, this lead can be used to flash upgrade the RF modules. I am also releasing an updated firmware for the LCE-01 Ethernet module to resolve a (very intermittent) protocol issue when the virtualkeypad is used alongside the RF portal. The LCE is V2.20 Dimension Firmware is at: V6.92 (enables outputs on apps) (although 520 and 264 cannot be used with the app until a new app release is available - Ethernet modules drop offline with the current app) G2 Firmware: V1.56 Galaxy G3: V5.55 E080-2 Ethernet: V2.11 E080-4 Ethernet: V3.05 Flex V3: V3.18 IB-Ethernet (Flex V3): V1.02

Sounds about right. I managed to jam the Honeywell in 31 seconds when testing earlier. Tried two portal versions with different firmwares and all did the same. No way of adjusting either.

I cannot determine any local mast information. It's a bit of a mission to start asking which network providers and which phones are in use Etc.

An example I was looking at today took its first single RF Jam after 11 months of flawless operation. The system hadn't skipped a beat with a perfect heartbeat test signal record and daily open/close reporting.

The Honeywell RF portal is based on the CC1101 from TI.

I'm only using panel diagnostics at the moment. I have some measurement equipment ordered for further investigation. I'm also awaiting further direction from Honeywell, as there are three different C079 portal variants all with different firmwares (and recent changes) and information on the changes hasn't been available. I also have conflicting installer reports of one portal variant fixing the problem at customer sites, but the trouble with this is that only time will tell if this is actually the case - the installer seemed convinced though... This particular installer is in the Netherlands, so whatever seems to be happening, it's doesn't seem limited to the UK.

I'm not sure what's going on at the moment, but certainly seeing Honeywell systems with some issues. Perhaps the Honeywell has tighter parameters for RF noise triggering a Jam. I believe it's a 3 minute period of signal jam that constitutes a jam tamper. I am not sure what the protocol does underneath that as far as signal levels Etc, but there's no real way of preventing the tamper at the panel side when the RF portal is fitted. If this does have something to do with mobile comm's (speculation at the moment), then it could mean trouble ahead... I really hope not.

Has anyone else seen an increase in alarm system wireless issues this year ? I'm not sure if it's based on the wireless systems uptake, but I have accounts where there has been no issues for many months suddenly start getting random jam alerts at no particular set time points. I'm very suspicious that this is something to do with the increase in mobile 4G. Perhaps I am just being paranoid...

See if you can get an updated firmware. If not, IPSec would be the best of what's there. You need more information on the L2TP to see what is actually implemented.

Depends on your router or VPN gateway secureiam. Something based around open source will likely be updated quickly when any issues are discovered. If you're using one entry point, then it's easier to focus efforts to keep it up to date. Much easier to do that than to rely on very small teams of security equipment designers to find vulnerabilities and release fixes. My personal experience of reporting such a vulnerability to one vendor of a 'third party approved' device, was that they just didn't want to know. When your phone connects via VPN a secure tunnel is created into the private network and all apps/IP based programs behave as they would in the private network. All traffic between your external location and your VPN device is secure, so it doesn't matter anymore that your app traffic is plain text. The 'vulnerable' devices remain in the private network.

Port forward should be the last resort with customers warned about the vulnerability. Just because something is password protected, doesn't mean there's some other vulnerability available through the forwarded port. Installers are adding IP enabled devices in customers premises without having any idea of how secure the device and its internal protocols are. VPN should be the preferred connection method, with the firmware in the VPN device being regularly updated to ensure that any vulnerabilities have been addressed.

No, was talking about converting the UDL code for the app in order that customers don't see it.

Still easy to pick up with wireshark for those that want it.

If the panel has been locked down properly, then you will not be able to connect with RSS. The virtual keypad 'backdoor' is not a back door and the pin should also have been changed if the panel is locked down. Other than that, it requires specialist equipment to interface with the Atmel CPU. Easier to display the zones, note them and then default.

Is the HKC encrypted traffic?

Texecom or Honeywell Galaxy. Texecom doesn't encrypt the communication though, so you'd need to use a VPN connection with it.

It would need to be a faulty device to be staying in write mode. Depending on the Ethernet firmware, the level can dip down momentarily (buggy Honeywell firmware), so you can probably just ignore on the COM4 device and the virtual keypad for it KP15. I think it's probably easier for you to swap devices until you have them all done. If this was at a customer site, I would say to just swap them all and then test them back in the office. It may be better doing the same at home in order to keep false alarms at a minimum. Apart from that, you'd need to connect a bus analyser/recorder and watch the traffic in order to debug the issue.

No the length is too short and the bus too resilient for this to be an issue. But if Ethernet COM4 is dropping out too, then it rules any open on the bus out. It would appear that something is dragging the bus down. A slave device can do this if it sits in write mode when it shouldn't. An intermittent short to the A/B lines would also do the same.