I have a little problem with a PIX using UDP syslog to an old syslogd server, which I'm hoping members of the list may be able to assist me with. Some time ago, I noticed that some of the bigger messages were being truncated. Further investigation suggested that Cisco were imposing a 256 character limit on messages sent via syslog. The problem is rarely seen - mostly it shows up with IPSEC key renewal messages which happen to be very long. After several "oh yes it does, oh no it doesn't" rounds of trying to convince our suppliers, and in turn Cisco - who initially swore blind they couldn't reproduce the fault - Cisco finally admitted that they do indeed impose a 256 limit on UDP syslog messages. The PIX is perfectly capable of handling bigger UDP messages than that - it has to do in order just to process DNS messages - so the problem only affects the PIX UDP syslog stream. Cisco also recommend , of course, using TCP instead, which they haven't apparently imposed such a restriction on; TCP usage would also help to improve the general security of the logging process, which would also be a good thing anyway. Cisco don't appear to be very interested in my request to patch the UDP message buffer size; I think it would be nothing more than a single line code change to raise the buffer size to 512 which should easily cover any IPSEC syslog messages I can see being truncated. I'm strongly considering migrating the syslog server to syslog-ng so that I could support TCP syslog streams anyway, but in order to defend against any migration problems I wanted a backup plan for PIX TCP stream support. My current plan is some form of very temporary perl daemon listening on TCP redirecting to the Unix Domain syslog socket. So. Does anyone on the list have experience of Cisco PIX TCP Syslog stream talking to syslog-ng? Does anyone on the list have a good idea of the internal layout of the PIX TCP syslog stream - in particular how is the end of message encoded? ( Under UDP of course , EOM is implied by end of packet, but under TCP some explicit EOM marker would have(?) to be added to the stream. ) Would anyone be able to send me some tcpdumps or similar for me to decode the format so that I could generate some test data to fire at the listener? Ted *************************************************************************************************** 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. ***************************************************************************************************