On Fri, 27 Aug 2004, Frederick Page wrote:
> Fred Wright schrieb am 26. August 2004:
> 
> >> 192.168.100.100 (this is m0n0wall) sent an invalid ICMP type 3, code 0
> >> to a broadcast 192.168.100.255 on eth0
> 
> >Does it really think that's a broadcast address?  What's the
> >netmask?
> 
> That's /24 (255.255.255.0) on all machines.
> 
> >If FreeBSD isn't broken, then it must have received a packet *from*
> >192.168.100.255, and didn't consider that to be a broadcast.
> 
> As Manuel suggested, I ran a tcpdump trace and found the solution:
> 
> The Linux-machine has a Samba-Server running, Samba sends UDP packets
> on Port 138 to 192.168.100.255 in order to find any Windows-machines.
> 
> The problem in front of the machine thought, it would be a clever
> idea, to REJECT UDP-Ports 137-138 on the LAN-interface of m0n0wall.
> I just blocked TCP/UDP 135-139 on the LAN-interface and the messages
> stopped ;-)
> 
> Of course m0n0 is completely innocent, it just did, what it was told:
> send "ICMP destination unreachable" when UDP traffic came in on Port
> 138.

I don't agree.  Sending known illegal packets shouldn't be possible
regardless of user configuration, unless the "configuration" involves
something specifically intended for testing.  There are *some*
misconfigurations that *can't* be detected easily (e.g. inconsistent
netmasks), but this wasn't one of them, nor was it really a
misconfiguration, anyway.

Note that it would be both inconvenient and inefficient to require two
separate rules for each such case, one for broadcast addresses, and one
for non-broadcast addresses.  Thus, what you had should *not* be
considered an error on your part (or m0n0wall's per se) - it's the code's
responsibility to check for broadcasts.

There are some questions here.  Linux apprently claimed that m0n0wall sent
the ICMP error *to* the broadcast address, but since the destination of
the error is supposed to be the *source* of the offending packet, that
implies a packet being sent *from* the broadcast address.  Doing so is
illegal, and any implementation is supposed to *silently* discard any such
packets it receives.  It's *also* illegal to send an ICMP error to a
broadcast address, in the sense that the "no broadcast as source"
condition is reiterated in the conditions for sending an ICMP error.

It's also possible that Linux is incorrectly reporting a case where the
ICMP error was merely being sent *in response to* a broadcast
(particularly since it was apparently the source of the Samba broadcasts),
though that's *also* illegal.  However, since the ICMP error is presumably
being generated by IPFilter rather than the kernel, it's possible that
IPFilter is where the trouble lies.

Do you still have the packet trace?  It would be best if it included the
link-layer headers, since the Ethernet "broadcastness" also enters into
it.  ICMP errors are supposed to be avoided if *either* the IP *or* the
link-layer address is a broadcast, though something might take a short-cut
and check only one.

BTW, Windoze sometimes (but not always) uses 137 as the *source* port for
DNS lookups, and blocking such traffic can increase DNS delays.

					Fred Wright