Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAC Authentication of packet failed. Dropping #349

Closed
GoogleCodeExporter opened this issue Mar 14, 2015 · 36 comments
Closed

MAC Authentication of packet failed. Dropping #349

GoogleCodeExporter opened this issue Mar 14, 2015 · 36 comments

Comments

@GoogleCodeExporter
Copy link

Hi

I am starting to test a security device. So I got a danalock door lock, and I 
believe that something must be wrong

I've set a networkkey, included the device by software and the keys seem to be 
shared. At least it says so.

But I can't send any commands to the device like lock or unlock, neither I can 
receive data when I manually unlock the door. Also I receive this message:

2014-08-10 22:51:01.156 Info, Node004, Received SecurityCmd_NonceGet from node 4
2014-08-10 22:51:01.156 Detail, Node004, Queuing (Security) 
SecurityCmd_NonceReport (Node=4): 0x01, 0x11, 0x00, 0x13, 0x04, 0x0a, 0x98, 
0x80, 0x3b, 0xfa, 0xcc, 0xcc, 0x39, 0x63, 0xef, 0x4e, 0x05, 0x18, 0xcc
2014-08-10 22:51:01.156 Detail, 
2014-08-10 22:51:01.156 Info, Node004, Sending (Security) message (Callback 
ID=0x18, Expected Reply=0x04) - SecurityCmd_NonceReport (Node=4): 0x01, 0x11, 
0x00, 0x13, 0x04, 0x0a, 0x98, 0x80, 0x3b, 0xfa, 0xcc, 0xcc, 0x39, 0x63, 0xef, 
0x4e, 0x05, 0x18, 0xcc
2014-08-10 22:51:01.163 Detail, Node004,   Received: 0x01, 0x04, 0x01, 0x13, 
0x01, 0xe8
2014-08-10 22:51:01.163 Detail, Node004,   ZW_SEND_DATA delivered to Z-Wave 
stack
2014-08-10 22:51:02.331 Detail, Node004,   Received: 0x01, 0x05, 0x00, 0x13, 
0x18, 0x00, 0xf1
2014-08-10 22:51:02.331 Detail, Node004,   ZW_SEND_DATA Request with callback 
ID 0x18 received (expected 0x18)
2014-08-10 22:51:02.331 Info, Node004, Request RTT 1175 Average Request RTT 1185
2014-08-10 22:51:02.385 Detail, Node004,   Received: 0x01, 0x1c, 0x00, 0x04, 
0x00, 0x04, 0x16, 0x98, 0x81, 0xcb, 0x79, 0x6f, 0x3a, 0x58, 0xee, 0xb1, 0x6d, 
0x78, 0xc9, 0x94, 0x3b, 0x76, 0x18, 0xe9, 0x2f, 0x15, 0x2f, 0x9e, 0x3b, 0x48
2014-08-10 22:51:02.385 Detail, 
2014-08-10 22:51:02.385 Info, Node004, Response RTT 1228 Average Response RTT 
1223
2014-08-10 22:51:02.385 Info, Node004, Received SecurityCmd_MessageEncap from 
node 4
2014-08-10 22:51:02.385 Info, Decrypted Packet: 0xcf, 0x40, 0xf2
2014-08-10 22:51:02.385 Warning, Node004, MAC Authentication of Packet Failed. 
Dropping
2014-08-10 22:51:02.385 Detail, Node004,   Expected reply and command class was 
received
2014-08-10 22:51:02.385 Detail, Node004,   Message transaction complete

Note that I'm using a rPi and I run this using Py-OZW.

Thanks

Original issue reported on code.google.com by santal.m...@gmail.com on 10 Aug 2014 at 10:11

@GoogleCodeExporter
Copy link
Author

Also seems like the device is not added on the device database

Here goes some details:

Z-Wave information about the Danalock
Manufacturer Info

    Zensys manufacturer ID(270) // Poly-Control

Device Info

    GENERIC_TYPE_ENTRY_CONTROL
    SPECIFIC_TYPE_ADVANCED_DOOR_LOCK

Supported commands
Non encrypted combo and lock

    COMMAND_CLASS_MANUFACTURER_SPECIFIC,
    COMMAND_CLASS_BATTERY,
    COMMAND_CLASS_VERSION,
    COMMAND_CLASS_SECURITY,

