On 2014-05-29, Stan Gammons <[email protected]> wrote: > On 05/28/2014 04:10 PM, Philip Guenther wrote: >> On Tue, May 27, 2014 at 7:12 PM, Stan Gammons <[email protected] >> <mailto:[email protected]>> wrote: >> >> Using tcpdump -n -ttt -r /var/log/pflog I have a log entry with >> [len16<asnlen69] at the end. The packet was from port 65500 to >> 161. What is len16<asnlen69 ? >> >> >> If something in tcpdump output isn't described by the manpage, you'll >> need to check the source and see what the code generating it didn't >> like. In this case, it's likely that the higher-level protocol inside >> the packet claimed there was more data than fit in the packet. Could >> be a bug in what's generating it...or could be a bug in tcpdump's >> parser for the higher-level protocol. >> >> >> Philip Guenther >> > > > I see no reference to len or asnlen in the tcpdump man. Given the source > IP I thought it might be something odd. I haven't looked through the > tcpdump code to see what generated that type entry. This is the log > entry minus the target IP. > > May 27 04:37:36.728724 rule 63/(match) block in on em0: 125.96.160.190.65500 > > xx.xxx.xx.xx.161: [len16<asnlen69]
161 - snmp. There are all sorts of snmp probes you'll see on the internet, I've seen it quite a bit recently. In this case I'm guessing it's either a bad packet generator or it's someone trying to crash/exploit buggy snmp daemons by trying to make them read beyond the end of the packet.
