From nobody@FreeBSD.org  Thu Apr 17 05:35:02 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id DE0371065672
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 Apr 2008 05:35:02 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id CABA18FC15
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 Apr 2008 05:35:02 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m3H5YoYX060285
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 Apr 2008 05:34:50 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m3H5YoaB060283;
	Thu, 17 Apr 2008 05:34:50 GMT
	(envelope-from nobody)
Message-Id: <200804170534.m3H5YoaB060283@www.freebsd.org>
Date: Thu, 17 Apr 2008 05:34:50 GMT
From: Eugene <4pr@legis.krsn.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: FreeBSD 7 multucast routing problem
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         122839
>Category:       kern
>Synopsis:       [em] FreeBSD 7 multicast routing problem
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 17 05:40:00 UTC 2008
>Closed-Date:    Sat Apr 10 12:08:52 UTC 2010
>Last-Modified:  Sat Apr 10 12:08:52 UTC 2010
>Originator:     Eugene
>Release:        FreeBSD 7
>Organization:
meridian ltd
>Environment:
FreeBSD central-gw 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Apr 15 21:05:52 KRAST 2008
>Description:
Multicast routing does not working correctly. For example if i'm sending multicast stream into interface em0 with ip 192.168.101.1/24 from a windows machine with ip 192.168.101.2/24, using vlc player as generator of the stream 239.0.2.1, and trying to receive it on the interface em1 with ip 192.168.102.1/24 with other windows machine with ip 192.168.102.2/24 with the same version of vlc, acting as recever for that multicast stream, mrouted, wich builded from the ports (i also tryed pimdd) does not do multicast routing, until i put both interfaces into a promiscious mode. 
First i tryed multicast routing with GENERIC kernel, by loading ip_mroute before interfaces have been configured with /boot/loader.conf (ip_mroute_load="YES"). Then i tryed to load ip_mroute after evrething will loaede with kldload ip_mroute. Both times were no any errors on the console or logs. kldstat showed me, what module was loaded. As resault mrouting still not work.
Than i tryed to rebuild the kernel with option MROUTING in kernel config. Mrotuing still not working. I thought, it may be a bug in the ethernet network driver, so i tryed to work with msk0 msk1 interfaces (that ethernet adapters builded into the motherboard). The resault still the same.
Then mrouted daemon working, on all interfaces appears flag ALLMULTI, i sow than on ifconfig output.
If i connect those two windows machines over a switch (machines even with the same ips) multicast stream appears on the other machine, so the stream itself is correct.
If i start mrouted with debug option -d, without promiscious mode on network adapters, it seems, what mrouted are able to receive only igmp leave messages, then i pressing the stop button on vlc acting as recever: 

19:12:18.835 RECV leave message      from 192.168.102.2   to 224.0.0.2.

With promiscious mode enabled mrouted output is: 

19:13:48.138 RECV V2 member report   from 192.168.102.2   to 239.0.2.1
19:13:48.138 group 239.0.2.1 joined on vif 1
19:13:48.138 update lclgrp (192.168.101/24 239.0.2.1) gm:2
19:13:48.270 RECV V2 member report   from 192.168.102.2   to 239.0.2.1
19:13:52.344 aging forwarding cache entries

There is no any packet filters enabled:

ipfw list
ipfw: getsockopt(IP_FW_GET): Protocol not available

Output ifconfig (with mrouted or pimdd disabled, and no ALLMULTI flag):

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:15:17:6d:3d:be
        inet 192.168.101.1 netmask 0xffffff00 broadcast 192.168.101.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:15:17:6d:3d:45
        inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
msk0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:1e:8c:60:f8:43
        media: Ethernet autoselect (none)
        status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet 127.0.0.1 netmask 0xff000000

>How-To-Repeat:
Just try to start multicast routing.
>Fix:
Quick fix is to enable promiscious mode on the network adapters.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Apr 17 05:45:46 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=122839 
State-Changed-From-To: open->feedback 
State-Changed-By: bms 
State-Changed-When: Thu 17 Apr 2008 08:49:01 UTC 
State-Changed-Why:  
The symptoms you describe do not sound like a multicast routing issue. 
Given your description it sounds like the ethernet drivers are not 
implementing ALLMULTI correctly. 

If the ALLMULTI flag is appearing in the ifconfig output for the 
interfaces involved, that is the correct behaviour. 
The multicast forwarding code *requires* that the card supports ALLMULTI 
correctly. 

However ALLMULTI has historically been known not to work correctly with 
certain network adapters, and in this case it could be a firmware issue. 

For example I saw an issue with fxp last week whereby the card wouldn't 
send multicast traffic unless the group had also been joined, which 
violates POLA. 

