Subject: tlp0: filter setup and transmit failure
To: None <current-users@netbsd.org>
From: Richard Rauch <rauch@rice.edu>
List: current-users
Date: 12/15/2001 23:59:00
I've put -current (1.5Y; snapshot from around Dec. 1 or Dec. 6; GENERIC
kernel compiled on Nov. 10th by root@celeron) on my Gateway 2000 machine.
I have an immediate problem, and a warning that may be related.  The
warning is a repeated event that is logging to my dmesg:

tlp0: filter setup and transmit timeout

This message came up, once, when I was booting.  After (manually) starting
ipf/ipnat and trying to do some stuff (which failed; see below), I did a
tcpdump.  At that point, the ``tlp0: filter ...'' message began to repeat,
about once per second.  tlp0 is working in general.  (I can ssh in from
another machine, etc.)  (tlp0 is the link to my LAN; rtk0 is also in
there, as a link to an ADSL modem.)


The thing that FAILS is getting ipnat to work.  The system acts as if I
did not have ipnat set up at all.  (Under 1.5.2, everything pretty much
worked, modulo some problems with MSS/etc., which were more or less
resolved on netbsd-help.  I should not have any changes in /etc, as I
didn't touch that directory.)

To update, I simply unpacked all of the non-/etc .tgz files onto my drive,
and rebooted with the GENERIC -current kernel from the same snapshot.  My
old /etc directory should not have been touched in the update (I manually
extracted every non-/etc .tgz archive on top of the existing system).  I
haven't yet looked to see if I can/should modify anything in /etc for the
new system.


My ipnat.conf and ipf.conf files are fairly trivial.  Things are just set
up to make NAT work, at the moment; no blocking/firewalling is done.

I'd like NAT to work again.  Getting rid of the errors wouldn't hurt, but
isn't so important.  (Once I get that working, maybe I can start to track
-current...(^&)  (Alternatively, if updating source from the 1.5.2 is as
easy as a CVS update (cvs update issued from /usr/src ?), then I could
just grab the latest sources and try to build a new kernel from there.)

dmesg, etc., can be extracted and posted if people want to see them.
(Though I suspect that I'd have to reboot, since the warnings have
probably scrolled much of the valuable dmesg information out of the buffer
by now...)


Thanks in advance for any help.


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu