Re: UDP multicast packets not seen on listening interface in BETA5

From: Bill Paul (wpaul_at_FreeBSD.ORG)
Date: 09/30/05

  • Next message: Josh Carroll: "Re: UDP multicast packets not seen on listening interface in BETA5" 
    To: josh.carroll@psualum.com
Date: Thu, 29 Sep 2005 22:14:37 +0000 (GMT)

    > All,
    >
    > I'm having a bit of trouble with a program I wrote to listen for
    > multicast packets from my DSL modem in order to monitor/collect line
    > stats. It has worked previously in 5.4 and 6.0-BETA3. The source is
    > availabe here for anyone that wants to poke around in it:
    >
    > http://wdiag.sourceforge.net
    >
    > Anyway, recently I rebuilt world and the kernel from BETA5 sources
    > (previously on BETA3 or thereabouts). The application no longer finds
    > the multicast packets, but works fine in BETA3.
    >
    > Let me briefly describe what the program does. It simply bind()'s to
    > port 1875/udp (INADDR_ANY), joins the proper multicast group, calls
    > select() then recvfrom() to look for the packet. It waits for a
    > timeout period, then fails if it doesn't see the packet in that time
    > period, which is what is happening in BETA5.
    >
    > I ran tcpdump and I do see the packets hitting the interface:
    >
    > 09:00:45.394614 IP 192.168.1.254.1875 > 224.73.193.62.1875: UDP, length 120
    >
    > I suspect maybe I am not properly joining the multicast group, so it's
    > ignoring the packet. But like I said, this worked in BETA3 which is
    > why I'm stumped.
    >
    > nc -v -u -l 1875
    >
    > Doesn't see any packets either, for what it's worth, though I don't
    > know off hand whether nc can do multicast or not.
    >
    > Also I verified the program is indeed listening with sockstat:
    > root westell 2194 3 udp4 *:1875 *:*
    >
    > Any ideas where I can begin to troubleshoot this?

    Well no, because you left out one vital piece of information, which is
    what kind of network adapter are you using?

    Yes, it matters.

    Yes, you should feel silly for not thinking it was important enough to
    mention. It's _ALWAYS_ important enough to mention. No, you aren't
    allowed to play the "but I just wanted to see if this sounded familiar
    to someone" game.

    Running tcpdump, unless you use the -p flag, will put the NIC into
    promiscuous mode. This means you'll pick up all multicast frames
    (and everything else) regardless of how the NIC's multicast filter is
    programmed.

    Just joining a group will not put the interface into promiscuous mode:
    it'll just program the NIC's multicast filter to accept that particular
    group. That is of course unless someone a) broke the driver for your
    NIC or b) broke SIOCADDMULTI support somewhere in the stack. Until you
    tell us what NIC you have, there's no easy way to tell which is the
    case.

    -Bill 

    --
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul@windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Josh Carroll: "Re: UDP multicast packets not seen on listening interface in BETA5"

    Relevant Pages

    • Packet reordering and blocking problem at gigabit with 2.4 kernel
      ... I am developing application level multicast router with Xeon processor. ... The system lost lots of packets and reordered the packets, ... Every channel sends 6Mbps with 2048 bytes packet. ... I heard that SMP machines has inherant reordering issues, ...
      (Linux-Kernel)
    • UDP multicast packets not seen on listening interface in BETA5
      ... I'm having a bit of trouble with a program I wrote to listen for ... the multicast packets, ... Also I verified the program is indeed listening with sockstat: ...
      (freebsd-current)
    • Re: Spoofing multicast addresses
      ... }>> connections and it wasteful to do unnecessary checking on these packets. ... reducing the overhead of multicast packets wouldn't make ... doing the PCB lookup before the source address check, then the attacker ... able to keep things in the non-optimal state by varying the packet stream. ...
      (FreeBSD-Security)
    • Re: Multiple multicast apps
      ... Looks like an error in the multicast filter setup for your network ... Rather than having to take all multicast packets off the ... It's a bug and I would assume it has been fixed later in the 4.x ...
      (comp.unix.bsd.freebsd.misc)
    • Re: Spoofing multicast addresses
      ... > connections and it wasteful to do unnecessary checking on these packets. ... But that is exactly NOT the case when being attacked with a SYN flood ... You certainly don't NEED to do a PCB lookup for a TCP packet with a ... multicast source addresses. ...
      (FreeBSD-Security)