Can you ping Pyun YongHyeon and/or Jack Vogel about this? Both have 
been working on the msk and em drivers recently so they can better 
advise you about possible driver problems. Thanks. 



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

From: 4pr@legis.krsn.ru
To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru
Cc:  
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Fri, 18 Apr 2008 15:50:02 +0800

 Thank you very mach for your response!
 
 Yes, as i wrote before, if mrouted daemon, or pimdd daemon is running, 
 then ALLMULTI flag appears on all interfaces (i can see it from ifconfig 
 output). But multicast routing do not work.
 
 I have a machine with an old FreeBSD4.9 running, wich working as a 
 router/multicast router with Intel gigabit desktop pci adapters (em) 
 installed. That old installation do not have any problems with multicast 
 routing role. So for testing i have installed completly equal to that old 
 ones cards to my new installation of FreeBSD7.0 instead of new Intel's 
 pcix server adapters (they also uses driver em) which i tryed to use 
 before. And resault was absolutely the same. Mrouting do not work, until 
 promiscious mode will be enabled (by mtest or tcpdump). So i fink, it is 
 not a firmware bug, as card working correctly with 4.9 release.
 
 I desided to try to use that hardware with FreeBSD 6.3 installed into 
 another hard drive with GENERIC kernel and ip_mroute loaded after boot 
 time. And resault still the same. On 6.3 branch i have same problem. 
 
 Is it possible, what on different drivers like "em" and "msk" existing the 
 same bug, wich cousing them do not work with multicast routing code 
 correctly?
 
 More infromation about problem, if it might help: then on receiveng 
 machine on vlc player (adjasted to receive multicast from 239.0.2.1) i 
 pressing PLAY button, mrouted -d do not show anything about that event. 
 Then i pressing the STOP button i see on debug:
 
 19:13:48.138 RECV V2 member report   from 192.168.102.2   to 239.0.2.1
 
 But, if promiscious mode enabled, then i pressing PLAY button on receiver 
 i see:
 
 19:13:48.138 RECV V2 member report   from 192.168.102.2   to 239.0.2.1
 19:13:48.138 group 239.0.2.1 joined on vif 1
 19:13:48.138 update lclgrp (192.168.101/24 239.0.2.1) gm:2
 19:13:48.270 RECV V2 member report   from 192.168.102.2   to 239.0.2.1
 19:13:52.344 aging forwarding cache entries
 
 and pressin the STOP buttong gives more debug print, then without 
 promiscious mode enabled.
 
 So i'm shure, there was a lot code changing in em driver since 4.9, and 
 somethng might be occasionally broken in the code.
 
 Please, cold you help me with contacting Pyun YongHyeon and/or Jack Vogel? 
 Or where i can find theyr email addresses?
 
 Tommorow i will try another cards, like rtl8139 10/100 or similar for 
 testing.
 
 Thank you again.

