I already said the double NAT probably wasn't an issue here ,)
agreed, but I wanted to make sure the security implications were clear.
1 Like
Please do not argue 
You both have already established that it won't be because of the double NAT.
But this is somethin i want to do beside of this special problem.
So thank you frollic for your idea. I will think about this - especially how i still can use the router to firewalling and so on.
But for my current problem i don't know what to do.
Now i prepare my other Mi 3G to replace the router - maybe it's a hardware issue - i don't know.
when something just crops up suddenly, and if you bypass a piece of hardware it goes away, a hardware issue is a definite possibility.
2 Likes
Now that you've established it works on the modem-router, try moving your units further and further away from it (network wise), to see when/where they start to fail again.
2 Likes
Then first of all thank you both up to here.
I will try to replace the router and then report.
However, this should take a little while.
1 Like
You already have three routers in your network, move some stuff around 
I had the same problems with my Archers some time ago. The devicr group of echo and subwoofer did not start playing after saying the command and then they played 2 seconds of music and stopped.
It all came down to setting DTIM 1 instead of 2 (default) so the transmission was "syncing faster between alexa devices". Never had this problem again after that.
And please ensure your switches and Openwrt systems so mdns snooping properly on the multicast. Without, a mdns packet loop could load your network heavily.
1 Like
Cool - that's a pretty concrete hint. I will try this tomorrow (now the kids already sleeping).
How do I check this specifically?
I have not found a corresponding sounding setting in the switch. Also not on the OpenWRT devices.
1 Like
What he means is turn on igmp snooping
2 Likes
Ah thank you. I did not associate IGMP with DNS.
Yes igmp snooping is switched on on every network device in my network including the switch.
1 Like
@frollic, @dlakelan, @Catfriend1
Slowly I am despairing. What i did so far?:
- I replaced the lte-modem with another one (same model).
- I changed the sim-card of the lte-modem.
- I completely replaced the router with another Xiaomi Mi 3G (config mainly leave the same)
- I set the DTIM on all wifis to 1 as Catfriend1 told
Then i connected a echo device directly with the wifi of the router (not a AP). With this setup the switch and the APs are uninvolved and can be excluded as the source of error (although the RXBadPkt errors at the switch port statistics still worry me).
The result: The music plays some seconds and then: stop - wait nearly 10s - music plays again some seconds - then stop again...
A hardware error can basically be ruled out, since both the modem and the router have been replaced.
So it can almost only be due to my router configuration. But I have no clue where the problem could be.
What switch do you use? Tplinks count 802.1q vlan trunk packets as bad but that is no error in real.
1 Like
Your guess is correct - it is a TP-Link. This would already explain the problem.
I also disconnected the LAN side so that the switch is no longer connected to the router at all. The problem still exists.
1 Like
here is how my multicast cfg looks like:
config interface 'VL50'
option proto 'static'
option delegate '0'
option igmp_snooping '1'
option igmp_v3 '1'
option multicast_querier '0'
option type 'bridge'
option ifname 'bat0.50 eth0.50'
I had to replace my TPLink SG1024de switch with a smaller SG108DE-v5 because my wireshark showed corrupted mdns packets originating from the echo devices looping around. it turned out the 1024 unit had a lack mdns/igmv3 snooping support causing this - the newer sg108de v5 model with igmp snooping turned on made the packet storm every second cease.
1 Like
I agree the RXBadPkt is not really an error, it's a problem in the way the switches firmware accounts packets... they're not really bad. So we can ignore that issue.
I definitely think a wireshark is in order... Connect the amazon echo in the way you describe above directly to the wifi of the router... and do a tcpdump on the wifi interface.
tcpdump -i wlan0 -w /tmp/packets.pcap
then play the music and wait for it to go through 2 cycles of play/freeze and then stop the packet capture. (replace wlan0 with the name of the device actually used in your router for the wlan you're connecting to)
This should give you a good idea of what is up. if you want me to take a look at the pcap file I can do that. private message me with a link.
1 Like
... and if you let the echo play (with hick ups), and disconnect the rest of the network,
does the playback go back to normal ?
1 Like
I added the igmp_v3, multicast_querier and delegate option to my interface. And indeed: It seemed to get better now. In the meantime, however, this turns out to be a fallacy. The playback still stalls. 
Hm i have the SG1016DE-v3. However, since the problems occurred when the switch was no longer connected to the router at all, I would postpone replacing the switch for a while. Especially since it also worked with this switch in the past.
Almost - I disconnected the switch so that only the Wifi clients of the router itself were connected to the router and the Internet. Besides the Echo device, there were a few other devices connected to that wifi.
In this configuration, the errors continued to occur.
I'll run the test again tomorrow (the kids again...) and make sure that the Echo device is indeed the only connected device.
Thank you very much for the generous offer. I will be very happy to take advantage of it, as I can only see that there are problems in the dumps, but I cannot identify their cause.
The next few days I will probably also perform a downgrade to the 19.07.5, because it worked in principle at that time with this version.
1 Like
I did look at the capture file. It's hard to know how it's different from when it's working right.
First off, we can ignore Multicast or UDP. It seems the data is entirely transferred by TCP:
You can see there's a bunch of out-of-order packets (red).
My impression is that you're suffering packet loss or out-of-ordering.
Have you replaced the cable between your LTE-modem and your router?
Can you try running a dslreports.com speed test and posting a link to the results page here?
Mine too, but didn't found the origin for this.
Not complete. Only the patch cable from the router to the patchbay.
The other cable is going directly through the house to the attic.
This cable isn't old (1 year). But tomorrow i will try to connect the modem directly side by side to the router.