Crypted combo (Z-Wave and bluetooth units, prepared for a future keypad)

    COMMAND_CLASS_DOOR_LOCK,
    COMMAND_CLASS_USER_CODE,
    COMMAND_CLASS_SCHEDULE_ENTRY_LOCK,
    COMMAND_CLASS_CONFIGURATION,
    COMMAND_CLASS_TIME,
    COMMAND_CLASS_MANUFACTURER_SPECIFIC,
    COMMAND_CLASS_BATTERY,
    COMMAND_CLASS_VERSION

Crypted lock (Z-Wave units)

    COMMAND_CLASS_DOOR_LOCK,
    COMMAND_CLASS_CONFIGURATION,
    COMMAND_CLASS_TIME,
    COMMAND_CLASS_MANUFACTURER_SPECIFIC,
    COMMAND_CLASS_BATTERY,
    COMMAND_CLASS_VERSION

Original comment by santal.m...@gmail.com on 10 Aug 2014 at 10:19

@GoogleCodeExporter
Copy link
Author

Oh... and this should be important aswell

http://guide.danalock.com/index.php/ZwConfigVariablesTable

Original comment by santal.m...@gmail.com on 10 Aug 2014 at 10:20

@GoogleCodeExporter
Copy link
Author

Please upgrade to the latest version and send complete logs. There is a issue 
with rPI boards at the moment. 

Original comment by jus...@dynam.ac on 11 Aug 2014 at 4:27

@GoogleCodeExporter
Copy link
Author

Hi here goes the complete log.


Original comment by santal.m...@gmail.com on 11 Aug 2014 at 8:53

Attachments:

@GoogleCodeExporter
Copy link
Author

the device doesn't appear to be reset correctly. Is there a factory reset 
option or something on it? Its not even responding to simple Network Key 
functions in the log you sent. 

(I gather you had previously tried to pair it with something?)

Original comment by jus...@dynam.ac on 11 Aug 2014 at 10:29

@GoogleCodeExporter
Copy link
Author

That's weird.

I excluded the device from the controller, then I made reset on the zstick 
controller and to the doorlock.

After that I cleaned the xml file to have a clean environment.

Restarted my program and included the lock successfully. Then I sent some 
commands and nothing happens

Original comment by santal.m...@gmail.com on 11 Aug 2014 at 10:44

@GoogleCodeExporter
Copy link
Author

I don't understand why you say that:

2014-08-10 22:42:03.643 Info, Node004, Response RTT 1197 Average Response RTT 
1192
2014-08-10 22:42:03.643 Info, Node004, Received SecurityCmd_NonceReport from 
node 4
2014-08-10 22:42:03.644 Info, Input Packet: Packet: 0x00, 0x98, 0x06, 0x01, 
0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 
0x0f, 0x10
2014-08-10 22:42:03.644 Detail, Node004, Queuing (Security) 
SecurityCmd_MessageEncap (SecurityCmd_NetworkKeySet) (Node=4): 0x01, 0x2d, 
0x00, 0x13, 0x04, 0x26, 0x98, 0x81, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 
0xaa, 0x0e, 0x0f, 0x10, 0xc6, 0x52, 0xd4, 0xa1, 0xd6, 0xb1, 0xb5, 0x51, 0xc3, 
0xc1, 0x59, 0x8a, 0x6b, 0x40, 0xd3, 0x91, 0x24, 0xa1, 0x75, 0x16, 0xf2, 0xcf, 
0x36, 0xe8, 0xfe, 0x25, 0x07, 0xe8
2014-08-10 22:42:03.644 Info, Node004, Reseting Network Key after Inclusion
2014-08-10 22:42:03.644 Info, Node004,   Using Configured Network Key 
(AddingNode: true KeySet: true)
2014-08-10 22:42:03.644 Detail, Node004,   Expected reply and command class was 
received
2014-08-10 22:42:03.644 Detail, Node004,   Message transaction complete


This seems like they are communicating. Or am I wrong?

Original comment by santal.m...@gmail.com on 11 Aug 2014 at 10:49

@GoogleCodeExporter
Copy link
Author

After we send a SecurityCmd_NetworkKeySet we should get a 
SecurityCmd_NetworkVerify - thats why I say its not responding correctly.