From: petunin1@legis.krsn.ru
To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru, bms@FreeBSD.org
Cc:  
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Tue, 22 Apr 2008 22:52:53 +0800

 Hi.
 
 I cold't find any rtl8139 based adapters at me, so i tryed to play with 
 3com 3c905-tx  (rev. A, as printed on the board, with controller chip 
 "Parallel Tasking 3com 40-0336-004 9750s 04749555 LUCENT 40-03364" ) and 
 OFFICE CONNECT 3csoho100-tx (also rev. a with controller chip "Parallel 
 tasking II perfomance 3com 40-0483-004 0111t 42433437 AGERE 40-04834")
 
 The system detected both of them as XL0 and XL1 network devices. And, with 
 first card (3com 3c905-tx) xl0 multicast task routing started working just 
 fine and as expected. But with another card  (soho office connect) 
 multicast routnig still do not working, and problem seems to be exact the 
 same as with em and msk drivers. (mrouting working only in promiscious 
 mode).
 
 I've downloaded latest intel's driver for FreeBSD7 (6.8.7) and tryed to 
 use it, but with no luck. Problem still exist.
 
 So, as it seems to me, it is not a em driver problem. I fink, it is 
 imposiible, what such different drivers, as xl, em and msk were was broken 
 simultaneously and identically.
 
 As my colleague says, when we both take a brief look at the source codes 
 of em driver, it seems some card have a hardware filter, and some do not 
 have it. So, if the card's filter programmed correctly (by the driver), 
 multicast working task working just fine, and if not, we have a problems.
 
 On latest intel's driver 6.8.7 we have commented a few string on the code, 
 after what, multicast routing started to work correctly. But i fink, it's 
 a wrong way, so i asking for help again, if someone can help me to 
 investigate the source of the problem and fix it by the right way.
 
 What we have changed:
 
 central-gw# diff if_em.c.orig if_em.c
 2337c2337
 <       if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) {
 ---
 > //    if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) {
 2341,2343c2341,2343
 <       } else
 <               e1000_update_mc_addr_list(&adapter->hw, mta,
 <                   mcnt, 1, adapter->hw.mac.rar_entry_count);
 ---
 > //    } else
 > //            e1000_update_mc_addr_list(&adapter->hw, mta,
 > //                mcnt, 1, adapter->hw.mac.rar_entry_count);
 
 
 
 in that part of if_em.c file:
 
 /*********************************************************************
  *  Multicast Update
  *
  *  This routine is called whenever multicast address list is updated.
  *
  **********************************************************************/
 
 static void
 em_set_multi(struct adapter *adapter)
 {
         struct ifnet    *ifp = adapter->ifp;
         struct ifmultiaddr *ifma;
         u32 reg_rctl = 0;
         u8  mta[512]; /* Largest MTS is 4096 bits */
         int mcnt = 0;
 
         IOCTL_DEBUGOUT("em_set_multi: begin");
 
         if (adapter->hw.mac.type == e1000_82542 &&
             adapter->hw.revision_id == E1000_REVISION_2) {
                 reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL);
                 if (adapter->hw.bus.pci_cmd_word & CMD_MEM_WRT_INVALIDATE)
                         e1000_pci_clear_mwi(&adapter->hw);
                 reg_rctl |= E1000_RCTL_RST;
                 E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl);
                 msec_delay(5);
         }
 
         IF_ADDR_LOCK(ifp);
         TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
                 if (ifma->ifma_addr->sa_family != AF_LINK)
                         continue;
 
                 if (mcnt == MAX_NUM_MULTICAST_ADDRESSES)
                         break;
 
                 bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr),
                     &mta[mcnt * ETH_ADDR_LEN], ETH_ADDR_LEN);
                 mcnt++;
         }
         IF_ADDR_UNLOCK(ifp);
 
 //      if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) {
                 reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL);
                 reg_rctl |= E1000_RCTL_MPE;
                 E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl);
 //      } else
 //              e1000_update_mc_addr_list(&adapter->hw, mta,
 //                  mcnt, 1, adapter->hw.mac.rar_entry_count);
 
         if (adapter->hw.mac.type == e1000_82542 &&
             adapter->hw.revision_id == E1000_REVISION_2) {
                 reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL);
                 reg_rctl &= ~E1000_RCTL_RST;
                 E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl);
                 msec_delay(5);
                 if (adapter->hw.bus.pci_cmd_word & CMD_MEM_WRT_INVALIDATE)
                         e1000_pci_set_mwi(&adapter->hw);
         }
 }
 
 Thank you

From: "Bruce M. Simpson" <bms@FreeBSD.org>
To: petunin1@legis.krsn.ru
Cc: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Tue, 22 Apr 2008 16:39:01 +0100

 petunin1@legis.krsn.ru wrote:
 > ...
 > So, as it seems to me, it is not a em driver problem. I fink, it is 
 > imposiible, what such different drivers, as xl, em and msk were was broken 
 > simultaneously and identically.
 >   
 
 Without seeing reproducible results, I couldn't comment either way.
 
 > As my colleague says, when we both take a brief look at the source codes 
 > of em driver, it seems some card have a hardware filter, and some do not 
 > have it. So, if the card's filter programmed correctly (by the driver), 
 > multicast working task working just fine, and if not, we have a problems.
 >   
 
 Yes. It's regrettable that not all devices support the IFF_ALLMULTI 
 feature, nor that it is supported correctly and consistently where it is 
 supported.
 
 For example, wi(4) has never supported IFF_ALLMULTI correctly. The 
 network stack has no notion that a card with IFF_MULTICAST capability 
 can't support IFF_ALLMULTI.
 
 The way to fix it is to add support for emulating it using IFF_PROMISC. 
 This was part of the motivation behind the M_PROMISC change to 
 ether_input() last year, which allows the input path to tell if it 
 received frames which it otherwise wouldn't. It was largely added to 
 avoid introducing layer 2 loops with vlan(4) and if_bridge(4).
 
 This use of IFF_PROMISC has to be reference counted however. What would 
 also help in tidying that piece of code up would be to get rid of the 
 special case of carp(4)'s emulated addresses by tying this into a common 
 API.
 
 Unfortunately I don't have free time to actually do this work at the 
 moment, but I am happy to review patches.
 
 > On latest intel's driver 6.8.7 we have commented a few string on the code, 
 > after what, multicast routing started to work correctly. But i fink, it's 
 > a wrong way, so i asking for help again, if someone can help me to 
 > investigate the source of the problem and fix it by the right way.
 >   
 
 Tony Ackerman (tackerman@FreeBSD.org) is still listed as em(4) 
 maintainer according to MAINTAINERS, last I heard Jack Vogel 
 (jfv@FreeBSD.org) was actually involved. The MAINTAINERS file should 
 probably be updated.
 
 It is probably best if you contact Jack about em(4) directly.
 
 Thanks.
 BMS

