Christopher Brannon writes: > Yep, this is a buffer overrun. Additionally, the OP isn't > checking the return value of read(). It returns -1 on failure, in which > case, it should not be used as an index into the buffer. Even though I am not supposed to be receiving anywhere near a full buffer's worth of data, it has got to be a reference pointer problem of some kind. I did experiment with a smaller buffer but nothing changed. One would have expected the garbage data to be different but it was always the same string fragment. When I figure it out, I will tell you what I found. I know that the serial routines under Linux are supurb so I am sure I just have something configured wrong. I spent the first day perplexed because I wasn't even sure whether I needed a null modem or not. I couldn't get anything to come back. It turns out that the hardware flow control needs to be absolutely shut off as the radio doesn't even fake it by leaving the correct lines on all the time. If your communicator program is looking to use CTS or RTS, you will be waiting forever. As soon as I took that out, it started talking big time. I was never so glad to see an error message in all my life. If you send anything other than a valid command, even an empty carriage return, the radio responds with "ERR" I almost think I hear it laughing at me. Thanks for all of your suggestions. Martin _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list