We are talking to the Lock Unencrypted fine - But most of the command classes 
require encryption - so things are not working correctly. 

When you say you reset the lock - its more than just "excluding" it from the 
Network right? I imagine there is some "factory reset" button or code or 
soemthing?

Can you test pairing hte lock with HomeSeer? (then copy the Network Key from 
the zwave.ini file in HomeSeer to the options.xml file and fire up OZW and see 
if it works)

Original comment by jus...@dynam.ac on 12 Aug 2014 at 4:27

@GoogleCodeExporter
Copy link
Author

Yes, I've done a factory reset.

I will try homeseer.

Original comment by santal.m...@gmail.com on 12 Aug 2014 at 8:32

@GoogleCodeExporter
Copy link
Author

It worked.

But that is not a solution? I want to be able to include and work with it.
And it seems to be to slow to a 1 device only network. I tell it to lock and it 
take about a 1 minute or two to assume the command.

What can be wrong :(

Original comment by santal.m...@gmail.com on 12 Aug 2014 at 9:24

@GoogleCodeExporter
Copy link
Author

You didn't state if it's working with 1) OZW or 2)Homeseer, or 3)it worked with 
Homeseer, you copied the network key to OZW and now you can control the lock. 

If 3, then it is a solution! Albeit not a OZW one!

As for the slow response, I assume your referring to OZW. In that case, make 
sure that your testing that after OZW is fully started. If your testing 
immediately after starting your app, OZW is going through its probe stages, and 
your commands will be at the end of the queue. 

Original comment by jus...@dynam.ac on 12 Aug 2014 at 4:37

@GoogleCodeExporter
Copy link
Author

It worked with homeseer and I copied the networkkey and it was working fine on 
ozw too. Although on Ozw it was extremelly slow taking about a minute to reply.

Yes that is not the solution I want. I want to be able to include the device 
and use it with my ozw application.

Why didn't it work. Do you have any clue?

And thanks for the hint

Original comment by santal.m...@gmail.com on 12 Aug 2014 at 4:45

@GoogleCodeExporter
Copy link
Author

So, is there any solution for including this device correcly on ozw?

Original comment by santal.m...@gmail.com on 18 Aug 2014 at 2:54

@GoogleCodeExporter
Copy link
Author

right now - I need to do some more testing with a rpi and other Locks. Thats 
going to take a while, as I neither own a rPi, nor any other locks. 
but I believe the rPi isn't fast enough for it to complete the Network Key Set 
within ~10 Seconds of inclusion (yours is right on the limit - So that might be 
the issue).

Original comment by jus...@dynam.ac on 20 Aug 2014 at 3:36

@GoogleCodeExporter
Copy link
Author

And as you can include via HomeSeer and then it works correctly - Then I don't 
consider this "broken" right now... If you do the inclusion with homeseer, copy 
the network key to OZW Options.xml and fire up OZW, then its the same as doing 
the inclusion with OZW. 

Original comment by jus...@dynam.ac on 20 Aug 2014 at 3:37

@GoogleCodeExporter
Copy link
Author

This latest tests I done was on a desktop... So it's not rpi related... I
am running a Intel i7 at 2.8Ghz with debian 7

Still it fails so I believe something is wrong.


2014-08-20 16:37 GMT+01:00 <open-zwave@googlecode.com>:

Original comment by santal.m...@gmail.com on 20 Aug 2014 at 4:16

@GoogleCodeExporter
Copy link
Author

Its taking just over 10 seconds. I believe the time-out is less than 10 
seconds. without physical access to the lock, not much more I can do at the 
moment. 

Original comment by jus...@dynam.ac on 20 Aug 2014 at 4:24

@GoogleCodeExporter
Copy link
Author

I can help, what would you want me to do with the lock to test or do?

I have programming skills so maybe I can help, I'm just a little bit
unaware of the security process



2014-08-20 17:24 GMT+01:00 <open-zwave@googlecode.com>:

Original comment by santal.m...@gmail.com on 20 Aug 2014 at 4:26

@GoogleCodeExporter
Copy link
Author

Definitly something is wrong on this lock...

Here goes another log

I'm pretty sure that I have a fast machine, the device is on high_power
inclusion, I have the lock right on the side of the zwave stick... still it
takes too long and nothing has been done. What can be wrong here?

