implement a shared utility function for displaying an FKO context

[mrash]

Both the client and the server have their own functions for printing an FKO context. These should be consolidated into a libfko utility function.

[fjoncourt]

I have prepared a patch but not pushed anything to github yet. The test suite is running :) I have created a fko_dump_ctx_to_buffer function, but reading your request, I think it shoud be stored in fko_util.c rather than adding a new function to the libfko ABI. Or do you think such a function could be useful ?

[mrash]

Hello Franck,

Quick note before I fly home - definitely fko_util.c, and I think the dump_ctx() function used by the server is pretty close to what we want. Then the client can use it similarly to how the server uses it.

On Aug 4, 2013, at 2:12 PM, Franck Joncourt [email protected] wrote:

I have prepared a patch but not pushed anything to github yet. The test suite is running :) I have created a fko_dump_ctx_to_buffer function, but reading your request, I think it shoud be stored in fko_util.c rather than adding a new function to the libfko ABI. Or do you think such a function could be useful ?

—
Reply to this email directly or view it on GitHub.

[mrash]

Merged, thanks. Made a couple of minor additions.

[fjoncourt]

I have noticed the dump is nice formatted when running in foreground mode, but not in daemon mode through syslog.

SPA Field Values:#012=================#012   Random Value: 1876769906738013#012       Username: franck#012      Timestamp: 1376509006#012    FKO Version: 2.0#012   Message Type: 5 (Local NAT access msg)#012 Message String: 127.0.0.2,tcp/22#012     Nat Access: 127.0.0.1,22#012    Server Auth: <NULL>#012 Client Timeout: 0#012    Digest Type: 3 (SHA256)#012      HMAC Type: 3 (SHA256)#012Encryption Type: 1 (Rijndael)#012Encryption Mode: 2 (CBC)#012   Encoded Data: 1876769906738013:ZnJhbmNr:1376509006:2.0:5:MTI3LjAuMC4yLHRjcC8yMg:MTI3LjAuMC4xLDIy#012SPA Data Digest: DXispkZqZEH2qO9fzRpBMB6e0FzIRNXJQ7Jz/zn4Eoc#012           HMAC: vCemrEbmOZs03J+L2Q2LEPkvN2m4Br7to51aoVEfFOY#012 Final SPA Data: +374OdIkgHWn8fWtvFYaTKmaYMahp5vDpILqNjcASapGW9StAsGX89wkGmeWnW3uBI3dhFUZLRTvsawBlmjVfvGu/kdMS5OjuqsmGQR67TeJG7AN5251+RaPpOSxKs2H8FrdQK18+YTu8e0ISKXM91OcqQ5xpTeW19MjMPjB8BIvO7rGGB/Laz

rather than

[127.0.0.1] (stanza #1) SPA Decode (res=0):
SPA Field Values:
=================
   Random Value: 1321457858621119
       Username: franck
      Timestamp: 1376509202
    FKO Version: 2.0
   Message Type: 5 (Local NAT access msg)
 Message String: 127.0.0.2,tcp/22
     Nat Access: 127.0.0.1,22
    Server Auth: <NULL>
 Client Timeout: 0
    Digest Type: 3 (SHA256)
      HMAC Type: 3 (SHA256)
Encryption Type: 1 (Rijndael)
Encryption Mode: 2 (CBC)
   Encoded Data: 1321457858621119:ZnJhbmNr:1376509202:2.0:5:MTI3LjAuMC4yLHRjcC8yMg:MTI3LjAuMC4xLDIy
SPA Data Digest: Ijn4/jLbNHXG06hNpqTJRy/DeuW+eYgZsQr6dHN77Lo
           HMAC: BDfUyTO9AgWidE0uaYtFyap5sv9VOWA9Kpmxsdr7h54
 Final SPA Data: 9mAnBJlhC9HNgsKpP2OWgP9RGKNL7Lui8Sr9aBVKDydFSC2ZJFSZhwKLhwlmMGohTgmm8+lbExXqqcuQXmIy7st5Sd2EfxRO6Y8CTYYPJcPlOdMiflFt7F2DNWTTU2m4jg/2rtafHOnsYuZEKTIB+EAuqsbiy/7kTZIjPUOHQIJbcyBOG64Ekj

Sad :(

[fjoncourt]

I have found a way to avoid syslog from stripping newlines by adding $EscapeControlCharactersOnReceive off to its configuration file.

Aug 14 21:53:16 franck fwknopd[19320]: [127.0.0.1] (stanza #1) SPA Decode (res=0):
SPA Field Values:
=================
   Random Value: 1978276251963699
       Username: franck
      Timestamp: 1376509996
    FKO Version: 2.0
   Message Type: 5 (Local NAT access msg)
 Message String: 127.0.0.2,tcp/22
     Nat Access: 127.0.0.1,22
    Server Auth: <NULL>
 Client Timeout: 0
    Digest Type: 3 (SHA256)
      HMAC Type: 3 (SHA256)
Encryption Type: 1 (Rijndael)
Encryption Mode: 2 (CBC)
   Encoded Data: 1978276251963699:ZnJhbmNr:1376509996:2.0:5:MTI3LjAuMC4yLHRjcC8yMg:MTI3LjAuMC4xLDIy
SPA Data Digest: QWggi+GAgMcUmKYh9ZZ5nVvaLBF7S8ywpKFuqmzH1xE
           HMAC: z1b1zlP1k1sF2PL2f+YOTHScEBSrptUvKZbHSnjm0M4

I do not know about other loggers. Any idea what should be done?

[mrash]

On Wed, Aug 14, 2013 at 3:56 PM, Franck Joncourt
[email protected]:

I have found a way to avoid syslog from stripping newlines by adding $EscapeControlCharactersOnReceive
off to its configuration file.

Aug 14 21:53:16 franck fwknopd[19320]: [127.0.0.1](stanza #1) SPA Decode (res=0):

SPA Field Values:

Random Value: 1978276251963699
Username: franck
Timestamp: 1376509996
FKO Version: 2.0
Message Type: 5 (Local NAT access msg)
Message String: 127.0.0.2,tcp/22
Nat Access: 127.0.0.1,22
Server Auth:
Client Timeout: 0
Digest Type: 3 (SHA256)
HMAC Type: 3 (SHA256)
Encryption Type: 1 (Rijndael)
Encryption Mode: 2 (CBC)
Encoded Data: 1978276251963699:ZnJhbmNr:1376509996:2.0:5:MTI3LjAuMC4yLHRjcC8yMg:MTI3LjAuMC4xLDIy
SPA Data Digest: QWggi+GAgMcUmKYh9ZZ5nVvaLBF7S8ywpKFuqmzH1xE
HMAC: z1b1zlP1k1sF2PL2f+YOTHScEBSrptUvKZbHSnjm0M4

I do not know about other loggers. Any idea what should be done?

Thanks for catching this. How about modifying dump_ctx_to_buffer() to add
a new "is_syslog" flag? If true, then dump_buf would be formatted as a
single string without newline chars, each field would be printed as "field:
," (with the trailing comma if there is another field after the
current one), and there would be no additional spaces between each field.
Also, the "SPA Field Values:" and "====..." strings would not be included.
The end result would be a syslog-friendly string that starts like "Random
Value: , Username: , Timestamp: . ...". If the
"is_syslog" flag is false, then the current format would be used. This way
the caller can decide whether the FKO dump buffer needs to be formatted for
a syslog destination or a normal stdout destination, and
dump_ctx_to_buffer() doesn't need to know anything about this (beyond
whether is_syslog is true or not). How does this sound?

Thanks,

--Mike

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/95#issuecomment-22662661
.

Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F

[mrash]

Reopening based on the previous comment and Franck's catch for the syslog formatting issue.

[fjoncourt]

I thought about it this last weekend and my idea was to upgrade the log_msg
function to handle \r or \n char by itself. I mean if a message contains \r\n
or \n then we can split it in severals parts and call vsyslog several times. I
have not looked at the code yet to check whether it is easy to do or not.

Otherwise we can do as you said. I would prefer not to change the
dump_ctx_to_buffer behavior according to a status flag since I think everything
about logging should stay in the log module, and this is specially a problem
occuring with syslog.

I will have a look at it this coming weekend along with the verbose mode. This
week is a bit busy.

Talk to you soon.