Accesspoint(s) werken niet op switch waar TV tuner op zit

[DaRoot]

Ik heb gisteravond bij een kennis een erg vreemd issue ontdekt, dat ik nog niet kan verklaren.
Situatie schets:
Solcon glasvezel aansluiting
Fritzbox Router met wifi als enige router daarachter.
8 poorts gigabit switch unmanaged achter de Fritzbox, waaraan diverse bekabelde apparatuur zit (Desktop PC's, printers)
vanaf die gigabit switch 1 UTP kabel naar een Fast Ethernet switch unmanaged in een andere kamer, waarachter dan weer een Draytek AP zit en een Arris TV ontvanger die bij het abonnement hoort.

Probleem:
Zodra de TV ontvanger aan staat en programma's ontvangt, is er geen data verkeer van/naar het AP mogelijk, zowel aan de ethernet kant als aan de wifi kant niet. Sluit ik ondertussen op diezelfde switch een laptop bekabeld aan, heeft deze wel gewoon data-verkeer.
Koppel ik de TV ontvanger af van de switch, werkt het AP weer naar behoren, en de laptop blijft ook werken.
Alle andere devices op de andere switch blijven ook gewoon werken.

Schema:


Ter test heb ik een unifi ap meegenomen en een Netgear 5 poorts Gbit switch managed. Als ik de Draytek AP vervang door de Unifi, zelfde resultaat.
Vervang ik de 5 poorts FE switch door die netgear, zelfde resultaat
Vervang ik die andere 8 poorts Gbit switch door die netgear, zelfde resultaat.

Sluit ik de AP aan op de eerste switch na de Fritzbox, werkt alles, dus Wifi en TV en bekabeld ethernet.

Er wordt nu waarschijnlijk een 2e kabel rechtstreeks van de Fritzbox naar de Arris ontvanger getrokken, dat zal het vermoedelijk wel oplossen, maar ik heb nog geen idee wat er nu echt aan de hand is.

Drukt zo'n TV tuner de rest weg op die switch door bepaald type verkeer? Dan zou de bekabelde laptop ook niet meer moeten werken lijkt me..
...

Relevante software en hardware in gebruik
Fritzbox router (type onbekend)
8 poorts Netgear gigabit switch unmanaged
5 poorts TP Link Fast Ethernet switch unmanaged
Draytek Vigor AP710 accesspoint

extra test-hardware:
Unifi AP AC lite
Netgear 5 poorts Gigabit managed switch

[Rukapul]

DaRoot schreef op vrijdag 18 februari 2022 @ 12:43:
Drukt zo'n TV tuner de rest weg op die switch door bepaald type verkeer? Dan zou de bekabelde laptop ook niet meer moeten werken lijkt me..

Ja, multicast TV traffic kan een draadloos signaal helemaal vol laten lopen.

Daarvoor heb je een switch nodig die IGMP snooping ondersteunt, of verschillende poorten gebruiken op de router als die IGMP snooping ondersteunt. Het TV verkeer blijft dan op de netwerk segmenten waar de TV ontvangers zich bevinden in plaats van overal.

[ Voor 10% gewijzigd door Rukapul op 18-02-2022 12:56 ]

[DaRoot]

Rukapul schreef op vrijdag 18 februari 2022 @ 12:55:
[...]

Ja, multicast TV traffic kan een draadloos signaal helemaal vol laten lopen.

Daarvoor heb je een switch nodig die IGMP snooping ondersteunt, of verschillende poorten gebruiken op de router als die IGMP snooping ondersteunt. Het TV verkeer blijft dan op de netwerk segmenten waar de TV ontvangers zich bevinden in plaats van overal.

Zoiets had ik ook al gevonden, maar hoe verklaart dat dan dat de bedrade laptop wel blijft werken? Komt dat doordat die multicast traffic 1 op 1 wordt doorgezet naar het wifi signaal, waardoor dit onbruikbaar wordt?

[laurens0619]

DaRoot schreef op vrijdag 18 februari 2022 @ 13:54:
[...]

Zoiets had ik ook al gevonden, maar hoe verklaart dat dan dat de bedrade laptop wel blijft werken? Komt dat doordat die multicast traffic 1 op 1 wordt doorgezet naar het wifi signaal, waardoor dit onbruikbaar wordt?

Goede vraag
Een tv stream is slecht een megabit of 5, die komen nu dus ook bij je laptop dus je hebt 5mbit minder bandbreedte

Wifi is alleen allergisch voor een multicast iptv stream en die hangt zichzelf op. Waarom dat is weet ik niet precies, vele retransmission oid?

Edit df opgezocht

The problems with multicast over WiFi vs wired

In a switched wired network, all traffic is sent at the same data rate (generally 1Gbps today) and with each port being its own collision domain, collisions are rare. In addition, wired traffic uses a bounded medium, so interference and frame corruption is also rare. Because of this, there is no network impact to sending large amounts of wired traffic as multicast. WiFi does not share either of these characteristics, which makes multicast more complicated. Below are some of the issues with multicast to multicast over WiFi:

Multicast traffic is sent at a mandatory data rate. As mentioned, WiFi clients share a collision domain. Because multicast is a single transmission that must be received by all transmitted receivers, access points are forced to send that frame at the lowest-common-denominator settings, to give the receivers the best chance of hearing the transmission uncorrupted. While this is fine for small broadcast traffic like beacons, it’s unsustainable for high-bandwidth applications.
Low data-rate traffic consumes more air time. Because multicast traffic is sent at a low data rate, it takes longer for each of those transmissions to complete. A 1MB file sent at a data rate of 1 Mbps will take significantly longer than the same file at a data rate of 54Mbps. This means that all other stations must spend more time waiting for their turn to transmit.
Battery-powered clients have reduced battery life. Multicast and broadcast traffic are sent at the DTIM interval, which all stations keep track of. When a multicast frame is sent, all stations must wake up to listen to the frame, and discard it if they don’t need it. This results in battery-powered devices staying awake for a lot longer than needed. If the DTIM interval is too high, the increased latency can impact real-time applications like video. But the lower the DTIM interval, the more often stations need to wake up.
Multicast senders will not resend corrupt frames. Frame corruption and retransmissions are a standard part of any WiFi transaction. Every unicast frame, even if unacknowledged at upper OSI layers such as when using UDP, are acknowledged at Layer 2, and retransmitted by the sending station if necessary. This may not seem like a big deal at first, as unacknowledged traffic on a wired network works fine most of the time. But in an area of interference or poor RSSI level, it’s not unusual to see 10% of wireless frames retransmitted. 10% loss would be considered extremely high on a wired network, and most applications are unable to handle this level of loss.

[ Voor 68% gewijzigd door laurens0619 op 18-02-2022 14:34 ]

[DaRoot]

laurens0619 schreef op vrijdag 18 februari 2022 @ 14:28:
[...]

Goede vraag
Een tv stream is slecht een megabit of 5, die komen nu dus ook bij je laptop dus je hebt 5mbit minder bandbreedte

Wifi is alleen allergisch voor een multicast iptv stream en die hangt zichzelf op. Waarom dat is weet ik niet precies, vele retransmission oid?

Edit df opgezocht


[...]

Dan zou dat dus kunnen als zo'n Accesspoint die multicasts 1 op 1 doorzet van LAN naar Wifi..
Dat zou dan een plausibele verklaring kunnen zijn..

laurens0619 schreef op vrijdag 18 februari 2022 @ 14:28:
[...]

Goede vraag
Een tv stream is slecht een megabit of 5, die komen nu dus ook bij je laptop dus je hebt 5mbit minder bandbreedte

Wifi is alleen allergisch voor een multicast iptv stream en die hangt zichzelf op. Waarom dat is weet ik niet precies, vele retransmission oid?

Edit df opgezocht


[...]

thanks voor de info.
dan vermoed ik dat zo'n AP dat verkeer 1 op 1 doorzet van LAN naar Wifi, omdat het AP immers ook niet weet of een wifi client dit verkeer wil gebruiken of niet.
Dan is zeer waarschijnlijk de oplossing die ze gaan toepassen, een aparte kabel rechtstreeks van Fritzbox naar TV ontvanger, afdoende om e.e.a. te voorkomen / op te lossen.