What can I do to help you debugging this?


2014-08-20 17:26 GMT+01:00 Diogo Alves <santal.maluko@gmail.com>:

Original comment by santal.m...@gmail.com on 20 Aug 2014 at 9:06

@GoogleCodeExporter
Copy link
Author

Essentially, you need to figure out why it doesn't respond to the 
NetworkKey_Set command. 

There is no Log attached, so nothing I can look it. 

Original comment by jus...@dynam.ac on 21 Aug 2014 at 5:33

@GoogleCodeExporter
Copy link
Author

Sorry forgot to attach:

Original comment by santal.m...@gmail.com on 21 Aug 2014 at 8:50

Attachments:

@GoogleCodeExporter
Copy link
Author

In the log it's 11 seconds between discovery and the networkkey_set command. 
That's inline with the 10 second timeout I suspect. 
Can you capture the serial port traffic with Homeseer and send to me? (With the 
network key Homeseer is using)

Original comment by jus...@dynam.ac on 21 Aug 2014 at 9:43

@GoogleCodeExporter
Copy link
Author

I can do it later tonight.

I will then post here the logs.

Thanks for the suggestion!


2014-08-21 10:43 GMT+01:00 <open-zwave@googlecode.com>:

Original comment by santal.m...@gmail.com on 21 Aug 2014 at 11:05

@GoogleCodeExporter
Copy link
Author

Please try revision 885 - I've tried to reduce the discovery time during a 
AddNode Command. 
If it doesn't work, please:
"make clean"
"BUILD=debug make"
and then link with your application, and send me the full logs. 

Original comment by jus...@dynam.ac on 21 Aug 2014 at 2:37

@GoogleCodeExporter
Copy link
Author

Hello

Here is the result on the homeseer

I will try those changes you posted now

This log is all the inclusion process

The network key is
Key=A1-FF-13-14-14-2B-F8-B7-3C-40-31-7-C7-5F-CA-32

Original comment by santal.m...@gmail.com on 21 Aug 2014 at 11:14

Attachments:

@GoogleCodeExporter
Copy link
Author

Just tried the update.

it took about 7 seconds but it still doesn't secure the device.

Has the exact same behaviour but it's faster

I hope that the raw dump from home seer can you :(

Original comment by santal.m...@gmail.com on 21 Aug 2014 at 11:32

@GoogleCodeExporter
Copy link
Author

Can you do the debug log like I asked please?

Original comment by jus...@dynam.ac on 22 Aug 2014 at 1:31

@GoogleCodeExporter
Copy link
Author

hey, I found out that I did not linked the library... and have marked the 
timming in a wrong way

Now I paired the lock, unfortunatly I can't lock or unlock (I could do it 
before with the homeseer inclusion)

I will post here the config file I've created for it (maybe I have something 
wrong)
The inclusion log and the lock command log

PS1: That was a great work you've done
PS2: Beware version 887 is not initializing properly and throws and 
segmentation fault

Original comment by santal.m...@gmail.com on 22 Aug 2014 at 10:40

Attachments:

@GoogleCodeExporter
Copy link
Author

this time it does set the NetworkKey Correctly - So it seems timeouts might 
have been a issue:
2014-08-22 11:30:40.051 Info, Node020, Received SecurityCmd_NetworkKeyVerify 
from node 20

But Getting the Associations Failed. (in all the examples).... It just doesn't 
respond. this is critical in OZW, so no reply means that OZW essentially hangs 
on that stage for that node. hence why it wont lock. (cause its stuck in that 
stage)

In the Lock-Unlock file, it almost appears if the device has gone to sleep - 
Its not even responding to NONCE_Get messages, and thus the entire security 
queue hangs up. 

(if it doesn't respond to NONCE_GET we can't even send a Encrypted message. Its 
fundamental to the device.)

the 'config' you posted is not really a config file. Its from zwcfg_*.xml. 
Which despite its name, is NOT a config file.  whenever you are testing, its 
much better if you can remove the zwcfg_*.xml file between runs. Its not 
critical and will get recreated. 

If you putting that danalock.xml file into the config/danalock/ etc directory, 
its will mess things up. you don't need any config file as of know, but as we 
move along, we might end up creating one.

