I have a very odd situation that I'm hoping you can help out with, I am not a networking expert by any means and am trying to do some troubleshooting. I picked up a MiraBox HDMI extender, which is basically a box that encodes HDMI signals for multicast to receivers on the network. In theory you plug in the transmitter, plug in one or many receivers, and the HD signal is broadcast across your IP network. The transmission and receiving of video works, and my wired network appears unaffected. However my wifi network degrades to the point that it is unusable and clients can't connect. The interfaces on the MiraBox devices are all wired and at no point is there point to point communication between the devices over wifi. I downloaded WireShark on my Mac to see if I could determine what is going on. - On the wifi interface, I get a flood of GVSP packets. They are tagged as unknown Format and have a bad checksum - With the wifi interface disconnected and looking at the wired interface, I see a flood of UDP packets. They are tagged as bad checksum. Some of them are tagged as Bad UDP length, but those ones don't seem to be throwing the checksum error. I have two similar transmitter devices, both exhibit the same behaviour. The manufacturer claims they work fine in their testing. I found one other user reporting similar issues with a similar device. Returning them isn't really an option as the shipping back to China is almost the same as the cost of the devices. Any tips on what could be causing this or troubleshooting steps? So far I've tested the two different transmitters (same), connecting to the switch versus connecting to the router (same), different ethernet cables (same). I have no idea what would be causing this. Not sure if this is relevent, but here is my networking equipment. - Asus AC3100 Router / Wifi acting as the gateway & DHCP - After the router, a Netgear GS116 Switch - After the switch, Two Asus AC-66U in Access Point mode Thanks in advance! asked 21 Jun '17, 07:57  pnear |
2 Answers:
Um..."multicast becomes broadcast"? Nope. Now, it may be that a device is sending multicast to all connected devices - if it hasn't been configured to handle multicast properly. I found instructions for the ASUS device that suggests it supports IPTV, but one must configure multicast proxy and IGMP snooping - see https://www.asus.com/us/support/FAQ/1011708/ So, if you want the IPTV available on wireless, you can try the configuration described at the link above. If you don't want it, you'll probably have to configure the ASUS to block the traffic entirely. answered 22 Jun '17, 10:50  wesmorgan1 -1 Without more details.... Multicast becomes broadcast on any local subnet with a subscriber to that multicast stream. It sounds like your wireless network can't handle the amount of data being sent via multi(broad)cast. You indicate you do not need this on the wireless network. Suggested resolution: Segment wireless from wired network. This will keep broadcast traffic from wired off wireless. (22 Jun '17, 09:23) Velas Thanks all for the suggestions! I've started a thread over at the forum of the custom firmware maker for ASUS to see if there are any ideas on how to keep the broadcast traffic off of the wifi. Can't clean and upload a capture, but here is a screenshot of one of the offending packets. Hope this has enough info to answer some of the questions on the type of multicast in use.
(22 Jun '17, 12:00) pnear Pnear, If you do want to scrub your capture to upload, this tool makes it quite easy. https://www.tracewrangler.com/ It is my belief that your wireless network simply can't handle the amount of data being sent by the HDMI streaming device. There's a bit of a side debate on this, but multicast will be broadcast on your LAN if any device is subcribed to the stream. (Your screenshot confirms destination ip address and destination mac are multicast, thus your layer 2 switches can not possibly know what clients want this traffic, thus it sends it to all - aka broadcasts) As such, you will always have this traffic on the entire layer 2 link that any listener is on. As I see it you have two options: 1) Fix/upgrade wireless to handle this extra, unwanted load. 2) Isolate wireless from this traffic by implementing a new subnet for wireless, with routing between it and existing LAN. (broadcast traffic will not cross subnets) (22 Jun '17, 12:11) Velas |
Yes, multicast traffic is addressed to a broadcast address and multicast MAC. Layer 2 will deliver this to all endpoints. Need confirmation? 1) Run Wireshark in promiscous mode on LAN client 1. 2) From LAN client 2 - go to tunein.com and start playing any stream. 3) Review capture for destination "broadcast", protocol <> ARP, etc. I find it interesting that your suggestion is the same resolution (block broadcast on wireless if he doesn't need the stream there). Of note, the OP explicitly stated he does not need this stream on wifi. Further, he states it is saturating the wireless link with no subscribers on wireless, further confirmation of multicast becoming broadcast in nature on local layer 2 data link when any host on that link is a subscriber. EDIT: External Explanation of muiltcast in a layman friendly format answered 22 Jun '17, 11:14  Velas edited 22 Jun '17, 11:15 Please go read your linked source on IP multicast. In particular, pay attention to the dissection of packet headers in their examples. Then look at OP's screenshot above. You will not find broadcast addresses in either example - you will find MULTICAST addresses. Here's a good "Introduction to IP Multicast" presentation from Cisco: http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/ip-multicast/prod_presentation0900aecd80310883.pdf Basically, IF the intermediate devices are configured properly, here's what should (basically) happen in a typical "last hop"/endpoint situation:
This is why the OP's ASUS wireless device requires specific configuration for IPTV/multicast. The device must be configured for multicast routing (by enabling its IGMP proxy) and what it terms 'efficient multicast forwarding' (which it terms 'IGMP snooping'); the former allows the device to handle IGMP requests from wireless clients, and the latter allows the device to 'eavesdrop' on the IGMP activity so that it will only forward multicast traffic to specific wireless endpoints as requested (via IGMP). Once this is configured, the ASUS device should NOT forward IP multicast traffic to any device that has not specifically requested it via IGMP. If OP does this configuration now, he should never see IP multicast traffic on his wireless clients UNLESS they specifically request it, AND he can stream IPTV to his wireless devices 'on the fly' if he ever decides to do so. Multicast is NOT broadcast. (23 Jun '17, 09:17) wesmorgan1 Velas - I don't think the packets you highlighted in your screenshot represent IP multicast traffic. EtherType 0x8899 is RealTek Remote Control Protocol (RRCP), and IPv4 multicast uses EtherType 0x0800 (IPv4). As far as I know, RRCP is only used for switch control; you may be looking at traffic specific to your particular hardware. I tried the tunein.com test you suggested, and I saw no RRCP traffic on my wireless endpoint; the audio stream was delivered via unicast HTTP2/TLS. (23 Jun '17, 09:26) wesmorgan1 |
You might want to share your trace - you can use trace wrangler to anonymize if needed.
Multicast has special handling on wifi on downlink direction so it is conceivable that it can cause issues as it is usually sent at some basic rate, possibly the lowest (and you might have yours selected at 1Mbps, and if you have even a modest amount of traffic at 1Mbps you have a problem). So this might be an optimization exercise but we have to see really what is involved, and the easiest way is with a wireless trace. Encrypted is likely fine for this class of problem... you are using an encrypted wireless network, aren't you?!!