kern/76966: udp/520 reply packets when routed is not running

[Emil Cazamir]

-----Original Message-----
From: owner-freebsd-bugs at freebsd.org [mailto:owner-freebsd-bugs at freebsd.org]
On Behalf Of David Malone
Sent: 6 februarie 2005 19:50
To: freebsd-bugs at FreeBSD.org
Subject: Re: kern/76966: udp/520 reply packets when routed is not running

The following reply was made to PR kern/76966; it has been noted by GNATS.

From: David Malone <dwmalone at maths.tcd.ie>
To: Emil Cazamir <emil.cazamir at galati.rdsnet.ro>
Cc: FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: kern/76966: udp/520 reply packets when routed is not running
Date: Sun, 6 Feb 2005 17:41:15 +0000

 On Tue, Feb 01, 2005 at 05:35:28PM +0200, Emil Cazamir wrote:
 > >Description:
 > 	The FreeBSD kernel seems to respond to udp/520 packets even when
 > there is no such daemon running.
 
 There's no code in the FreeBSD kernel for doing this, however I think
 I know what is going on...
 
 > 17:03:32.185977 0:f:3d:47:8b:de ff:ff:ff:ff:ff:ff 0800 60:
192.168.0.10.520
 > > 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
 > 17:03:32.186153 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
 > 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
 
 Your FreeBSD maching gets a packet for 192.168.0.255 - I suspect
 you have the netmask on your FreeBSD machine set incorrectly so it
 does not consider this a broadcast address. Consequently, it probably
 considers this a misdirected packet and so sends an ICMP redirect
 and then forwards the packet, in this case to the default router.
 
 I'm not sure why the source address on the packet has changed -
 that bit seems a bit odd.
 
 	David.
_______________________________________________
freebsd-bugs at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at freebsd.org"

There is no problem with the netmask, there are several subnets sharing the
same wire. I lokked into few kernel config files and I didn't found anything
specific. I think that the cause of what's happening is somewhere in
natd/libalias, all the machines which respond to [or  forward] udp/520
packets are running natd. I will make available kernel config files, process
listings, etc if it is required.

Best regards,
Emil Cazamir