can you do a "inclusion" with homeseer, remove any zwcfg_*.xml file, and 
startup OZW with the right network key... lets see what is different... if any.

Finally, 887 is working fine for me. Can you get a backtrace of your crash?

Original comment by jus...@dynam.ac on 22 Aug 2014 at 2:50

@GoogleCodeExporter
Copy link
Author

Great! I will do that.

I would really like to learn more about openzwave internals. I seems to
have a loooooot of features but some are still unknow to me, plus I'm using
the py-ozw so I'm not handling with the openzwave code too much


2014-08-22 15:50 GMT+01:00 <open-zwave@googlecode.com>:

Original comment by santal.m...@gmail.com on 22 Aug 2014 at 3:03

@GoogleCodeExporter
Copy link
Author

Hey Justin, 
With 884, 885 and 886 my Kwikset locks no longer work which seems similar to 
what has been posted in this thread.
As worked for me in previous builds, I tried playing the the MAX_TRIES and 
RETRY_TIMEOUT but thats not helping either this time. 
Attached is my log.
Can you tell me what might be going on?
I will try to remove and re-add the locks to the network to see if that makes 
any difference. 
Anything else I can do to help you find the problem?

Thanks, 
TJ

Original comment by TJTrolin...@gmail.com on 22 Aug 2014 at 3:37

Attachments:

@GoogleCodeExporter
Copy link
Author

TJ: Readd as I posted in the other forum. Its failing the Decryption when we 
receive messages back, which indicate the Keys got out of whack.

Original comment by jus...@dynam.ac on 22 Aug 2014 at 4:06

@GoogleCodeExporter
Copy link
Author

Hello,

after removing the config the lock is wrong fine.... it just hangs for
sometime because it is not accepting the BasicCmd and it retries 3 times...
since each retry takes 20 seconds it takes a minute sometimes



2014-08-22 17:06 GMT+01:00 <open-zwave@googlecode.com>:

Original comment by santal.m...@gmail.com on 22 Aug 2014 at 6:51

@GoogleCodeExporter
Copy link
Author

I removed the two locks. 
Did a factory reset on both. 
Added the first one with no problems and was able to lock/unlock.  
Then tried to add the second one about 10 times with no success.
Then after a restart couldn't communicate with the first one again.
It seems to be always the same issue waiting for a reply to "Security message".
I am at a loss what to do next.  

