Date: Wed, 5 Apr 95 13:11:48 JST From: Masahiro SEKIGUCHI <seki@sysrap.cs.fujitsu.co.jp> To: Bill Fenner <fenner@parc.xerox.com> Cc: hackers@FreeBSD.org Subject: IGMP bug Message-ID: <9504050411.AA02781@seki.sysrap.cs.fujitsu.co.jp> References: <9504040118.AA00039@seki.sysrap.cs.fujitsu.co.jp> <95Apr4.153027pdt.49864@crevenia.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504050411.AA02781>