Linux multicast IP en dynamische IP adressen

[Exirion]

Ik implementeer een distributed protocol dat met IP multicast werkt. De servers op de verschillende hosts zijn aanspreekbaar via een 224.x.x.x multicast adres. Elke host kan via dat multicast adres ook zichzelf bereiken.

Het protocol moet gebruikt worden in een dynamische omgeving waarin IP adressen niet statisch zijn. In een testje zijn er twee devices waarvan device A een server draait. Zodra A de server draait kan device B een ping doen naar het 224.x.x.x adres.

Het probleem is nu dat een wijziging van het IP adres van A leidt tot problemen bij device A zelf. Na de wijziging van het adres kan device B nogsteeds succesvol pingen naar A, en krijgt dan een reply terug van het nieuwe adres van A. Tevens kan B succesvol een request sturen naar het multicast kanaal en het krijgt dan een nogsteeds een reply van A (met het nieuwe adres). Echter, op device A zelf is het multicast kanaal lokaal helemaal dood. Pingen geeft meldingen als "Network is unreachable" en bovendien is het herstarten van de server niet mogelijk omdat het openen van een nieuwe multicast socket mislukt (ook al is SO_REUSEADDR gebruikt).

Kort gezegd: als A z'n IP adres verandert dan kan A zichzelf niet meer bereiken, maar andere devices kunnen A nog wel bereiken en vice versa. Ik denk aan een routeringsprobleem op de localhost, maar je zou verwachten dat die routering in de kernel gecorrigeerd wordt zodra A z'n adres (via ifconfig of wat dan ook) op een bepaalde adapter aanpast. Naar buiten toe gaat het immers nogsteeds helemaal goed met z'n nieuwe IP adres.

Heeft iemand hier een verklaring voor? De enige oplossing die ik nu zie is om op linklayer niveau raw ethernet packets af te tappen en dan de voor ons bestemde multicastpakketten er zelf uit te pikken. Dat is echter niet zo elegant, en bovendien zou alles op IP niveau gewoon moeten werken. Is dit een bug op zie ik iets over het hoofd?

[ACM]

Je kan nog bekijken wat de output van `route` is voor en na de wijziging van het adres.
Wat ik vreemder vind is dat device B dus nog steeds de multicast-tree kan pingen en ook netjes een reply van A (en B ) terugkrijgt
Terwijl A zelf niet meer weet waar dat adres is

Maar volgens mij worden de route-tabellen niet zomaar opnieuw opgezet, dat zal denk ik pas gebeuren bij een herstart van de netwerkdevice. (waar je ook die socket mee vrij geeft denk ik?)

Btw, ik weet eigenlijk niet waar je beter antwoord kan krijgen, hier of in NOS? Wil je het hier laten staan, of liever in NOS hebben?

[ Voor 14% gewijzigd door ACM op 06-12-2002 11:44 ]

[D2k]

hoe verandert A zijn IP?
volgens mij neemt ie dat pas over na een herstart van de netwerk daemon?


.edit: venster niet te lang laten openstaan

[ Voor 21% gewijzigd door D2k op 06-12-2002 11:45 ]

[Exirion]

ACM schreef op 06 December 2002 @ 11:42:
Je kan nog bekijken wat de output van `route` is voor en na de wijziging van het adres.

Heb ik gedaan, en dat verandert ook wel maar het multicast adres is alleen lokaal niet toegankelijk. Extern wel, en A kan opzich gewoon communiceren met andere devices.

Wat ik vreemder vind is dat device B dus nog steeds de multicast-tree kan pingen en ook netjes een reply van A (en B ) terugkrijgt
Terwijl A zelf niet meer weet waar dat adres is

Dat is dus precies het probleem

Maar volgens mij worden de route-tabellen niet zomaar opnieuw opgezet, dat zal denk ik pas gebeuren bij een herstart van de netwerkdevice. (waar je ook die socket mee vrij geeft denk ik?)

Het device herstarten is geen optie omdat ik de IP configuratie doe met een eigen implementatie van het Zeroconf Link-Local Addressing protocol. Het ligt echter niet aan de werking daarvan aangezien het probleem zich ook voordoet met 'ifconfig'.

Alles lijkt er op te wijzen dat er een bug in de interne routering van multicast verkeer zit. Dat komt blijkbaar alleen tot uit bij dynamische IP adressen die tijdens een multicast sessie wijzigen.

Btw, ik weet eigenlijk niet waar je beter antwoord kan krijgen, hier of in NOS? Wil je het hier laten staan, of liever in NOS hebben?

Ik twijfelde ook heel erg. Het gaat hier wel om een implementatie kwestie die met sockets te maken heeft. De kern van het probleem zit echter in de kernel zelf vermoed ik.

Ik heb hier wel een boek over de TCP/IP stack van de Linux kernel liggen, maar dat is niet iets wat je even in een middagje doorbladert om een probleem te fixen

[ Voor 1% gewijzigd door Exirion op 06-12-2002 12:58 . Reden: typo ]

[Exirion]

Ik ben nu FreeBSD aan het downloaden om te vergelijken. Als FreeBSD het wel goed doet dan is het een Linux bug

[Verwijderd]

Uit man 7 udp

code:

       In order to receive packets the
       socket should be bound to an local address first by  using
       bind(2),  when  this is not the case the socket layer will
       automatically assign  a  local  port  on  the  first  user
       receive request.

Maw. als je local address verandert, zul je de udp-socket opnieuw moeten bind()en, cq. een nieuwe socket bind()en.

[Exirion]

Verwijderd schreef op 06 December 2002 @ 15:32:
Maw. als je local address verandert, zul je de udp-socket opnieuw moeten bind()en, cq. een nieuwe socket bind()en.

Dit klopt helaas niet. Als het IP adres verandert dan wordt de administratie van de socket gewoon aangepast. Via getsockopt() krijg ik dan ook het nieuwe adres terug. Bovendien werkt de socket prima, want zoals ik beschreef blijft de server actief en toegankelijk voor host B.

Het enige probleem is dat het multicast adres lokaal niet goed gerouteerd wordt, maar waarom.....

[Verwijderd]

Multicast-HOWTO

Some considerations: first, note that you don't just join a group. You join a group on a particular network interface. Of course, it is possible to join the same group on more than one interface. If you don't specify a concrete interface, then the kernel will choose it based on its routing tables when datagrams are to be sent. It is also possible that more than one process joins the same multicast group on the same interface. They will all receive the datagrams sent to that group via that interface.

As said before, any multicast-capable hosts join the all-hosts group at start-up , so "pinging" 224.0.0.1 returns all hosts in the network that have multicast enabled.

Finally, consider that for a process to receive multicast datagrams it has to ask the kernel to join the group and bind the port those datagrams were being sent to. The UDP layer uses both the destination address and port to demultiplex the packets and decide which socket(s) deliver them to.

f you want just to send and receive, you must say yes to "IP: multicasting" when configuring your kernel. If you also want your Linux box to act as a multicast router (mrouter) you also need to enable multicast routing in the kernel by selecting "IP: forwarding/gatewaying", "IP: multicast routing" and "IP: tunneling", the latter because new versions of mrouted relay on IP tunneling to send multicast datagrams encapsulated into unicast ones. This is necessary when establishing tunnels between multicast hosts separated by unicast-only networks and routers. (The mrouted is a daemon that implements the multicast routing algorithm -the routing policy- and instructs the kernel on how to route multicast datagrams).

[Exirion]

Verwijderd schreef op 06 december 2002 @ 17:01:
Multicast-HOWTO

Dank voor je bijdrage, maar ik ken de documentatie van haver tot gort

Het eerste stuk ken ik, maar zoals ik al zei: voor externe hosts blijft de multicast goed werken. Ik bind expliciet aan eth0, dus het eerste stuk is dan verder niet relevant.

Het tweede stuk spreekt voor zich. Als ik dat niet gedaan had dan zou multicasting helemaal niet gewerkt hebben Het probleem waar ik mee zit is wat dieper en ingewikkelder dan de multicast basics. Het is onverklaarbaar dat host B nogsteeds kan multicasten naar de server op host A terwijl host A zichzelf niet meer kan vinden