From nobody@FreeBSD.org  Sun Jun 11 08:01:12 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1DF1A16A418
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 11 Jun 2006 08:01:12 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 83F6743D48
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 11 Jun 2006 08:01:11 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k5B81BMY060142
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 11 Jun 2006 08:01:11 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k5B81B9E060141;
	Sun, 11 Jun 2006 08:01:11 GMT
	(envelope-from nobody)
Message-Id: <200606110801.k5B81B9E060141@www.freebsd.org>
Date: Sun, 11 Jun 2006 08:01:11 GMT
From: Dmitry Sergienko <dmitry@trifle.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: fastforwarding routes packets to network ip address
X-Send-Pr-Version: www-2.3

>Number:         98799
>Category:       kern
>Synopsis:       [netinet] fastforwarding routes packets to network ip address
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jun 11 08:10:18 GMT 2006
>Closed-Date:    Mon Feb 12 12:58:43 GMT 2007
>Last-Modified:  Mon Feb 12 13:00:22 GMT 2007
>Originator:     Dmitry Sergienko
>Release:        6.1-PRERELEASE
>Organization:
Trifle Co., Ltd.
>Environment:
FreeBSD sprinter.apex.dp.ua 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #4: Fri Feb 17 00:03:43 EET 2006     root@sprinter.apex.dp.ua:/usr/obj/usr/src/sys/SPRINTER  i386

>Description:
When enabling net.inet.ip.fastforwarding any ip packet (i.e. ping) to
network ip address is being forwarded to broadcast MAC address.

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet 172.16.128.33 netmask 0xfffffff8 broadcast 172.16.128.39
        ether 00:0e:0c:a8:50:a3
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 172.16.128.78 netmask 0xffffffe0 broadcast 172.16.128.95
        ether 00:0e:0c:a8:50:a3
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
        vlan: 2 parent interface: em0

# arp -n 172.16.128.32
? (172.16.128.32) at ff:ff:ff:ff:ff:ff on em0 permanent [ethernet]

and now we send ping from 172.16.128.88 to 172.16.128.32:

# tcpdump -nepi em0 icmp
19:00:09.957790 00:15:f2:5c:58:31 > 00:0e:0c:a8:50:a3, ethertype IPv4 (0x0800), length 98: 172.16.128.88 > 172.16.128.32: ICMP echo request, id 57092, seq 0, length 64
19:00:09.957798 00:0e:0c:a8:50:a3 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 98: 172.16.128.88 > 172.16.128.32: ICMP echo request, id 57092, seq 0, length 64

When fastforwarding is off no packet to broadcast MAC address is being
forwarded:

# sysctl net.inet.ip.fastforwarding=0
net.inet.ip.fastforwarding: 1 -> 0
# tcpdump -nepi em0  icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
626434 packets received by filter
0 packets dropped by kernel


