As a temporary fix, i have blocked the port 5353/UDP on ipv6 with firewalld.

Checked with local N/W team and unable to do the set up to test and confirm this.

Adding Internals>Network tentatively. Could someone from Internals>Network team take a look into this issue further.

Thanks

Kpn sukses kita

Thanks for filing the bug, could you grab a NetLog per instructions below so that we can help investigate the issue? Thanks

Instructions available at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Ok, tomorrow i will provide the NetLog.
Thanks!

Thank you for providing more feedback. Adding requester "zhongyi@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We won't be able to get much further without a net-internals log, as per comment #5.

Sorry for the BIG delay.
Here's the log.

Deleted: chrome-net-export-log.json.tar.gz 779 KB

chrome-net-export-log.json.tar.gz 779 KB Download

Deleted: Captura de tela em 2018-02-08 14-54-35.png 184 KB

	Captura de tela em 2018-02-08 14-54-35.png 184 KB View Download

Thank you for providing more feedback. Adding requester "zhongyi@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Any chance this may be https://support.google.com/chromecast/answer/7634752 --- caused by an Android or Chromecast device? 

The NetLog mostly seems to show Chrome receiving the flood --- the viewer UI seems to have problems with its size, but using cruder methods:

$ cat chrome-net-export-log.json|fgrep -v '"type":78}'|wc -l
142

$ cat chrome-net-export-log.json|fgrep  '"type":78}'|wc -l
691841

where type 78 is: "UDP_BYTES_RECEIVED":78

I don't think the problem is caused by Android or Chromecast because on the tcpdump, i see my own computer sending this stuff

Oh, of course, unlike me you would know what the IPs involved are. Anyway, this is what the bulk of the log looks like --- basically the same thing as your TCPDump, just with only one address, and 
sizes at a different layer:
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::b00f:2562:623b:7057]:5353"
                    --> byte_count = 40
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::250:56ff:fea6:589f]:5353"
                    --> byte_count = 34
t=    0 [st=    0]  UDP_BYTES_RECEIVED
                    --> address = "[fe80::250:56ff:fea6:589f]:5353"
                    --> byte_count = 34

Hmm, the socket the receives are on is associated with [fe80::46a:363c:33c2:8b31]:5353 ---- maybe that says something to you?

What's interesting is that it's not logging any sends; so if whatever is sending this is in Chrome, it's either not using the standard UDP socket classes or not 
using the standard log.

@reporter can you answer the questions in comment #12?

I think the problem is related to the LAN where i was connected (my job LAN). Because on my house i can't reproduce this.
On the job LAN i can see printers, Chrome searching Chromecast flooding the log, and others devices using the mDNS via IPV6.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can you collect a net-internals at work then where the problem reproduces?

+ Internals>Cast,

This seems to be related to media discovery in Chrome. Cast folks, do you know if this is a known issue, or maybe it is related to https://support.google.com/chromecast/answer/7634752 ?

We've changed some old switches and the problem is gone.
I think it's related to this device.
Sorry for alert all here.

Thanks for the support!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the update. Closing this bug per comment #20.