Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
Hi! Yes, I have PF enabled with some NAT rules present in the rule set. However disabling PF (even by commenting out 'pf_enable' in the /etc/rc.conf and rebooting the machine) does not make any difference. The problem persist regardless of whether NAT is enabled or not (or even whether pf.ko is loaded or not). Best regards, Andriy. 2010/12/15 serg vasilyev > 2009/12/9, Andriy Syrovenko : > > Hi, > > > > Well, turning off the transmit checksum offloading on the upstream > > interface solves the problem with IP checksums of IGMP report and > > leave messages always being 0. So after issuing the > > > > ifconfig re1 -txcsum > > > > command, the proxy successfully subscribes to receiving multicast > > streams, and I can see multicast UDP traffic coming in on the upstream > > interface. However there is another serious problem. Shortly alfter my > > router starts forwarding multicast traffic kernel crashes. The crash > > may happen either immediately when I press the play button in my IPTV > > player, or just after several channel switches. You can find crash > > reports in the attached files. They are almost identical, differing > > only in whether the pf module is loaded. > > > > > > The interesting part of the story is if I block incoming UDP multicast > > traffic using something like > > > > block in quick inet proto udp from any to 224.0.0.0/4 > > > > in my pf.conf, system remains stable. But as soon as I comment the > > rule and reload pf, kernel crashes. I suspect the problem is not > > strictly related to the igmp processing, but to the multicast routing > > in general. Probably something wrong with thread synchronization. My > > system is a dual-core Intel Atom. > > > > Another interesting observation is when my BSD box is disconnected > > from the upstream router, I can see only IGMPv3 messages going out the > > upstream interface, even despite the fact that igmpproxy supports > > IGMPv2 only. > > > > br, > > Andrey > > > Does your system do any nat processing ? > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
The following reply was made to PR kern/138666; it has been noted by GNATS. From: Andriy Syrovenko To: bug-follo...@freebsd.org, univers...@ukr.net Cc: Subject: Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy Date: Mon, 7 Dec 2009 11:56:11 +0200 I'd like to confirm the problem exists and I can reproduce it easily. The stack trace is completely identical to the initially submitted one. Tested with igmpproxy from ports (0.1 beta2) as well as with the fresh version from sourceforge, with absolutely the same result. Steps required to reproduce: 1. Start igmpproxy 2. Send igmp report query (probably this step is optional) 3. Wait for several minutes for the kernel crash to occur I'd love to help in investigating and debugging the issue if someone points me in the right direction. My system is: FreeBSD venus 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #0: Fri Dec=A0 4 10:03:09 EET 2009=A0=A0=A0=A0 r...@mybsd:/usr/obj/usr/src/sys/ROUTER=A0 amd= 64 Kernel configuration is: include=A0=A0=A0=A0=A0=A0=A0=A0 GENERIC ident=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ROUTER options=A0=A0=A0=A0=A0=A0=A0=A0 DEVICE_POLLING options=A0=A0=A0=A0=A0=A0=A0=A0 HZ=3D1000 options=A0=A0=A0=A0=A0=A0=A0=A0 ALTQ options=A0=A0=A0=A0=A0=A0=A0=A0 ALTQ_CBQ options=A0=A0=A0=A0=A0=A0=A0=A0 ALTQ_RED options=A0=A0=A0=A0=A0=A0=A0=A0 ALTQ_RIO options=A0=A0=A0=A0=A0=A0=A0=A0 ALTQ_HFSC options=A0=A0=A0=A0=A0=A0=A0=A0 ALTQ_PRIQ options=A0=A0=A0=A0=A0=A0=A0=A0 MROUTING ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
Is it planned to be MFCed to STABLE? Or, could you possibly point me into the right revision in HEAD, so I could merge and test it locally? 2009/12/7 Bruce Simpson : > I believe this *may* have been fixed in HEAD, but was one of the things > which couldn't be MFCed due to the RC freeze... > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
I have switched to 8-STABLE. Kernel does not seem to crash anymore, however IGMP still does not work. tcpdump complains that outgoing IGMP report and leave packets have incorrect checksum- it is always 0. Though I'm not sure weather it is IGMP checksum or IP checksum that is incorrect. 2009/12/7 Bruce Simpson : > Andriy Syrovenko wrote: >> >> Is it planned to be MFCed to STABLE? >> Or, could you possibly point me into the right revision in HEAD, so I >> could merge and test it locally? >> > > Actually I did already MFC most of my changes to stable/8, just not > releng/8.0. > > There were a few things to do with IGMP packet checks which I rolled in to > my last swathe of changes. If this is a purely IGMP related problem, those > fixes should be enough to get going. > > On the other hand, you could try backing out the last few revs on > ip_mroute.c where I've tried to clean up some of the legacy code and get it > into modernity. > > I didn't turn up any problems with that code in my most recent testing (last > March, when I committed them), but my testing was limited to my own LAN. > > The backtrace in the PR suggested a problem around m_freem(), this could be > a problem with another call which uses the mbuf. > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
2009/12/8 Bruce Simpson : > Andriy Syrovenko wrote: >> >> I have switched to 8-STABLE. Kernel does not seem to crash anymore, >> however IGMP still does not work. tcpdump complains that outgoing IGMP >> report and leave packets have incorrect checksum- it is always 0. >> Though I'm not sure weather it is IGMP checksum or IP checksum that is >> incorrect. >> > > This just sounds like a fairly normal artefact of tcpdump/bpf with checksum > offload, as I get the exactly same thing on my desktop w/ re(4). > > You need to confirm the checksums at the wire to be sure, or disable > rxcsum/txcsum: > # ifconfig re0 -txcsum -rxcsum I've checked w/ tcpdump on my MacBook connected to the same LAN segment the upstream interface of my router is connected to. The packets on the wire have bad checksums. And yes, I have re(4) interfaces as well. I'll try turning off checksum offloading today evening, as soon as I get to my router. > Nothing has changed in the behaviour of the code which computes IGMP > checksums; it does not depend on the outer IP header, and isn't touched by > IP checksum offload, unless your network card (or its driver) is doing > something it shouldn't be doing. I have looked through the tcpdump source code, and am now fairly confident that it is IP (not IGMP) checksum that is broken. > Perhaps Florian can shed some light on your IGMP issue? igmpproxy only > understands IGMPv2, afaik. Yep, it is igmp v2 only indeed. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy
2009/12/8 Bruce Simpson : > The only other thing I can think of is: is this an igmpproxy issue, ie. is > the IGMP traffic which is causing problems, coming from igmpproxy itself? That's possible. > The kernel never generates IGMP control traffic related to routing. Any IGMP > traffic generated by userland, generally uses the raw socket interface. I don't yet understand all the mechanics behind the multicast routing. And igmpproxy does seem to use raw sockets to send igmp packets. However when I tried to do some investigations yesterday evening, I added a couple of printf()s to igmp_v1v2_queue_report() in sys/netinet/igmp.c, and I saw their output in dmesg while switching multicast groups. > Userland could potentially also use pcap to inject directly to the link > layer, and indeed, that might be a more desirable situation where the daemon > is intended to run on interfaces w/o an IPv4 address. Of course, this > entirely bypasses the host IP stack. This does not seem to be the case with the igmpproxy. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
