Lo, on Sunday, December 31, JD Kitch did write: > > Now, find out *who's* sending this traffic. Make sure you've got the > > lsof-2.2 package installed. As root, run > > > > lsof | grep 61662 | grep -i udp > > I do have that package, but this command turned up no output.
Uh oh. And you're still getting these log messages? That's probably not good. It's possible that lsof could slip through the cracks, so to speak, but it's pretty unlikely. > Just yesterday I got another machine connected to this one via a > second nic, and I have a windows machine attched that I'm > masquerading for, but that is not the IP i configured that machine > to be. I'm certainly not knowingly running anything for SNMP, hell, > I don't even know what it is. :P Any ideas, what I might be running > that would cause this? I've not worked with masquerading much; I use ipchains primarily for firewalling. It's possible (though, I think, fairly unlikely) that this record is due to packets you're relaying for the Windows box. That's easy to test: ipchains -I input 1 -s <windows-box's-IP> -p udp -d 0.0.0.0/0 161 -l -j DENY will block all traffic from the windows machine to port 161/udp ANYWHERE, as it enters your Debian machine. If you stop getting these REJECT messages on your output chain and start getting DENY messages on your input chain, then that's the deal. If that's the case, then the Windows box is likely running some sort of SNMP software, so you'll need to consult your local Windows guru for further instructions. Otherwise, it's not that. Yank the rule: ipchains -D input 1 I'm not very familiar with the Debian packages, as yet. The only ones I know of that deal with SNMP at all are snmp (the client), snmpd (the server), and associated libraries. It's been a while since I've done SNMP, but I don't think that either of these two packages would cause this kind of behavior; the port numbers look bogus. SNMP is the Simple (ahem!) Network Management Protocol; it's basically intended for monitoring and administering various devices across the network. The SNMP folks redid the terminology for no adequately-explained reason (although I think the telephone companies may have had their fingers in this pie)---rather than client/server, they have manager/agent. Sorta makes sense, but there's no reason to come up with new terms. Anyway: manager (think network administrator sitting at a console watching his network) sends out a query to one of the agents, which responds with the requested data. The manager also has the ability to write to the agents (drop this route, reboot yourself), and there are provisions for allowing the agents to send asynchronous notifications to the manager (though those typically use port 162/udp on the manager side). The data supplied by each agent varies from machine to machine, but it typically contains stuff like network performance metrics (# dropped packets), network configuration (routing tables), and so forth. It's been some time since I've worked with SNMP (I actually had to port a manager, developed in-house, from Solaris <yuk> to Windows NT <double yuk>), so the details are a little foggy. The agents (== servers) do have to listen on port 161/udp, but I don't know that there's any requirement that the managers use a specific port. Likewise, I think the agents can send their response out any port, but 99 times out of 100, they'll just use 161/udp, since they've already got it open. Since you seem to be sending *to* port 161, that would suggest that you (or the windows box) is acting as a manager. That's not generally something that runs unless you specifically start it, though. Here's a thought---try installing ethereal, run it as root, and see if you can't snoop the packets that are causing this message. Filter on destination IP and port; unfortunately, I don't remember the details of ethereal's filter syntax. There's also a good chance you'll have to install libsnmp for the decode to work. Then, drop the ipchains rule that's blocking this traffic and get a record of what exactly is going on here. Send that along, and we'll see if we can't figure out what's happening. (Once you've finished with ethereal, you'll probably want to reload the rule.) Good luck, Richard