2014-08-23 15:26:55.785 Info, Node028, Sending (Security) message (Callback 
ID=0x17, Expected Reply=0x04) - SecurityCmd_MessageEncap (Association Set) 
(Node=28): 0x01, 0x1f, 0x00, 0x13, 0x1c, 0x18, 0x98, 0x81, 0xaa, 0xaa, 0xaa, 
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x46, 0x7f, 0x0f, 0x61, 0xb3, 0x97, 0x41, 0x6f, 
0x46, 0xa4, 0x40, 0xfe, 0xd1, 0xe6, 0x25, 0x17, 0xea
2014-08-23 15:26:55.785 Detail, Node028,   Received: 0x01, 0x04, 0x01, 0x13, 
0x01, 0xe8
2014-08-23 15:26:55.785 Detail, Node028,   ZW_SEND_DATA delivered to Z-Wave 
stack
2014-08-23 15:26:57.018 Detail, Node028,   Received: 0x01, 0x05, 0x00, 0x13, 
0x17, 0x00, 0xfe
2014-08-23 15:26:57.018 Detail, Node028,   ZW_SEND_DATA Request with callback 
ID 0x17 received (expected 0x17)
2014-08-23 15:26:57.018 Info, Node028, Request RTT 1232 Average Request RTT 1224
2014-08-23 15:27:06.424 Detail, Node028,   Received: 0x01, 0x0c, 0x00, 0x49, 
0x84, 0x1c, 0x06, 0x04, 0x40, 0x03, 0x72, 0x86, 0x98, 0x0f
2014-08-23 15:27:06.424 Detail, 
2014-08-23 15:27:06.424 Info, Node028, UPDATE_STATE_NODE_INFO_RECEIVED from 
node 28
2014-08-23 15:27:06.424 Detail, Node028, AdvanceQueries queryPending=1 
queryRetries=0 queryStage=Associations live=1
2014-08-23 15:27:35.799 Detail, 
2014-08-23 15:27:35.799 Info, Node028, Sending (Security) message (Attempt 2, 
Callback ID=0x18, Expected Reply=0x04) - SecurityCmd_MessageEncap (Association 
Set) (Node=28): 0x01, 0x1f, 0x00, 0x13, 0x1c, 0x18, 0x98, 0x81, 0xaa, 0xaa, 
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x46, 0x7f, 0x0f, 0x61, 0xb3, 0x97, 0x41, 
0x6f, 0x46, 0xa4, 0x40, 0xfe, 0xd1, 0xe6, 0x25, 0x18, 0xe5
2014-08-23 15:27:35.830 Detail, Node028,   Received: 0x01, 0x04, 0x01, 0x13, 
0x01, 0xe8
2014-08-23 15:27:35.830 Detail, Node028,   ZW_SEND_DATA delivered to Z-Wave 
stack
2014-08-23 15:27:37.032 Detail, Node028,   Received: 0x01, 0x05, 0x00, 0x13, 
0x18, 0x00, 0xf1
2014-08-23 15:27:37.032 Detail, Node028,   ZW_SEND_DATA Request with callback 
ID 0x18 received (expected 0x18)
2014-08-23 15:27:37.032 Info, Node028, Request RTT 1232 Average Request RTT 1228
2014-08-23 15:27:48.357 Detail, Node002,   Received: 0x01, 0x0b, 0x00, 0x04, 
0x00, 0x02, 0x05, 0x31, 0x05, 0x01, 0x09, 0x4d, 0x86
2014-08-23 15:27:48.357 Detail, 
2014-08-23 15:27:48.357 Info, Node002, Received SensorMultiLevel report from 
node 2, instance 1, Temperature: value=77F
2014-08-23 15:27:48.357 Detail, Node002, Initial read of value
2014-08-23 15:27:48.841 Detail, Node002,   Received: 0x01, 0x09, 0x00, 0x04, 
0x00, 0x02, 0x03, 0x45, 0x03, 0x00, 0xb5
2014-08-23 15:27:48.841 Detail, 
2014-08-23 15:27:48.841 Detail, Node002, Initial read of value
2014-08-23 15:27:48.841 Info, Node002, Received thermostat fan state: Idle
2014-08-23 15:28:15.813 Detail, 
2014-08-23 15:28:15.813 Info, Node028, Sending (Security) message (Attempt 3, 
Callback ID=0x19, Expected Reply=0x04) - SecurityCmd_MessageEncap (Association 
Set) (Node=28): 0x01, 0x1f, 0x00, 0x13, 0x1c, 0x18, 0x98, 0x81, 0xaa, 0xaa, 
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x46, 0x7f, 0x0f, 0x61, 0xb3, 0x97, 0x41, 
0x6f, 0x46, 0xa4, 0x40, 0xfe, 0xd1, 0xe6, 0x25, 0x19, 0xe4
2014-08-23 15:28:15.845 Detail, Node028,   Received: 0x01, 0x04, 0x01, 0x13, 
0x01, 0xe8
2014-08-23 15:28:15.845 Detail, Node028,   ZW_SEND_DATA delivered to Z-Wave 
stack
2014-08-23 15:28:17.046 Detail, Node028,   Received: 0x01, 0x05, 0x00, 0x13, 
0x19, 0x00, 0xf0
2014-08-23 15:28:17.046 Detail, Node028,   ZW_SEND_DATA Request with callback 
ID 0x19 received (expected 0x19)
2014-08-23 15:28:17.046 Info, Node028, Request RTT 1232 Average Request RTT 1230
2014-08-23 15:28:55.827 Error, Node028, ERROR: Dropping command, expected 
response not received after 3 attempt(s)
2014-08-23 15:28:55.827 Detail, Node028, Removing current message 

Original comment by TJTrolin...@gmail.com on 22 Aug 2014 at 10:28

@GoogleCodeExporter
Copy link
Author

Yes... I have the same problem with the attempts.... it messes with all my 
network... I would like to have something to turn off that message.... so it 
would not mess with everything....

Original comment by santal.m...@gmail.com on 26 Sep 2014 at 10:42

@Fishwaldo
Copy link
Member

I'm guessing the rewrite of the Security CC fixed this. If not, please open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants