A bitter missive from last year with my previous comments on the utter stupidity of Cisco PIX syslog formatting and the magic 256 byte message truncation. Cisco still haven't fixed it, and apparently couldn't give a monkey's. Ted Ted Rule 05/09/2002 16:28 To: syslog-ng@lists.balabit.hu cc: Subject: Cisco PIX TCP Syslogging via syslog-ng More very sad news I'm afraid. I've been able to glue together a temporary copy of syslog-ng on my central syslog server listening to TCP/1468 for PIX syslogging. It is already apparent that things don't work properly - most of this appears to be entirely Cisco's fault. My original problem was that I'd reported UDP packet truncation for syslog messages > 255 characters. Cisco swore blind that my moving to TCP would fix this. tcpdump's of my test rig strongly suggests Cisco simply lied. Even the TCP stream seems to impose a 255 character limit prior to transmission. Worse still - as intimated from previous missives - the TCP stream doesn't contain EOM characters of any flavour between messages such that multiple syslog messages may appear in a single TCP packet. Moreover, sadly, syslog-ng appears to be unable to pick apart multiple messages correctly on some occasions, and hence one sees things like this: Sep 5 15:58:58 fttvgpsvpn1 %PIX-7-702301: lifetime expiring, (sa) sa_dest= 195. 188.171.5, sa_prot= 50, sa_spi= 0x6a3b8b02(1782287106), sa_trans= esp-3des esp-m d5-hmac , sa_conn_id= 8, (identity) local= 195.188.171.5, remote= 217.34.209.200 , local_proxy= 194.34.198.40/255.255.2<190>%PIX-6-602302: deleting SA, (sa) sa_d est= 195.188.171.5, sa_prot= 50, sa_spi= 0x6a3b8b02(1782287106), sa_trans= esp-3 des esp-md5-hmac , sa_conn_id= 8 where the 2 messages concatenated are actually contained in 2 separate TCP packets, as per the tcpdump below. The general logic I can deduce from the debugs so far is that the log daemon on the PIX assembles a message, truncates to 255 characters, stuffs it out the log stream ( be it UDP or TCP ). If the stream is TCP, I suspect Nagle Algorithm or similar determines when sufficient data within one or more messages have been accumulate sufficient to actually send a TCP packet. As a result, whilst any given log message is limited to 255 bytes, but any given TCP packet need not be. All in all, its a mess. I'm better off leaving the syslogging routing via UDP to ensure correct EOM determination on the syslog server. Needless to say, I'll raise a log with our Cisco resellers to try and get Cisco to fix their code. The minimum 2 requirements are: a) Raise log message size limit to 512 bytes for either UDP or TCP streams b) Terminate TCP messages with NUL or NL to allow sane logservers to unsplit the mess. I suspect there is very little Balazs can do to improve the decode of the PIX log stream without Cisco fixing their broken code. Ted 15:58:58.013327 192.168.82.15.1024 > 172.17.12.19.1468: P 878:1133(255) ack 1 win 4096 4500 0127 9d42 0000 fc06 55b2 c0a8 520f E..'.B....U...R. ac11 0c13 0400 05bc 02ff 1fde 3b30 7c08 ............;0|. 5018 1000 4360 0000 3c31 3931 3e25 5049 P...C`..<191>%PI 582d 372d 3730 3233 3031 3a20 6c69 6665 X-7-702301: life 7469 6d65 2065 7870 6972 696e 672c 2028 time expiring, ( 7361 2920 7361 5f64 6573 743d 2031 3935 sa) sa_dest= 195 2e31 3838 2e31 3731 2e35 2c20 7361 5f70 .188.171.5, sa_p 726f 743d 2035 302c 2073 615f 7370 693d rot= 50, sa_spi= 2030 7836 6133 6238 6230 3228 3137 3832 0x6a3b8b02(1782 3238 3731 3036 292c 2073 615f 7472 616e 287106), sa_tran 733d 2065 7370 2d33 6465 7320 6573 702d s= esp-3des esp- 6d64 352d 686d 6163 202c 2073 615f 636f md5-hmac , sa_co 6e6e 5f69 643d 2038 2c20 2869 6465 6e74 nn_id= 8, (ident 6974 7929 206c 6f63 616c 3d20 3139 352e ity) local= 195. 3138 382e 3137 312e 352c 2072 656d 6f74 188.171.5, remot 653d 2032 3137 2e33 342e 3230 392e 3230 e= 217.34.209.20 302c 206c 6f63 616c 5f70 726f 7879 3d20 0, local_proxy= 3139 342e 3334 2e31 3938 2e34 302f 3235 194.34.198.40/25 352e 3235 352e 32 5.255.2. 15:58:58.026581 172.17.12.19.1468 > 192.168.82.15.1024: . ack 1133 win 32120 (DF ) 4500 0028 6190 4000 4006 0e64 ac11 0c13 E..(a.@.@..d.... c0a8 520f 05bc 0400 3b30 7c08 02ff 20dd ..R.....;0|... . 5010 7d78 82af 0000 P.}x.... 15:58:58.027406 192.168.82.15.1024 > 172.17.12.19.1468: P 1133:1445(312) ack 1 w in 4096 4500 0160 9d43 0000 fc06 5578 c0a8 520f E..`.C....Ux..R. ac11 0c13 0400 05bc 02ff 20dd 3b30 7c08 .......... .;0|. 5018 1000 ca1d 0000 3c31 3930 3e25 5049 P.......<190>%PI 582d 362d 3630 3233 3032 3a20 6465 6c65 X-6-602302: dele 7469 6e67 2053 412c 2028 7361 2920 7361 ting SA, (sa) sa 5f64 6573 743d 2031 3935 2e31 3838 2e31 _dest= 195.188.1 3731 2e35 2c20 7361 5f70 726f 743d 2035 71.5, sa_prot= 5 302c 2073 615f 7370 693d 2030 7836 6133 0, sa_spi= 0x6a3 6238 6230 3228 3137 3832 3238 3731 3036 b8b02(1782287106 292c 2073 615f 7472 616e 733d 2065 7370 ), sa_trans= esp 2d33 6465 7320 6573 702d 6d64 352d 686d -3des esp-md5-hm 6163 202c 2073 615f 636f 6e6e 5f69 643d ac , sa_conn_id= 2038 0a0a 3c31 3930 3e25 5049 582d 362d 8..<190>%PIX-6- 3630 3233 3032 3a20 6465 6c65 7469 6e67 602302: deleting 2053 412c 2028 7361 2920 7361 5f64 6573 SA, (sa) sa_des 743d 2032 3137 2e33 342e 3230 392e 3230 t= 217.34.209.20 302c 2073 615f 7072 6f74 3d20 3530 2c20 0, sa_prot= 50, 7361 5f73 7069 3d20 3078 3137 6563 3539 sa_spi= 0x17ec59 3335 2834 3031 3336 3533 3031 292c 2073 35(401365301), s 615f 7472 616e 733d 2065 7370 2d33 6465 a_trans= esp-3de 7320 6573 702d 6d64 352d 686d 6163 202c s esp-md5-hmac , 2073 615f 636f 6e6e 5f69 643d 2037 0a0a sa_conn_id= 7.. ************************************************************************************************ This E-mail message, including any attachments, is intended only for the person or entity to which it is addressed, and may contain confidential information. If you are not the intended recipient, any review, retransmission, disclosure, copying, modification or other use of this E-mail message or attachments is strictly forbidden. If you have received this E-mail message in error, please contact the author and delete the message and any attachments from your computer. You are also advised that the views and opinions expressed in this E-mail message and any attachments are the author's own, and may not reflect the views and opinions of FLEXTECH Television Limited. ************************************************************************************************