Hi  @CShaw 

CShaw wrote

 

Questions:-

• Is this expected behaviour or a bug? If expected - why? If a bug - is there a fix?
• As the switch is unmanaged, can I configure it to not drop these packets?
• Is this the same across other TP-Link devices?
• Do other manufacturers' switches have this issue? What switch do I need that will not do this? 

 

Thanks for any assistance.

 

Chris

1) It is an unmanaged switch, which means there will never be a firmware release/fix.

2) Unfortunately, no.

3) For smart switch you can drop the unknown packets. This is an option you can choose. See the User Guide of the smart switch. Refer to the model naming format guide I wrote.

4) I am not aware of/familiar with any other vendors.

Hi @CShaw 

Thanks for posting in our business forum.

CShaw wrote

  @Clive_A Thanks for the reply.

 

Can you also please confirm the operation as described, and whether this is a known/accepted bug.

 

Are you able to guarantee that if I purchase an EasySmart switch (e.g. TL-SG1210MPE or any other with an 'E' suffix) this will not also have this fault?

 

Thanks,

 

Chris

Smart switch is starting with the 2000 series. Not 1000 series.

Hi @CShaw 

Thanks for posting in our business forum.

CShaw wrote

  @Clive_A Thank you for clarifying, so understand I need to look at the SMB switches rather than home office.

 

1. Can you please confirm the operation of the SG1005LP has the fault as described above, and whether this is a known/accepted bug?
2. Can you confirm that any of the smart switches (2000 series), in particular models SG2218P, SG2016P, SG2210P and SG2210MP, will NOT have the fault?

 

Thanks,

 

Chris

I cannot reply to them before I have a test result from the dev. The specific reason for why that happens to your network is unknown to me.

We will do some generic multicast test to see if this is a problem.

Hi @CShaw 

Thanks for posting in our business forum.

CShaw wrote

  @Clive_A Thank you very much.

 

Regards,

Chris

Based on the team's reply, when there is a router involved, an IGMP report will be sent to the router.

Will you capture this on the router? Is the query frame sent to the switch?

Hi @CShaw 

Thanks for posting in our business forum.

CShaw wrote

  @Clive_A Thanks for the follow-up.

 

The router (in this case, a TP-Link AX-1800) sends IGMPv3 membership queries every 255s or so. I can see IGMPv3 replies from several devices at this point, but not from my IGMPv2-generating device. This is the same whether I use Wireshark whilst connected to the wi-fi or to the switch. My laptop is subscribed to the mutlicast group 239.192.0.1 that we use.

As soon as I remove the switch from the topology the IGMPv2 message is visible across the network and the multicast works.

I've tried to capture the topology below. GGB-i1 is our development device. The WAP is a TP-Link WA850RE - i.e. all network infrastructure is TP-Link.

 

 

The two Wireshark captures below show the problem. My device IP is 192.168.1.106. In the first you can see the IGMPv2 Join Group messages. The switch is not present in this case.

 

In the second, the same test has been run with the switch in place. There is no IGMP traffic from the device as it has been blocked/consumed by the switch. 

 

The main difference in v2 and v3 is the destination of the message: always 224.0.0.22 in v3, but the mutlicast address in v2.

 

 

I asked the test team to look into this.

So, the PC that is used by Wireshark may not be included in the multicast group so it does not receive anything. This case might be the described situation.

Well, the switch cannot be configured, you cannot know this port mirror.

You can try out the models that do not support IGMP like LS1005G. Or models that can disable the IGMP snooping.

It does not support V3 and it is normal that it does not process V3 traffic.