Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem

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

From: petunin1@xxxxxxxxxxxxx
To: bug-followup@xxxxxxxxxxx, 4pr@xxxxxxxxxxxxx, bms@xxxxxxxxxxx
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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: 3Com 3c501 parameters?
    ... This is a device driver for the 3Com Etherlink 3c501. ... Do not purchase this card, ... * multicasting in a real multicast environment. ...
    (comp.os.linux.networking)
  • Re: Strange networking problems after update 5.2.1->5.3
    ... looking for destination multicast frames. ... A more likely problem is that ARP packets ... generated by your system have the MAC address seen by the driver ... It's not clear whether the MAC address reported by ifconfig is actually ...
    (freebsd-stable)
  • fxp(4) multicast transmission bug.
    ... If I try to inject multicast traffic via bpf with fxp, bpf will report that it went out OK, however it never makes it out onto the wire. ... driver flags look like this when injection is NOT OK: ... I see from reading the driver that the fxp chip has certain restrictions on how the hash filter is programmed -- the command to do so must come before any other descriptors are queued. ...
    (freebsd-net)
  • [9fans] new realtek ether81[39].c drivers
    ... I've just pushed out new realtek drivers that use the controllers' ... built-in multicast filters when multicast is enabled, ... enabling promiscuous mode. ... I haven't tested the new 8139 driver, ...
    (comp.os.plan9)
  • RE: novell through freebsd firewall
    ... Is it possible to run nat and multicast on FreeBSD successfully? ... packets are sent towards the Novell servers. ...
    (freebsd-net)