From: Tomas Svensson <tomas@tutus.se>
To: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru
Cc:  
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Wed, 23 Apr 2008 15:16:56 +0200

 There is an obvious bug in the em driver regarding promiscuous multicast 
 (ALLMULTI), and I believe the following is the correct solution:
 
 Index: if_em.c
 ===================================================================
 RCS file: /usr/local/cvsroot/FreeBSD7/sys/dev/em/if_em.c,v
 retrieving revision 1.1.1.1
 diff -u -r1.1.1.1 if_em.c
 --- if_em.c	3 Mar 2008 13:50:01 -0000	1.1.1.1
 +++ if_em.c	23 Apr 2008 10:43:23 -0000
 @@ -1080,7 +1080,7 @@
   		if (ifp->if_flags & IFF_UP) {
   			if ((ifp->if_drv_flags & IFF_DRV_RUNNING)) {
   				if ((ifp->if_flags ^ adapter->if_flags) &
 -				    IFF_PROMISC) {
 +				    (IFF_PROMISC | IFF_ALLMULTI)) {
   					em_disable_promisc(adapter);
   					em_set_promisc(adapter);
   				}
 
 It fixes the problem for me on FreeBSD 7.0 and FreeBSD 6.2.
 
 Best regards,
 -Tomas

From: 4pr@legis.krsn.ru
To: bug-followup@FreeBSD.org, bms@FreeBSD.org, tomas@tutus.se,
        4pr@legis.krsn.ru
Cc:  
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Wed, 18 Jun 2008 22:47:37 +0800

 --=_mixed 0051374DC725746C_=
 Content-Type: text/plain; charset="US-ASCII"
 
 Hello!
 Thanks for given ideas and your help!
 Using patch suggested by Tomas Svensson we have made our version of it:
 
 --- if_em.c.orig        2007-11-29 06:24:38.000000000 +0700
 +++ if_em.c     2008-04-24 16:49:04.000000000 +0800
 @@ -1080,7 +1080,7 @@
                 if (ifp->if_flags & IFF_UP) {
                         if ((ifp->if_drv_flags & IFF_DRV_RUNNING)) {
                                 if ((ifp->if_flags ^ adapter->if_flags) &
 -                                   IFF_PROMISC) {
 +                                   (IFF_PROMISC | IFF_ALLMULTI)) {
                                         em_disable_promisc(adapter);
                                         em_set_promisc(adapter);
                                 }
 @@ -2379,12 +2379,14 @@
  static void
  em_disable_promisc(struct adapter *adapter)
  {
 +       struct ifnet    *ifp = adapter->ifp;
         uint32_t        reg_rctl;
  
         reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL);
  
         reg_rctl &=  (~E1000_RCTL_UPE);
 -       reg_rctl &=  (~E1000_RCTL_MPE);
 +       if (!(ifp->if_flags & IFF_ALLMULTI))
 +               reg_rctl &=  (~E1000_RCTL_MPE);
         E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl);
  }
  
 Also we have made a patch for if_msk.c :
 
 --- if_msk.c.orig       2007-12-08 19:16:14.000000000 +0700
 +++ if_msk.c    2008-04-24 17:51:02.000000000 +0800
 @@ -558,11 +558,11 @@
  
         bzero(mchash, sizeof(mchash));
         mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL);
 -       mode |= GM_RXCR_UCF_ENA;
         if ((ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) != 0) {
                 if ((ifp->if_flags & IFF_PROMISC) != 0)
                         mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
                 else if ((ifp->if_flags & IFF_ALLMULTI) != 0) {
 +                       mode &= ~(GM_RXCR_MCF_ENA);
                         mchash[0] = 0xffff;
                         mchash[1] = 0xffff;
                 }
 @@ -627,8 +627,12 @@
         mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL);
         if (ifp->if_flags & IFF_PROMISC)
                 mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
 -       else
 +       else {
                 mode |= (GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
 +               // ALLMULTI handling
 +               if (ifp->if_flags & IFF_ALLMULTI)
 +                       mode &= ~(GM_RXCR_MCF_ENA);
 +       }
         GMAC_WRITE_2(sc, sc_if->msk_port, GM_RX_CTRL, mode);
  }
  
 @@ -934,7 +938,7 @@
                 if ((ifp->if_flags & IFF_UP) != 0) {
                         if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) {
                                 if (((ifp->if_flags ^ sc_if->msk_if_flags)
 -                                   & IFF_PROMISC) != 0) {
 +                                   & (IFF_PROMISC | IFF_ALLMULTI)) != 0) 
 {
                                         msk_setpromisc(sc_if);
                                         msk_setmulti(sc_if);
                                 }
 
 Both patches solves for us described problem with multicast routing on 
 FreeBSD7.0
 But, if it is possible, as we are not too good with FreeBSD patching, cold 
 somebody review and do a sanity check for our patches, just in case we 
 have made a serios/simple mistekes? :)
 Thank you 
 
 
 --=_mixed 0051374DC725746C_=
 Content-Type: application/octet-stream; name="if_em.c.diff"
 Content-Disposition: attachment; filename="if_em.c.diff"
 Content-Transfer-Encoding: base64
 
 LS0tIGlmX2VtLmMub3JpZwkyMDA3LTExLTI5IDA2OjI0OjM4LjAwMDAwMDAwMCArMDcwMAorKysg
 aWZfZW0uYwkyMDA4LTA0LTI0IDE2OjQ5OjA0LjAwMDAwMDAwMCArMDgwMApAQCAtMTA4MCw3ICsx
 MDgwLDcgQEAKIAkJaWYgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVApIHsKIAkJCWlmICgoaWZwLT5p
 Zl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpKSB7CiAJCQkJaWYgKChpZnAtPmlmX2ZsYWdz
 IF4gYWRhcHRlci0+aWZfZmxhZ3MpICYKLQkJCQkgICAgSUZGX1BST01JU0MpIHsKKwkJCQkgICAg
 KElGRl9QUk9NSVNDIHwgSUZGX0FMTE1VTFRJKSkgewogCQkJCQllbV9kaXNhYmxlX3Byb21pc2Mo
 YWRhcHRlcik7CiAJCQkJCWVtX3NldF9wcm9taXNjKGFkYXB0ZXIpOwogCQkJCX0KQEAgLTIzNzks
 MTIgKzIzNzksMTQgQEAKIHN0YXRpYyB2b2lkCiBlbV9kaXNhYmxlX3Byb21pc2Moc3RydWN0IGFk
 YXB0ZXIgKmFkYXB0ZXIpCiB7CisJc3RydWN0IGlmbmV0CSppZnAgPSBhZGFwdGVyLT5pZnA7CiAJ
 dWludDMyX3QJcmVnX3JjdGw7CiAKIAlyZWdfcmN0bCA9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVy
 LT5odywgRTEwMDBfUkNUTCk7CiAKIAlyZWdfcmN0bCAmPSAgKH5FMTAwMF9SQ1RMX1VQRSk7Ci0J
 cmVnX3JjdGwgJj0gICh+RTEwMDBfUkNUTF9NUEUpOworCWlmICghKGlmcC0+aWZfZmxhZ3MgJiBJ
 RkZfQUxMTVVMVEkpKQorICAgIAkJcmVnX3JjdGwgJj0gICh+RTEwMDBfUkNUTF9NUEUpOwogCUUx
 MDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1JDVEwsIHJlZ19yY3RsKTsKIH0KIAo=
 
 --=_mixed 0051374DC725746C_=
 Content-Type: application/octet-stream; name="if_msk.c.diff"
 Content-Disposition: attachment; filename="if_msk.c.diff"
 Content-Transfer-Encoding: base64
 
 LS0tIGlmX21zay5jLm9yaWcJMjAwNy0xMi0wOCAxOToxNjoxNC4wMDAwMDAwMDAgKzA3MDAKKysr
 IGlmX21zay5jCTIwMDgtMDQtMjQgMTc6NTE6MDIuMDAwMDAwMDAwICswODAwCkBAIC01NTgsMTEg
 KzU1OCwxMSBAQAogCiAJYnplcm8obWNoYXNoLCBzaXplb2YobWNoYXNoKSk7CiAJbW9kZSA9IEdN
 QUNfUkVBRF8yKHNjLCBzY19pZi0+bXNrX3BvcnQsIEdNX1JYX0NUUkwpOwotCW1vZGUgfD0gR01f
 UlhDUl9VQ0ZfRU5BOwogCWlmICgoaWZwLT5pZl9mbGFncyAmIChJRkZfUFJPTUlTQyB8IElGRl9B
 TExNVUxUSSkpICE9IDApIHsKIAkJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZGX1BST01JU0MpICE9
 IDApCiAJCQltb2RlICY9IH4oR01fUlhDUl9VQ0ZfRU5BIHwgR01fUlhDUl9NQ0ZfRU5BKTsKIAkJ
 ZWxzZSBpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfQUxMTVVMVEkpICE9IDApIHsKKwkJCW1vZGUg
 Jj0gfihHTV9SWENSX01DRl9FTkEpOwogCQkJbWNoYXNoWzBdID0gMHhmZmZmOwogCQkJbWNoYXNo
 WzFdID0gMHhmZmZmOwogCQl9CkBAIC02MjcsOCArNjI3LDEyIEBACiAJbW9kZSA9IEdNQUNfUkVB
 RF8yKHNjLCBzY19pZi0+bXNrX3BvcnQsIEdNX1JYX0NUUkwpOwogCWlmIChpZnAtPmlmX2ZsYWdz
 ICYgSUZGX1BST01JU0MpCiAJCW1vZGUgJj0gfihHTV9SWENSX1VDRl9FTkEgfCBHTV9SWENSX01D
 Rl9FTkEpOwotCWVsc2UKKwllbHNlIHsKIAkJbW9kZSB8PSAoR01fUlhDUl9VQ0ZfRU5BIHwgR01f
 UlhDUl9NQ0ZfRU5BKTsKKwkJLy8gQUxMTVVMVEkgaGFuZGxpbmcKKwkJaWYgKGlmcC0+aWZfZmxh
 Z3MgJiBJRkZfQUxMTVVMVEkpCisJCQltb2RlICY9IH4oR01fUlhDUl9NQ0ZfRU5BKTsKKwl9CiAJ
 R01BQ19XUklURV8yKHNjLCBzY19pZi0+bXNrX3BvcnQsIEdNX1JYX0NUUkwsIG1vZGUpOwogfQog
 CkBAIC05MzQsNyArOTM4LDcgQEAKIAkJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSAhPSAw
 KSB7CiAJCQlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSAhPSAwKSB7
 CiAJCQkJaWYgKCgoaWZwLT5pZl9mbGFncyBeIHNjX2lmLT5tc2tfaWZfZmxhZ3MpCi0JCQkJICAg
 ICYgSUZGX1BST01JU0MpICE9IDApIHsKKwkJCQkgICAgJiAoSUZGX1BST01JU0MgfCBJRkZfQUxM
 TVVMVEkpKSAhPSAwKSB7CiAJCQkJCW1za19zZXRwcm9taXNjKHNjX2lmKTsKIAkJCQkJbXNrX3Nl
 dG11bHRpKHNjX2lmKTsKIAkJCQl9Cg==
 
 --=_mixed 0051374DC725746C_=--

