Ik kan me eigenlijk niet voorstellen dat multicast discovery geblokkeerd zou worden op de wifi van de V10 en als dat wel zo is, dan bevreemd me het dat daar nu pas melding van gemaakt wordt immers veel apparatuur is sterk afhankelijk van multicast discovery. Denk hierbij aan bijvoorbeeld Airplay maar ook een Chromecast zou niet meer te vinden zijn.

Hoi wjb,

Ik heb het eerder gezien bij WiFi extenders. Ik heb het aan de LAN zijde van het KPN-modem met Wireshark gecontroleerd. Helemaal geen queries vanaf de WiFi-devices te zien.  Broadcast is door KPN nooit over de WiFi doorgelaten. Daar kan ik me nog wat bij voorstellen, maar Multicast? 

IGMP multicast werd niet doorgegeven en dat is ook correct immers multicast to unicast werd niet ondersteund. Alle andere vormen van broadcast en multicast werden altijd al doorgegeven anders zou de WiFi immers onbruikbaar zijn omdat mDNS dan niet zou werken en apparaten elkaar daardoor niet zouden kunnen vinden. Er moet mijns inziens een andere oorzaak zijn van de problemen die je ondervindt. 

Ik moet je heel eerlijk bekennen dat ik hier niet heel veel verstand van heb, maar ik denk ook graag met je mee. Kan je misschien iets meer vertellen over jouw thuisnetwerk, ​@J.J.M.? Welke apparaten heb je aangesloten? En heb je deze ook al eens allemaal herstart?

Getest als testpanel deelnemer:

Box 10 Versie V10.C.24.12.10, wordt nu uitgerold als V10.C.24.12.11:

Extender: TP-Link RE190.

Link local multicast name resolution Wifi->Extender->LAN(Win10) : Werkt
IP 192.168.2.100.llmnr > 224.0.0.252.llmnr: UDP, length 27
IP 192.168.2.5.llmnr > 192.168.2.100.llmnr: UDP, length 52

Link local multicast name resolution Wifi->Extender->Wifi: Werkt
IP 192.168.2.100.5355 > 224.0.0.252.5355: UDP, length 22
IP 192.168.2.140.5355 > 192.168.2.100.5355

Link local multicast name resolution Wifi->Wifi: Werkt
IP 192.168.2.101.5355 > 224.0.0.252.5355: UDP, length 22
IP 192.168.2.141.5355 > 192.168.2.101.5355: UDP, length 38

TV ontvanger LAN -> Wifi mdns : Werkt, geen responder actief
IP 192.168.2.1.5353 > 224.0.0.251.5353: 0 PTR (QM)? _googlecast._tcp.local. (40)

Oude NETBIOS broadcast lookup, wifi-wifi : Broadcast werkt
IP 192.168.2.101.60254 > 192.168.2.255.137: UDP, length 50
IP 192.168.2.141.137 > 192.168.2.101.60254: UDP, length 62

 

Dit is natuurlijk een beporkte test, welke adressen en poorten gebruikt u voor P2P?

 

 

 

Hoi hmmsjan,

Daar noem je wat, volgens mij heb je me op het juiste spoor gezet.

Ik gebruik (uit gewoonte) 239.0.0.2/8 … 239.0.0.12/8 UDP port 60205 voor discovery. Daarna wordt 't regulier tcp of udp verkeer. 

Dit zit in de dynamic private port range en in de ‘private address space for use within an organization’. Heb ik met andere netwerken nooit problemen mee gehad.

Deed ‘t op de KPN WiFi altijd prima. Tot de update dus. Na jouw test krijg ik het vermoeden dat er niet rücksichtlos multicast van en naar de WiFi gedropt wordt, maar dat met de update het adresbereik en/of het poortbereik 'geknepen’ is.

De grote vraag aan KPN zou in dat geval zijn welke reeksen wel doorgelaten worden.

Heb even tijdelijk een ander accesspointje geregeld en 't werkt weer prima.

Heb daarna even een test op de KPN-WiFi gedaan met 224 ipv 239. En Inderdaad ….. doet 't weer prima.

 

Dus als iemand kan vertellen welke mc-reeksen/poorten er doorgelaten worden op de WiFi. Graag.

 

Mooi dat het weer werkt met deze workaround. Ik moet weer eens in die multicast materie duiken.

Als het gaat om multicast zenden aan de ene kant en tcpdump aan de andere kant, lijkt u gelijk te hebben en zie ik dat alleen werken binnen 224.0.0.0/24, het eerste blokje dus.

Echter: ik zie het zelfde gedrag bij Linux bij communicatie tussen host en virtuele machine via een bridge. Tot het moment dat op die bridge “mcast_snooping� wordt uitgeschakeld. Met andere woorden: een ontvanger moet zich aanmelden  via IGMP voordat hij de multicast toegestuurd krijgt.

