Since enabling (but not yet using) firewalling in the 2.4.1 kernel, my log
gets clobbered with messages like:
Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.21 -> 224.0.0.2
Feb 1 12:59:01 obelix kernel: NAT: 0 dropping untracked packet ce767480 1 129.69.22.21 -> 224.0.0.2
Feb 1 12:59:04 obelix kernel: NAT: 0 dropping untracked packet ce767d80 1 129.69.22.21 -> 224.0.0.2
Feb 1 13:00:44 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.51 -> 224.0.0.2
Feb 1 13:00:47 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.51 -> 224.0.0.2
Feb 1 13:00:50 obelix kernel: NAT: 0 dropping untracked packet ce767b40 1 129.69.22.51 -> 224.0.0.2
The IP Adresses belong to Windows 98 computers. What does the message mean,
and what could I do to stop them?
Nils
--
*New* *New* *New* - on shellac records
Windows HE - see top 10 reasons to downgrade on
Historical Edition http://www.microsoft.com/windowshe
On Thu, 01 Feb 2001, Nils Rennebarth wrote:
> Since enabling (but not yet using) firewalling in the 2.4.1 kernel, my log
> gets clobbered with messages like:
>
> Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.21 -> 224.0.0.2
>
> The IP Adresses belong to Windows 98 computers. What does the message mean,
> and what could I do to stop them?
It means that your box drops multicast administrative packets on the
floor.
--
Matthias Andree
Hi
do the messages apear when the windows machines a booting ?
i would tend to think that the kernel cannot handle the NET on
IGMP packets so its printting a message about it
the packets do look like they are goign to a multicast address
>
>Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.21 -> 224.0.0.2
>Feb 1 12:59:01 obelix kernel: NAT: 0 dropping untracked packet ce767480 1 129.69.22.21 -> 224.0.0.2
>Feb 1 12:59:04 obelix kernel: NAT: 0 dropping untracked packet ce767d80 1 129.69.22.21 -> 224.0.0.2
>Feb 1 13:00:44 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.51 -> 224.0.0.2
>Feb 1 13:00:47 obelix kernel: NAT: 0 dropping untracked packet ce767600 1 129.69.22.51 -> 224.0.0.2
>Feb 1 13:00:50 obelix kernel: NAT: 0 dropping untracked packet ce767b40 1 129.69.22.51 -> 224.0.0.2
>
--
---------------------------------------------
Check Out: http://stev.org
E-Mail: [email protected]
3:00pm up 16 days, 22:21, 4 users, load average: 1.37, 1.38, 1.25
In article <[email protected]> you write:
> On Thu, 01 Feb 2001, Nils Rennebarth wrote:
> > Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet
> ce767600 1 129.69.22.21 -> 224.0.0.2
>
> It means that your box drops multicast administrative packets on the
> floor.
I'm getting the occasional
Feb 1 13:17:08 yendi kernel: NAT: 0 dropping untracked packet
c3ea4da0 1 146.188.249.73 -> 209.220.232.240
syslog message. What exactly does it mean? 146.188.249.73 isn't my
machine at all, and 209.220.232.240 is my firewall. I assume I'm
dropping someone's packets on the floor, but what can cause a packet
to get dropped like that?
--
Dave Meyer
[email protected]
This is explained in the netfilter FAQ.
http://netfilter.kernelnotes.org/netfilter-faq-3.html#ss3.1
/ Magnus
On Thu, 1 Feb 2001 [email protected] wrote:
> I'm getting the occasional
>
> Feb 1 13:17:08 yendi kernel: NAT: 0 dropping untracked packet
> c3ea4da0 1 146.188.249.73 -> 209.220.232.240
>
> syslog message. What exactly does it mean? 146.188.249.73 isn't my
> machine at all, and 209.220.232.240 is my firewall. I assume I'm
> dropping someone's packets on the floor, but what can cause a packet
> to get dropped like that?
>
> --
> Dave Meyer
> [email protected]
dmeyer <[email protected]> writes:
>
> In article <[email protected]> you write:
>> On Thu, 01 Feb 2001, Nils Rennebarth wrote:
>> > Feb 1 12:58:56 obelix kernel: NAT: 0 dropping untracked packet
>> ce767600 1 129.69.22.21 -> 224.0.0.2
>>
>> It means that your box drops multicast administrative packets on the
>> floor.
>
> I'm getting the occasional
>
> Feb 1 13:17:08 yendi kernel: NAT: 0 dropping untracked packet c3ea4da0
> 1 146.188.249.73 -> 209.220.232.240
>
> syslog message. What exactly does it mean? 146.188.249.73 isn't my
> machine at all, and 209.220.232.240 is my firewall. I assume I'm
> dropping someone's packets on the floor, but what can cause a packet
> to get dropped like that?
The one big thing I know of that causes these messages is a
long-standing bug in the FreeBSD and OpenBSD (and presumably NetBSD, I
don't know about that one, though) network stacks.
When sending an ICMP host unreachable response to a DF packet, some of
the packet was byte-swapped.
The bytes were *only* in the segment of the original IP packet appended
to the ICMP message for identification purposes.
Under normal conditions this packet works fine with Linux. The
connection is killed, all is fine.
When running netfilter and connection tracking, netfilter uses these
byte-swapped fields to associate the ICMP message with the original TCP
or UDP packets.
Because the fields are out-of-order, this match fails. netfilter then
drops the packet on the floor and generates the 'untracked packet'
message.
FreeBSD have fixes their network stack not that long ago. I believe that
their 5.0 release corrects the bug, but I am not sure of that. Check
with them if you really care.
I don't believe that OpenBSD have corrected this problem at this stage
but, again, I have not checked recently. Check with them if you really
care.
This bug is *only* triggered when the packet has DF set. Normal packets
don't trigger that particular buggy code path.
Daniel
--
The truth knocks on the door and you say, 'Go away, I'm looking for
the truth,' and so it goes away. Puzzling...
-- Robert Pirsig