It’s not a nice text file, or even a Sqlite3 database file like my log files are. But if I use logrotate on the file generated by tshark, it gets broken when I snip it from the outside. If I can do this with the pacap files, that would be ideal. Normally, I use logrotate, and rotate the logs every 24 hours, keeping only 2 weeks worth. I want the file to roll over like my log files do. I can’t consume all of the disk space on a single, giant pcap file that spans weeks. That’s where I was born and raised on computer interfaces. Plus, you know me: I’m more comfortable on a command line. There is no GUI desktop interface to run Wireshark on, and I’m usually connected over an SSH terminal anyway. This is handy because my embedded systems are command line only. I can run tshark on the command line to capture the packets. Because if I get to the point where I’m bothering to do this, we have an intermittent problem that’s proven elusive. Now, I need to capture these packets over the course of several days. Honestly, the logs my program generates give me everything I need to know, but capturing the actual traffic on the network card will give me more proof that the problem is not me, or provide a valuable clue as to where my code has gone wrong. So sometimes I need to get right down to the network card and take a look at what’s actually happening to get to the bottom of the problem. But I never have control of the network and the clients that talk to my machine. I have the luxury of controlling the machine and OS my software runs on, as it’s more of an embedded system. The program will work perfectly fine everywhere but on the one customer’s network. Instead, I get a lot of “It Doesn’t Work On My Machine Only” from customers. Often, I have the opposite problem of the classic “It Works On My Machine” issue. I write a lot of network enabled programs for my day job.
0 Comments
Leave a Reply. |