This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 14:06:39 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8IIxaX06805 for ; Wed, 18 Sep 2002 20:59:36 +0200 Received: (qmail 23142 invoked from network); 18 Sep 2002 07:24:45 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 18 Sep 2002 07:24:45 -0000 Received: (qmail 4701 invoked by uid 1000); 17 Sep 2002 21:09:14 -0000 Received: (maildatabase); juh Received: (qmail 3439 invoked by alias); 15 Jan 2002 06:30:14 -0000 Received: (qmail 2132 invoked from network); 15 Jan 2002 06:28:57 -0000 Received: from unknown (HELO dipsaus.ds9a.tudelft.nl) (::ffff:10.0.0.202) by spaans.ds9a.nl with SMTP; 15 Jan 2002 06:28:57 -0000 Received: (qmail 27593 invoked from network); 15 Jan 2002 00:19:34 -0000 Received: from unknown (HELO vger.kernel.org) (::ffff:12.107.208.194) by adsl-xs4all.ds9a.nl with SMTP; 15 Jan 2002 00:19:34 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 19:16:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 19:16:06 -0500 Received: from adsl-63-192-223-74.dsl.snfc21.pacbell.net ([63.192.223.74]:32832 "EHLO gateway.berkeley.innomedia.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 19:15:55 -0500 Received: from berkeley.innomedia.com (IDENT:root@berkeley.innomedia.com [192.168.1.5]) by gateway.berkeley.innomedia.com (8.9.1/8.9.1) with ESMTP id QAA27631; Mon, 14 Jan 2002 16:16:51 -0800 Received: from berkeley.innomedia.com (IDENT:cjames@pc20.berkeley.innomedia.com [192.168.1.20]) by berkeley.innomedia.com (8.11.0/8.9.3) with ESMTP id g0F0FAt07207; Mon, 14 Jan 2002 16:15:10 -0800 Message-Id: <3C4374BA.F8E26684@berkeley.innomedia.com> Date: Mon, 14 Jan 2002 16:15:54 -0800 From: Christopher James X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test1-rtl i686) X-Accept-Language: en Mime-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: linux-kernel@vger.kernel.org, Christopher James Subject: Re: Multicast fails when interface changed References: <200201142016.XAA10180@ms2.inr.ac.ru> Content-Type: text/plain; charset=iso-8859-1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Spam-Status: No, hits=0 required=5 tests= Lines: 43 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by kylie.puddingonline.com id g8IIxaX06805 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > the app (vocal 1.2) does not use INADDR_ANY for imr_interface when > > joining the multicast group > > Hmm... and what does it use? > > As soon as /proc/net/dev_mcast does not show membership on the second > interface, it is not difficult to conclude that the applciation just forgot to > request mmembership on it. > > Alexey When joining the multicast group, imr_interface is set to the hostname IP address, in this case 192.168.25.113. This was verified by by looking at the Vocal code, and by putting printfs in Vocal code to print out imr_interface when joining the multicast group. More background on app and problem: We are developing a high availability solution where the application can run on one of two redundant networks. The application uses either eth1 (connected to network1) or eth2 (connected to network2). Only one interface is up at a time. When the application comes up, it uses eth1. Another process (other than the application) monitors the health of network1. If network1 goes down, then the monitoring process uses ifconfig to take down eth1, and ifconfig to bring up eth2 (using the same configuration information as used for eth1). This switch is completely transparent to the application: the application does not know about the switch or do anything to make the switch; the app does not set multicast membership on the new interface. It was our expectation that the switch from the first to second interface should work without any involvement from the application because the second interface is configured exactly the same as the first interface. After the switch, everything seems to work with the exception of multicasting: the multicast membership information is not propagated to the second interface, it stays with the first interface. Christopher (I'm not on list so please CC with answers/comments) :.˛mkabzwmb˛mbz_^nrzh&zzޗ++zfh~iz_j:+v)ߣmSy杶ii