Below is a dump of sysctl net.inet variables:
net.inet.ip.portrange.randomtime: 45
net.inet.ip.portrange.randomcps: 10
net.inet.ip.portrange.randomized: 1
net.inet.ip.portrange.reservedlow: 0
net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.hilast: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.forwarding: 1
net.inet.ip.redirect: 1
net.inet.ip.ttl: 64
net.inet.ip.rtexpire: 3600
net.inet.ip.rtminexpire: 10
net.inet.ip.rtmaxcache: 128
net.inet.ip.sourceroute: 0
net.inet.ip.intr_queue_maxlen: 50
net.inet.ip.intr_queue_drops: 10106094
net.inet.ip.accept_sourceroute: 0
net.inet.ip.keepfaith: 0
net.inet.ip.gifttl: 30
net.inet.ip.same_prefix_carp_only: 0
net.inet.ip.subnets_are_local: 0
net.inet.ip.dummynet.debug: 0
net.inet.ip.dummynet.red_max_pkt_size: 1500
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.max_chain_len: 16
net.inet.ip.dummynet.expire: 1
net.inet.ip.dummynet.search_steps: 430788827
net.inet.ip.dummynet.searches: 430303593
net.inet.ip.dummynet.extract_heap: 16
net.inet.ip.dummynet.ready_heap: 16
net.inet.ip.dummynet.curr_time: 40209021
net.inet.ip.dummynet.hash_size: 64
net.inet.ip.fastforwarding: 0
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.static_count: 35
net.inet.ip.fw.dyn_max: 4096
net.inet.ip.fw.dyn_count: 0
net.inet.ip.fw.curr_dyn_buckets: 256
net.inet.ip.fw.dyn_buckets: 256
net.inet.ip.fw.verbose_limit: 100
net.inet.ip.fw.verbose: 1
net.inet.ip.fw.debug: 1
net.inet.ip.fw.one_pass: 0
net.inet.ip.fw.autoinc_step: 100
net.inet.ip.fw.enable: 1
net.inet.ip.maxfragpackets: 1056
net.inet.ip.maxfragsperpacket: 16
net.inet.ip.fragpackets: 0
net.inet.ip.check_interface: 0
net.inet.ip.random_id: 0
net.inet.ip.sendsourcequench: 0
net.inet.ip.process_options: 1
net.inet.icmp.maskrepl: 0
net.inet.icmp.icmplim: 200
net.inet.icmp.bmcastecho: 0
net.inet.icmp.reply_src: 
net.inet.icmp.icmplim_output: 1
net.inet.icmp.log_redirect: 0
net.inet.icmp.drop_redirect: 0
net.inet.icmp.maskfake: 0
net.inet.tcp.rfc1323: 1
net.inet.tcp.mssdflt: 512
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 65536
net.inet.tcp.keepinit: 75000
net.inet.tcp.delacktime: 100
net.inet.tcp.hostcache.purge: 0
net.inet.tcp.hostcache.expire: 3600
net.inet.tcp.hostcache.count: 13
net.inet.tcp.hostcache.bucketlimit: 30
net.inet.tcp.hostcache.hashsize: 512
net.inet.tcp.hostcache.cachelimit: 15360
net.inet.tcp.reass.overflows: 0
net.inet.tcp.reass.maxqlen: 48
net.inet.tcp.reass.cursegments: 0
net.inet.tcp.reass.maxsegments: 2112
net.inet.tcp.insecure_rst: 0
net.inet.tcp.rfc3390: 1
net.inet.tcp.rfc3042: 1
net.inet.tcp.drop_synfin: 0
net.inet.tcp.delayed_ack: 1
net.inet.tcp.blackhole: 0
net.inet.tcp.log_in_vain: 0
net.inet.tcp.newreno: 1
net.inet.tcp.local_slowstart_flightsize: 4
net.inet.tcp.slowstart_flightsize: 1
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.sack.globalholes: 0
net.inet.tcp.sack.globalmaxholes: 65536
net.inet.tcp.sack.maxholes: 128
net.inet.tcp.sack.enable: 1
net.inet.tcp.inflight.stab: 20
net.inet.tcp.inflight.max: 1073725440
net.inet.tcp.inflight.min: 6144
net.inet.tcp.inflight.debug: 0
net.inet.tcp.inflight.enable: 1
net.inet.tcp.isn_reseed_interval: 0
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.pcbcount: 111
net.inet.tcp.do_tcpdrain: 1
net.inet.tcp.tcbhashsize: 512
net.inet.tcp.minmssoverload: 0
net.inet.tcp.minmss: 216
net.inet.tcp.syncache.rexmtlimit: 3
net.inet.tcp.syncache.hashsize: 512
net.inet.tcp.syncache.count: 0
net.inet.tcp.syncache.cachelimit: 15359
net.inet.tcp.syncache.bucketlimit: 30
net.inet.tcp.syncookies: 1
net.inet.tcp.always_keepalive: 1
net.inet.tcp.rexmit_slop: 200
net.inet.tcp.rexmit_min: 30
net.inet.tcp.msl: 30000
net.inet.udp.checksum: 1
net.inet.udp.maxdgram: 9216
net.inet.udp.recvspace: 41600
net.inet.udp.strict_mcast_mship: 0
net.inet.udp.blackhole: 0
net.inet.udp.log_in_vain: 0
net.inet.raw.recvspace: 8192
net.inet.raw.maxdgram: 8192
net.inet.accf.unloadable: 0

>How-To-Repeat:

>Fix:
Workaround is to disable fastforwarding.

>Release-Note:
>Audit-Trail:

From: Colin Petrie <cpetrie@xcalibre.co.uk>
To: bug-followup@FreeBSD.org,  dmitry@trifle.net
Cc:  
Subject: Re: kern/98799: [netinet] fastforwarding routes packets to network
 ip address
