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