Dus de vragen zijn: meldt uw P2P programma zich aan als luisteraar op 239.0.0.x ? Zitten er verschillen tussen oude en nieuwe firmware wat betreft multicast en het weghouden van de IP-TV multicast streams van de wifi?  (of omgekeerd: de nieuwe TV+ ontvanger laten werken met multicast over Wifi zonder alles plat te leggen)  

Ik moet in die testprogramma’s duiken (socat), dat is niet zo simpel, en kijken of 239.0.0.x over de Wifi te krijgen is na aanmelden, en zal KPN  melden als ik het niet voor elkaar krijg.

De communicatie gaat over een Microsoft .NET Socket.  Een node heeft altijd een server/listener actief. Of Microsoft dan ook al gelijk gaat adverteren heb ik eigenlijk nooit gecontroleerd, ik verwacht van wel.  De FW is zowel voor als na de modem update dezelfde.  Ik heb alleen gisteren even een nieuwe build gemaakt met 224.0.0.x ipv 239.0.0.x als basis.

IP-TV zit bij mij overigens niet in de vergelijking. Die is om de gebruikelijke problemen met de WiFi te voorkomen al vanaf dag 0 bekabeld.

Het lijkt te werken in versie Box10 + Linux, Wifi naar Wifi

Zender: socat STDIO UDP4-DATAGRAM:239.0.0.2:60205,range=192.168.2.0/24

Ontvanger: socat UDP4-RECVFROM:60205,ip-add-membership=239.0.0.2:192.168.2.151,fork EXEC:hostname

 

Deze magie stuurt standaard invoer naar 239.0.0.2 60205, de ontvanger(s) sturen de hostname terug die vervolgens op de zender wordt afgedrukt.

tcpdump:

13:20:02.545022 IP 192.168.2.141.38421 > 239.0.0.2.60205: UDP, length 559
13:20:02.548058 IP 192.168.2.151.60205 > 192.168.2.141.38421: UDP, length 5

Wifi->Wifi.  Er wordt niets gezien door tcpdump als de ontvanger niet loopt, dus membership is essentieel.

 

Wireshark: IGMPv3: 239.0.0.2 wordt aangemeld.

 

Frame 5: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface wls1, id 0
Ethernet II, Src: Intel_51:f2:de (00:26:c6:51:f2:de), Dst: IPv4mcast_16 (01:00:5e:00:00:16)
Internet Protocol Version 4, Src: 192.168.2.151, Dst: 224.0.0.22
Internet Group Management Protocol
    ÂIGMP Version: 3]
    Type: Membership Report (0x22)
    Reserved: 00
    Checksum: 0xebfb hcorrect]
    rChecksum Status: Good]
    Reserved: 0000
    Num Group Records: 1
    Group Record : 239.0.0.2  Change To Include Mode

 

Een snelle zoek op Microsoft documentatie leert dan IGMPv3 actief is, dus het zou moeten werken.

Als de ontvangende partij gestart wordt, wordt de IGMP door de ontvanger uitgezonden.

 

 

 

 

 

Ik kende socat nog niet. Het kan even duren, maar ik zal het hier ook eens proberen. Kijken of het resultaat vergelijkbaar is.

Ik vrees te moeten melden dat het van Wifi naar LAN niet werkt. Ik geef het door via het testpanel. Multicast DNS werkt wel maar ligt in 224.0.0.0/24, maar de test met socat en RTP streaming werken niet op 239.0.0.x

De stream vanaf Wifi  op default 224.0.0.56 is zelfs met tcpdump op LAN te zien zonder IGMP.

Wifi naar Wifi werkt correct.

224.0.0.69...100 staat als “unassigned� en zou dus zonder kans op conflicten gebruikt moeten kunnen worden.

Ik heb niet kunnen vinden of 224.0.0.0/24 een buitenbeentje is wat betreft IGMP, maar het lijkt er wel op.

Iemand citeert op intermet uit Cisco documentatie:

In general, addresses from 224.0.0.1 to 224.0.0.255 are reserved and used by various protocols (standard or proprietary, such as Hot Standby Router Protocol (HSRP)). Cisco recommends that you not use these for GDA in a multicast network. CGMP and IGMP snooping do not work with this reserved address range.�

Ik weet niet wat het allemaal betekent, maar IGMP lijkt in dit gebied dus niet te werken. Niet helemaal verwonderlijk, omdat IGMP zelf in dit gebied multicast. Het lijkt me dus geen probleem om vrije adressen daar te gebruiken voor “klein werk�. 

TV+ werkt trouwens prima via Wifi met multicast. dus IGMP is zeker vereist in de Wifi implementatie.

Het lijkt erop dat de 239.x.x.x  multicast ook niet werkt van 5GHz naar 2.4GHz wifi.