Date: Tue, 27 Jun 2006 11:58:57 +0100

 This is a multi-part message in MIME format.
 --------------020208010008040701020709
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Hi,
 
 This patch should fix your issue, could you give it a try and let me 
 know if it works?
 
 I make no promises about this code being any good but it appears to do 
 the job at my end where I have the same problem
 
 Please let me know if this helps
 
 Regards,
 
 Colin
 
 --------------020208010008040701020709
 Content-Type: text/x-patch;
  name="fastfwd.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="fastfwd.patch"
 
 *** ip_fastfwd.c	Tue Jun 27 11:29:01 2006
 --- ip_fastfwd.c.new	Tue Jun 27 11:30:18 2006
 *************** ip_fastforward(struct mbuf *m)
 *** 162,167 ****
 --- 162,168 ----
   	u_short sum, ip_len;
   	int error = 0;
   	int hlen, mtu;
 + 	int isbroadcast;
   #ifdef IPFIREWALL_FORWARD
   	struct m_tag *fwd_tag;
   #endif
 *************** ip_fastforward(struct mbuf *m)
 *** 275,280 ****
 --- 276,282 ----
   		goto drop;
   	}
   
 + 
   #ifdef ALTQ
   	/*
   	 * Is packet dropped by traffic conditioner?
 *************** passin:
 *** 421,426 ****
 --- 423,439 ----
   	 */
   	if (ro.ro_rt->rt_flags & RTF_BLACKHOLE)
   		goto drop;
 + 
 +         /*
 +          * Is packet a directed network broadcast packet?
 +          */
 +         isbroadcast = in_broadcast(dst->sin_addr, ifp);  
 +         if (isbroadcast) {
 + 		printf("ip_fastfwd: dropping directed broadcast - to %s\n",
 + 			inet_ntoa(dst->sin_addr));
 +                 ipstat.ips_badaddr++;
 +                 goto drop;
 +         }
   
   	/*
   	 * Step 5: outgoing firewall packet processing
 
 --------------020208010008040701020709--
Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Mon Sep 25 13:31:13 UTC 2006 
Responsible-Changed-Why:  
This is similar, but not identical to, kern/99484. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=98799 
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Mon Sep 25 15:33:35 UTC 2006 
State-Changed-Why:  
We're mulling over the best way to fix this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=98799 

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Dmitry Sergienko <dmitry@trifle.net>, 
 Colin Petrie <cpetrie@xcalibre.co.uk>
Subject: Re: kern/98799: [netinet] fastforwarding routes packets to network
 ip address
Date: Sat, 03 Feb 2007 06:15:30 +0000

 This is a multi-part message in MIME format.
 --------------060905000605030209020006
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Hi,
 
 The fix in the PR is not the right fix. in_broadcast() can potentially 
 return an IPv4 destination address as not being a broadcast address, 
 because it only walks the address list hung off the single ifnet pointer 
 provided.
 
 A more correct check is to perform the route lookup, and *then* check 
 for the RTF_BROADCAST flag, much as the RTF_BLACKHOLE check works, as 
 the PATRICIA trie code will then do the right thing. This does not, 
 however, prevent a hostile party from tying up CPU resources by the call 
 to ip_findroute().
 
 A patch which does this is attached. If you could test with this patch 
 and let me know, then I will commit the fix to -CURRENT.
 
 Regards,
 BMS
 
 
 --------------060905000605030209020006
 Content-Type: text/x-patch;
  name="dropbroadcasts.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="dropbroadcasts.diff"
 
 Index: ip_fastfwd.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/netinet/ip_fastfwd.c,v
 retrieving revision 1.37
 diff -u -p -r1.37 ip_fastfwd.c
 --- ip_fastfwd.c	17 Aug 2006 00:37:03 -0000	1.37
 +++ ip_fastfwd.c	3 Feb 2007 06:11:08 -0000
 @@ -418,9 +418,11 @@ passin:
  	ifp = ro.ro_rt->rt_ifp;
  
  	/*
 -	 * Immediately drop blackholed traffic.
 +	 * Immediately drop blackholed traffic, and directed broadcasts
 +	 * for either the all-ones or all-zero subnet addresses on
 +	 * locally attached networks.
  	 */
 -	if (ro.ro_rt->rt_flags & RTF_BLACKHOLE)
 +	if ((ro.ro_rt->rt_flags & (RTF_BLACKHOLE|RTF_BROADCAST)) != 0)
  		goto drop;
  
  	/*
 
 --------------060905000605030209020006--

From: Dmitry Sergienko <dmitry@trifle.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Bruce M Simpson <bms@incunabulum.net>, 
 Colin Petrie <cpetrie@xcalibre.co.uk>
Subject: Re: kern/98799: [netinet] fastforwarding routes packets to network
 ip address
Date: Mon, 05 Feb 2007 00:55:38 +0200

 Hi!
 
 Bruce, I've applied your patch to 6.2-STABLE. Broadcasts are absent with fastworwarding 
 enabled:
 
 # tcpdump -nepi fxp0 net 172.18.18.0/24
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
 00:34:30.351469 00:0e:0c:33:b8:2a > 00:a9:40:0f:83:a5, ethertype IPv4 (0x0800), length 98: 
 192.168.2.31 > 172.18.18.255: ICMP echo request, id 41750, seq 887, length 64
 00:34:31.351539 00:0e:0c:33:b8:2a > 00:a9:40:0f:83:a5, ethertype IPv4 (0x0800), length 98: 
 192.168.2.31 > 172.18.18.255: ICMP echo request, id 41750, seq 888, length 64
 
 
 Also notised that turning off net.inet.ip.fastworwarding leads to generation of icmp 
 answers to broadcasts by this host:
 
 # tcpdump -nepi fxp0 net 172.18.18.0/24
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
 00:47:41.440945 00:0e:0c:33:b8:2a > 00:a9:40:0f:83:a5, ethertype IPv4 (0x0800), length 98: 
 192.168.2.31 > 172.18.18.255: ICMP echo request, id 41750, seq 1678, length 64
 00:47:41.440966 00:a9:40:0f:83:a5 > 00:0e:0c:33:b8:2a, ethertype IPv4 (0x0800), length 98: 
 172.18.18.1 > 192.168.2.31: ICMP echo reply, id 41750, seq 1678, length 64
 00:47:42.441021 00:0e:0c:33:b8:2a > 00:a9:40:0f:83:a5, ethertype IPv4 (0x0800), length 98: 
 192.168.2.31 > 172.18.18.255: ICMP echo request, id 41750, seq 1679, length 64
 00:47:42.441041 00:a9:40:0f:83:a5 > 00:0e:0c:33:b8:2a, ethertype IPv4 (0x0800), length 98: 
 172.18.18.1 > 192.168.2.31: ICMP echo reply, id 41750, seq 1679, length 64
 ^C
 4 packets captured
 103 packets received by filter
 0 packets dropped by kernel
 
 # sysctl net.inet.icmp.bmcastecho
 net.inet.icmp.bmcastecho: 0
 
 Local pings does not generate icmp replies until net.inet.icmp.bmcastecho is turned on.
 
 I'm not sure this case still covers current bugreport. AFAIU this is not related to 
 fastforwarding code but to forwarding one.
 
 -- 
 Best regards,
 Dmitry Sergienko

From: Bruce M Simpson <bms@incunabulum.net>
To: Dmitry Sergienko <dmitry@trifle.net>
Cc: freebsd-gnats-submit@FreeBSD.org, 
 Colin Petrie <cpetrie@xcalibre.co.uk>
Subject: Re: kern/98799: [netinet] fastforwarding routes packets to network
 ip address
Date: Mon, 05 Feb 2007 00:09:23 +0000

 Hi Dmitry,
 
 First of all, thank you very much for testing the patch. I'll commit it 
 now though you raise an interesting point.
 
 Dmitry Sergienko wrote:
 > Bruce, I've applied your patch to 6.2-STABLE. Broadcasts are absent 
 > with fastworwarding enabled:
 [..]
 > Also notised that turning off net.inet.ip.fastworwarding leads to 
 > generation of icmp answers to broadcasts by this host:
 [..]
 > I'm not sure this case still covers current bugreport. AFAIU this is 
 > not related to fastforwarding code but to forwarding one.
 >
 I'd hazard a guess, with a quick look at the code, and say, because the 
 bmcastecho check in ip_icmp.c only checks  if the received mbuf has 
 M_BCAST or M_MCAST flags set. These mbuf flags are set on the chain 
 further down in the stack, by if_ethersubr.c.
 
 This is OK for a host, as it will reject incoming ICMP traffic which is 
 on a directly attached local network. However, we could have received an 
 IP datagram with a destination address which is a broadcast address, but 
 has not sent to a broadcast MAC address.
 
 You're right that this is a different problem to the one explained in 
 the PR, though I'm not sure how it would constitute a bug. Can you give 
 me more complete information about the network configuration of the 
 system where you're seeing this problem?
 
 The missing piece of information here is... are you getting replies back 
 from your FreeBSD router, because your FreeBSD router's candidate route 
 to 172.18.18.255 transits a point-to-point interface? *That* may account 
 for your observations.
 
 Explanation:
 In your tcpdump output, the broadcasts appear to be received with the 
 router's MAC address, which is consistent with FreeBSD acting as an 
 intermediate hop for forwarding a directed broadcast.
 
 In RELENG_6, rev 1.301.2.10 of ip_input.c has checks around line 569 to 
 let ip_forward() deal with non-locally-originated directed 
 broadcasts.The behaviour you are seeing is entirely consistent with this 
 code.
 
 FreeBSD will, and should, forward such traffic by default, because the 
 forwarding plane cannot reasonably be expected to have network topology 
 information about broadcast addresses at hops beyond locally-attached 
 networks: unless it is running a proactive routing protocol which sets 
 RTF_BROADCAST appropriately, as per my post on this to -net.
 
 Normally this flag is set by a nested call to arpresolve() further down 
 in the stack. Indeed my patch relies on this behaviour. In the PPP case 
 all bets are off -- because arpresolve() is invoked due to the cloning 
 interface route added for an Ethernet interface, e.g.:
     192.168.123        link#1             UC          0        0   bge0
 
 If I then go ping 192.168.123.255...
     192.168.123.255    ff:ff:ff:ff:ff:ff  UHLWb       1        9   bge0
 Lower case b is RTF_BROADCAST, W is RTF_WASCLONED.
 
 You'd have to do what that hypothetical routing daemon in my example 
 does and add an explicit broadcast route which transits the PPP 
 interface with RTF_BROADCAST set to drop the interface traffic. Or 
 better still, RTF_BLACKHOLE to be explicit about it...
 
 This is a bit of a stab in the dark as I don't have all the information.
 
 Regards,
 BMS
State-Changed-From-To: analyzed->patched 
State-Changed-By: bms 
State-Changed-When: Mon Feb 5 00:15:57 UTC 2007 
State-Changed-Why:  
I just patched this 

http://www.freebsd.org/cgi/query-pr.cgi?pr=98799 

From: Bruce M Simpson <bms@incunabulum.net>
To: Dmitry Sergienko <dmitry@trifle.net>
Cc: freebsd-gnats-submit@FreeBSD.org, 
 Colin Petrie <cpetrie@xcalibre.co.uk>
Subject: Re: kern/98799: [netinet] fastforwarding routes packets to network
 ip address
Date: Mon, 05 Feb 2007 00:11:26 +0000

 Hi,
 
 If the issue with directed broadcasts transiting a FreeBSD router is 
 indeed a separate issue as seems to be the case... Could you open a new 
 PR, so that I may commit the patch for the fastforwarding issue, and 
 track its progress separately!
 
 Thanks!
 BMS

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/98799: commit references a PR
Date: Mon,  5 Feb 2007 00:15:46 +0000 (UTC)

 bms         2007-02-05 00:15:40 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/netinet          ip_fastfwd.c 
   Log:
   When fast-forwarding is enabled, do not forward directed IPv4 broadcasts
   to locally attached broadcast networks.
   
   Note well: This relies on the layer 2 route cloning behaviour in BSD.
   
   PR:             98799
   Tested by:      Dmitry Sergienko
   MFC after:      1 week
   
   Revision  Changes    Path
   1.39      +4 -2      src/sys/netinet/ip_fastfwd.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: bms 
State-Changed-When: Mon Feb 12 12:56:54 UTC 2007 
State-Changed-Why:  
MFC 

http://www.freebsd.org/cgi/query-pr.cgi?pr=98799 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/98799: commit references a PR
Date: Mon, 12 Feb 2007 12:52:57 +0000 (UTC)

 bms         2007-02-12 12:52:54 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/netinet          ip_fastfwd.c 
   Log:
   MFC rev 1.39:
     When fast-forwarding is enabled, do not forward directed IPv4 broadcasts
     to locally attached broadcast networks.
   
     Note well: This relies on the layer 2 route cloning behaviour in BSD.
   
   PR:             98799
   Tested by:      Dmitry Sergienko
   
   Revision  Changes    Path
   1.28.2.5  +4 -2      src/sys/netinet/ip_fastfwd.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
>Unformatted:
