On May 11, 2010, at 9:19 PM, Robert Spier wrote: > FWIW, I'm still a little concerned about potentially breaking the p0f > plugin for people using the other qpsmtpd engines, but I'm happier to > have someone properly maintaining it, and we'll deal with fallout > later, if any. (Because it'll be pretty obvious when it breaks.)
I would agree with you entirely, except that before this patch, p0f support was already broken. For everybody. The minimum information the p0f plugin needs to match a TCP fingerprint against a p0f cache entry is the local_ip, local_port, remote_ip, and remote_port. The local elements weren't being set for any qpsmtpd engines. I'm guessing they were being set when the p0f plugin was written, and got subsequently removed. Now they are being set for the tcpserver based ones and thus p0f will work for them. Matt > Robert Spier wrote: >> >> >> Applied as 671a6953b0c9503717bda10dd07f434cbd302c9c >> >> Matt Simerson wrote: >>> >>> (patch remade against latest rspier/qpsmtpd) >>> >>> added remote_port, local_ip, local_port, and local_host to $qp->connection, >>> as the p0f plugin relies on it. >>> added notes to TcpServer.pm and the p0f plugin noting the dependence, and >>> the lack of support for models other than tcpserver.
