From owner-freebsd-hackers Tue Apr 4 21:17:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02215 for hackers-outgoing; Tue, 4 Apr 1995 21:17:14 -0700 Received: from fgwmail.fujitsu.co.jp (fgwmail.fujitsu.co.jp [164.71.1.133]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA02209 for ; Tue, 4 Apr 1995 21:17:11 -0700 Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.6.9+2.4W/3.3W5-MX941209-Fujitsu Mail Gateway) id NAA13550; Wed, 5 Apr 1995 13:16:42 +0900 Received: from fdm.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.9+2.4W/3.3W5-MX950127-Fujitsu Domain Mail Master) id NAA25653; Wed, 5 Apr 1995 13:16:40 +0900 Received: from sysrap by fdm.fujitsu.co.jp (5.65/6.4J.6) id AA00792; Wed, 5 Apr 95 13:16:39 +0900 Received: from seki.sysrap.cs.fujitsu.co.jp by spad.sysrap.cs.fujitsu.co.jp with smtp (Smail3.1.28.1 #1) id m0rwMcz-000AKlC; Wed, 5 Apr 95 13:23 JST Date: Wed, 5 Apr 95 13:11:48 JST From: Masahiro SEKIGUCHI Message-Id: <9504050411.AA02781@seki.sysrap.cs.fujitsu.co.jp> To: Bill Fenner Cc: hackers@FreeBSD.org Subject: IGMP bug References: <9504040118.AA00039@seki.sysrap.cs.fujitsu.co.jp> <95Apr4.153027pdt.49864@crevenia.parc.xerox.com> Sender: hackers-owner@FreeBSD.org Precedence: bulk >Could you tell me more about this "too-fast" bug? Shortly, it is "new IGMP requires 2 bytes for igmp_code field, but it has just 1 byte." This is a bug in a protocol design, not just coding issue. >> timer = ntohs(igmp->igmp_code); > >Interestingly enough, igmp_code is a u_char. I suppose that byte-swapping >a char doesn't make a whole lot of sense =) Absolutely. A main part of mrouted (vif.c) passes a two byte value (an integral value larger than 255) as an expected timeout of membership query command to the packet building subroutine. (Sorry, I forgot the name. igmp_send() or something.) The subroutine just puts the value to igmp_code. (No htons() here. I don't know why.) So, the timeout value in an IGMP packet becomes a lower 8 bit of the required value. Shorter than the true timeout. On receiver side, igmp_input extract a byte value (igmp_code) and pass it to ntohs(). On big endian machines such as SparcStation, which is the "reference" machine of the multicast packages, ntohs() is a nop. So, igmp wait timer expires too fast. (Remember this value was a lower 8 bit of the true value.) On little endian machines such as "our" Intel chips, ntohs() swaps upper and lower bytes. In our particular case, it makes the value 256 times as large as what was in the packet. This value may larger or smaller than the original value (before truncation by mrouted) dpending on the bit-pattern of the value. In mrouted 3.3, it was toooo large. >The 3.5 multicast release will contain lots of IGMP fixes (plus a lot of >other kernel fixes/changes), When I found the bug, I asked a local mbone guru whether it is well known. He didn't know the particular bug, but he told me 3.5 would be release soon and 3.3 bug report at that time has less valuable. I received the announcement of multicast 3.5 from him. It just says, "IGMP handling is fixed; it is strongly recommended to replace all 3.3 codes with 3.5 codes." I had a feeling that this modest sentence referes to the "brain-damaged" design of so-called "new IGMP". :-) >I hope to have it ported to FreeBSD soon. YES! >Any volunteers to do testing? I will. Does the test start before 2.1 release?