From: Bruce Simpson <bms@incunabulum.net>
To: Eugene <4pr@legis.krsn.ru>, freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Thu, 19 Mar 2009 17:47:38 +0000

 Hi,
 
 Have you managed to chase the em(4) patch upstream?
 
 It would be great if you could let me know so this PR can either be closed,
 or assigned to the em(4) driver maintainer.
 
 thanks,
 BMS

From: 4pr@legis.krsn.ru
To: bug-followup@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org
Cc:  
Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Fri, 20 Mar 2009 12:54:41 +0700

 SGksIA0KDQpBcyBpIHdyb3RlIGJlZm9yZSwgYmFzZWQgb24gdGhlIHBhdGNoLCBzdWdnZXN0ZWQg
 YnkgVG9tYXMgU3ZlbnNzb24sIHdlIA0KaGF2ZSBtYWRlIG91ciB2ZXJzaW9uIG9mIHRoYXQgcGF0
 Y2guIEFuZCBhYm91dA0KYSB5ZWFyIGFscmVhZHkgd2UgdXNpbmcgaXQgb24gYSBwcm9kdWN0aW9u
 IGluc2lkZSBjb3JlIHJvdXRlciB3aXRob3V0IGFueSANCnByb2JsZW1zLiBBbHNvIHdlIHBhdGNo
 ZWQgIGlmX21zay5jLCBhbmQgaXQgYWxzbw0Kd29ya2luZyBqdXN0IGZpbmUgc2FtZSBhbW91bnQg
 b2YgdGltZSBvbiB0aGUgc2FtZSByb3V0ZXIuIEJvdGggb3VyIHBhdGNoZXMgDQpmb3IgaWZfZW0u
 YyBhbmQgaWZfbXNrLmMgaSBoYXZlIHBvc3RlZCB0byB0aGUgbGlzdC4NClNvIGkgZGlkIG5vdCBj
 aGFzZWQgdGhlIGVtIG9yIG1zayBwYXRjaCB1cHN0cmVhbS4NCg0KVGhhbmtzLCANCkV1Z2VuZSBI
 LiBCcmV6aW4NCg0KDQoNCg0KDQpCcnVjZSBTaW1wc29uIDxibXNAaW5jdW5hYnVsdW0ubmV0Pg0K
 MjAuMDMuMjAwOSAwMDo0Nw0KIA0KICAgICAgICDrz83VOiAgIEV1Z2VuZSA8NHByQGxlZ2lzLmty
 c24ucnU+LCANCmZyZWVic2QtZ25hdHMtc3VibWl0QGZyZWVic2Qub3JnDQogICAgICAgIOvP0MnR
 OiANCiAgICAgICAg9MXNwTogICBSZToga2Vybi8xMjI4Mzk6IFttdWx0aWNhc3RdIEZyZWVCU0Qg
 NyBtdWx0aWNhc3Qgcm91dGluZyANCnByb2JsZW0NCg0KDQpIaSwNCg0KSGF2ZSB5b3UgbWFuYWdl
 ZCB0byBjaGFzZSB0aGUgZW0oNCkgcGF0Y2ggdXBzdHJlYW0/DQoNCkl0IHdvdWxkIGJlIGdyZWF0
 IGlmIHlvdSBjb3VsZCBsZXQgbWUga25vdyBzbyB0aGlzIFBSIGNhbiBlaXRoZXIgYmUgDQpjbG9z
 ZWQsDQpvciBhc3NpZ25lZCB0byB0aGUgZW0oNCkgZHJpdmVyIG1haW50YWluZXIuDQoNCnRoYW5r
 cywNCkJNUw0KDQoNCg==

From: 4pr@legis.krsn.ru
To: bug-followup@FreeBSD.org, bms@FreeBSD.org, freebsd-net@FreeBSD.org
Cc:  
Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Fri, 20 Mar 2009 17:56:11 +0700

 Hi, 
 
 As i wrote before, based on the patch, suggested by Tomas Svensson, we 
 have made our version of that patch. And about
 a year already we using it on a production inside core router without any 
 problems. Also we patched  if_msk.c, and it also
 working just fine same amount of time on the same router. Both our patches 
 for if_em.c and if_msk.c i have posted to the list.
 So i did not chased the em or msk patch upstream.
 
 Thanks, 
 Eugene H. Brezin

From: Pyun YongHyeon <pyunyh@gmail.com>
To: 4pr@legis.krsn.ru
Cc: bug-followup@freebsd.org, bms@freebsd.org, freebsd-net@freebsd.org,
	jfv@FreeBSD.org
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Fri, 20 Mar 2009 20:39:54 +0900

 --7JfCtLOvnd9MIVvH
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Fri, Mar 20, 2009 at 05:56:11PM +0700, 4pr@legis.krsn.ru wrote:
 > Hi, 
 > 
 > As i wrote before, based on the patch, suggested by Tomas Svensson, we 
 > have made our version of that patch. And about
 > a year already we using it on a production inside core router without any 
 > problems. Also we patched  if_msk.c, and it also
 > working just fine same amount of time on the same router. Both our patches 
 > for if_em.c and if_msk.c i have posted to the list.
 > So i did not chased the em or msk patch upstream.
 > 
 Would you try attached msk(4) patch?
 I think em(4) patch you posted looks right. Jack may handle
 this(CCed).
 
 --7JfCtLOvnd9MIVvH
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="msk.allmulti.patch"
 
 Index: sys/dev/msk/if_msk.c
 ===================================================================
 --- sys/dev/msk/if_msk.c	(revision 190121)
 +++ sys/dev/msk/if_msk.c	(working copy)
 @@ -287,9 +287,8 @@
  static void msk_miibus_statchg(device_t);
  static void msk_link_task(void *, int);
  
 -static void msk_setmulti(struct msk_if_softc *);
 +static void msk_rxfilter(struct msk_if_softc *);
  static void msk_setvlan(struct msk_if_softc *, struct ifnet *);
 -static void msk_setpromisc(struct msk_if_softc *);
  
  static void msk_stats_clear(struct msk_if_softc *);
  static void msk_stats_update(struct msk_if_softc *);
 @@ -560,7 +559,7 @@
  }
  
  static void
 -msk_setmulti(struct msk_if_softc *sc_if)
 +msk_rxfilter(struct msk_if_softc *sc_if)
  {
  	struct msk_softc *sc;
  	struct ifnet *ifp;
 @@ -577,15 +576,14 @@
  
  	bzero(mchash, sizeof(mchash));
  	mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL);
 -	mode |= GM_RXCR_UCF_ENA;
 -	if ((ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) != 0) {
 -		if ((ifp->if_flags & IFF_PROMISC) != 0)
 -			mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
 -		else if ((ifp->if_flags & IFF_ALLMULTI) != 0) {
 -			mchash[0] = 0xffff;
 -			mchash[1] = 0xffff;
 -		}
 +	if ((ifp->if_flags & IFF_PROMISC) != 0)
 +		mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
 +	else if ((ifp->if_flags & IFF_ALLMULTI) != 0) {
 +		mode |= GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA;
 +		mchash[0] = 0xffff;
 +		mchash[1] = 0xffff;
  	} else {
 +		mode |= GM_RXCR_UCF_ENA;
  		IF_ADDR_LOCK(ifp);
  		TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
  			if (ifma->ifma_addr->sa_family != AF_LINK)
 @@ -598,7 +596,8 @@
  			mchash[crc >> 5] |= 1 << (crc & 0x1f);
  		}
  		IF_ADDR_UNLOCK(ifp);
 -		mode |= GM_RXCR_MCF_ENA;
 +		if (mchash[0] != 0 || mchash[1] != 0)
 +			mode |= GM_RXCR_MCF_ENA;
  	}
  
  	GMAC_WRITE_2(sc, sc_if->msk_port, GM_MC_ADDR_H1,
 @@ -631,26 +630,6 @@
  	}
  }
  
 -static void
 -msk_setpromisc(struct msk_if_softc *sc_if)
 -{
 -	struct msk_softc *sc;
 -	struct ifnet *ifp;
 -	uint16_t mode;
 -
 -	MSK_IF_LOCK_ASSERT(sc_if);
 -
 -	sc = sc_if->msk_softc;
 -	ifp = sc_if->msk_ifp;
 -
 -	mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL);
 -	if (ifp->if_flags & IFF_PROMISC)
 -		mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
 -	else
 -		mode |= (GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA);
 -	GMAC_WRITE_2(sc, sc_if->msk_port, GM_RX_CTRL, mode);
 -}
 -
  static int
  msk_init_rx_ring(struct msk_if_softc *sc_if)
  {
 @@ -954,10 +933,8 @@
  		if ((ifp->if_flags & IFF_UP) != 0) {
  			if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) {
  				if (((ifp->if_flags ^ sc_if->msk_if_flags)
 -				    & IFF_PROMISC) != 0) {
 -					msk_setpromisc(sc_if);
 -					msk_setmulti(sc_if);
 -				}
 +				    & (IFF_PROMISC | IFF_ALLMULTI)) != 0)
 +					msk_rxfilter(sc_if);
  			} else {
  				if (sc_if->msk_detach == 0)
  					msk_init_locked(sc_if);
 @@ -973,7 +950,7 @@
  	case SIOCDELMULTI:
  		MSK_IF_LOCK(sc_if);
  		if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0)
 -			msk_setmulti(sc_if);
 +			msk_rxfilter(sc_if);
  		MSK_IF_UNLOCK(sc_if);
  		break;
  	case SIOCGIFMEDIA:
 @@ -3594,12 +3571,9 @@
  	CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, RX_GMF_CTRL_T),
  	    GMF_OPER_ON | GMF_RX_F_FL_ON);
  
 -	/* Set promiscuous mode. */
 -	msk_setpromisc(sc_if);
 +	/* Set receive filter. */
 +	msk_rxfilter(sc_if);
  
 -	/* Set multicast filter. */
 -	msk_setmulti(sc_if);
 -
  	/* Flush Rx MAC FIFO on any flow control or error. */
  	CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, RX_GMF_FL_MSK),
  	    GMR_FS_ANY_ERR);
 
 --7JfCtLOvnd9MIVvH--

From: 4pr@legis.krsn.ru
To: pyunyh@gmail.com
Cc: bug-followup@freebsd.org, bms@freebsd.org, freebsd-net@freebsd.org,
        jfv@freebsd.org
Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Fri, 20 Mar 2009 19:19:15 +0700

 Hi,
 
 Thank you for your response.
 Sorry, but i'm unable to test your patch for if_msk.c wich you suggested, 
 becouse our production core router need to be up and ready 24 hours a day, 
 and our quick fix for if_msk.c also helped us with multicast routing 
 problem. Right now i don't have the other hardware to simulate our network 
 condition for testings too.
 
 Thank you,
 
 Eugene H. Brezin
State-Changed-From-To: feedback->closed 
State-Changed-By: bms 
State-Changed-When: Sat 10 Apr 2010 12:07:35 UTC 
State-Changed-Why:  
Timeout on feedback. I believe yongari has merged driver fixes where 
relevant to this issue. 


Responsible-Changed-From-To: freebsd-net->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Sat 10 Apr 2010 12:07:35 UTC 
Responsible-Changed-Why:  
take this 

http://www.freebsd.org/cgi/query-pr.cgi?pr=122839 
>Unformatted:
