Issue 373181 in chromium: Chromium packet storm on port 5228

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Type-Bug Pri-2

New issue 373181 by david.st...@gmail.com: Chromium packet storm on port
5228
http://code.google.com/p/chromium/issues/detail?id=373181

Chrome Version : 31
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 6: OK
Firefox 20:
IE 7/8/9/10: OK

What steps will reproduce the problem?
1. Installing chromium
2. Ubuntu Linux 14.04
3. Waiting till chromium sends

What is the expected result?

Normal behaviour

What happens instead?

770 requests per second on port 5228

Please provide any additional information below. Attach a screenshot if
possible.

Chromium-browser is DOSing our firewall.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 373181 by j...@agatan.se: Chromium packet storm on port
5228
http://code.google.com/p/chromium/issues/detail?id=373181

google services use 5228, hangouts, google play, GCP.. etc use 5228.. im
betting all req. have same dest addr?

[chro...@googlecode.com]

Updates:
Cc: z...@chromium.org dim...@chromium.org t...@chromium.org
Labels: Cr-Services-CloudMessaging

Comment #3 on issue 373181 by yuk...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Thank you for the report. Port number 5228 looks to be relevant to GCM
(Google Cloud Messaging). CC-ed GCM folks just in case.

zea@, dimich@, tim@:
I've speculatively added Cr-Services-CloudMessaging label. Please remove it
if this issue is not relevant to GCM.

[chro...@googlecode.com]

Comment #4 on issue 373181 by paddy.do...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

I can confirm three users with Chrome version 34.0.1847.137.

Two are on Linux, one on MacOS.

Restarting the browser seems to have stopped the packet storm. Unsure yet
if it will start up again after a time, or if it was a once-off.

[chro...@googlecode.com]

Comment #9 on issue 373181 by paddy.do...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

90% of traffic trying to hit 74.125.24.188, with about 9% trying to hit
74.125.138.188

Not sure if it's the same for the OP, but just to note that we proxy web
traffic behind our firewall. The DOSing client machines are configured with
the proxy (and that's normally fine for regular web browsing etc), but for
some reason they were trying to access those IPs directly, and so were
being blocked on the firewall.

Looking at last night's logs, a couple of the desktops are trying to access
74.125.24.188:5228 about once every 10 minutes. So, nowhere near the
previous packet storm, but they are still trying to access the remote
machine directly, not via the proxy.

[chro...@googlecode.com]

Comment #10 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

M34 doesn't have proxy support in GCM, that landed in M35 (which I believe
should be coming out soon). 10 minutes is the current max backoff, so that
sounds right too.

That said, it's fine for this connection to fail, it's not critical in M34.
In M35 sync will start relying on it though, but it should respect proxies
then too.

Good to know that the client is no longer spamming retries, although it's
not clear how it got into a loop. If that happens again though, please let
us know, particularly what the delay between retries is.

[chro...@googlecode.com]

Comment #13 on issue 373181 by whoisa...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

It is doing it on our desktops running Chrome version 34.0.1847.137 m on
Windows 7.
The destination is typically 74.125.30.188(tcp/5228) Not every computer out
of 1000+ will try and connect but when it does it runs for 5-10 minutes at
random times. We can close Chrome and relaunch it and it could or could
not happen. We have tried disabling all extensions but that does not
correlate to the occurrence of this traffic.

[chro...@googlecode.com]

Comment #14 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

What is the proxy/firewall's behavior for these connections? What kind of
response is it returning? I'd like to see if I can reproduce this locally.

[chro...@googlecode.com]

Comment #15 on issue 373181 by paddy.do...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

For us, it's simply a Deny message on the firewall:

It's the same for both the `normal' 10-minute connection attempts, and
during the packet storm.

Here are the last few entries before, and the first few of the spamming:

May 21 08:07:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/41677
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:17:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/41923
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:27:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42179
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:37:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/35081
dst outside:74.125.138.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42700
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42701
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42702
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42703
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42704
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42705
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42706
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]
May 21 08:47:07 X.X.X.X %PIX-4-106023: Deny tcp src inside:X.X.X.X/42707
dst outside:74.125.24.188/5228 by access-group "outbound" [0xcdd950af, 0x0]

[chro...@googlecode.com]

Comment #16 on issue 373181 by email.yu...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

We noticed this traffic at the beginning of May. Huge amount of traffic
went to 74.125.x.188 at TCP/5228. We set FW rule to block TCP/5228 traffic.

By our observation, the traffic starts whenever Chrome is started. Lots of
Keep-alive traffic to those Google IPs. When closing Chrome, we notice that
there are [FIN ACK]. Then this means there is something in Chrome
continuously talking to Google.

Hopefully it's not doing evil stuff. Right now many business applications
are moving to browser-based on client side......

Google should clarify what they are collecting.

[chro...@googlecode.com]

Comment #17 on issue 373181 by fgor...@chromium.org: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

To clarify what why this is happening:
http://blog.chromium.org/2014/04/simplifying-cloud-messaging-for-app.html
This connection enables chrome.gcm API and other consumption of Google
Cloud Messaging starting M35 (with Proxy support).

[chro...@googlecode.com]

Comment #20 on issue 373181 by paddy.do...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

No further issues with Chrome 35 (so far anyhow). Seems to have fixed it.

[chro...@googlecode.com]

Updates:
Status: WontFix

Comment #21 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Awesome. Closing this for now, feel free to comment if the problem reoccurs.

[chro...@googlecode.com]

Comment #22 on issue 373181 by cmta...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

I'm seeing this same issue on OSX Mavericks with Chrome 35.0.1916.114.

[chro...@googlecode.com]

Comment #24 on issue 373181 by balaji.m...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

I'm also having this same issue with version 35.0.1916.114...but i have
this issue with different scenario ..Most of my campus PCs trying connect
to mtalk.google.com with port 443 and mtalk.google.com with port 5228.When
i see proxy log i can see many request coming from client to
mtalk.google.com ip address 74.125.68.188 .If i close the
chrome the traffic is not coming .is it bug with this version ?

[chro...@googlecode.com]

Comment #25 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

balaji: No, the fact that there are requests to mtalk.google.com:[5228,
443] is expected (background at
http://blog.chromium.org/2014/04/simplifying-cloud-messaging-for-app.html).
This bug is that in 34 the client appeared to be flooding if behind certain
proxies/firewalls.

[chro...@googlecode.com]

Comment #27 on issue 373181 by balaji.m...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Yes,it couldnt complete proxy authentication ..

Zea,what is fix for this issue ?ofcourse we have proxy since we are using
chrome at corporate company .

[chro...@googlecode.com]

Comment #28 on issue 373181 by nets...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

I am also seeing the issue where our squid proxy is being flooded with
requests to mtalk.google.com:443 and mtalk.google.com:5228 - The proxy is
not blocking via a squid policy specifically however since Chrome doesn't
appear to be sending authentication with these requests it is being denied
by squid.

The flood is extremely aggressive and repetitive. Please fix it or tone it
down a bit (a LOT)

[root@ldrwebpxytst01 squid]# cat /var/log/squid/access.log |grep
10.4.208.44 |grep mtalk.google.com |wc -l
7960164
[root@ldrwebpxytst01 squid]#

Nearly 8million requests since squid rolled it's logs 12hours ago from 1
client!

1402454784.992 0 10.4.208.44 TCP_DENIED/407 3296 CONNECT
mtalk.google.com:443 - HIER_NONE/- text/html
1402454785.016 0 10.4.208.44 TCP_DENIED/407 3291 CONNECT
mtalk.google.com:5228 - HIER_NONE/- text/html
1402454785.039 0 10.4.208.44 TCP_DENIED/407 3296 CONNECT
mtalk.google.com:443 - HIER_NONE/- text/html
1402454785.062 0 10.4.208.44 TCP_DENIED/407 3291 CONNECT
mtalk.google.com:5228 - HIER_NONE/- text/html
1402454785.083 0 10.4.208.44 TCP_DENIED/407 3296 CONNECT
mtalk.google.com:443 - HIER_NONE/- text/html
1402454785.107 0 10.4.208.44 TCP_DENIED/407 3291 CONNECT
mtalk.google.com:5228 - HIER_NONE/- text/html
1402454785.130 0 10.4.208.44 TCP_DENIED/407 3296 CONNECT
mtalk.google.com:443 - HIER_NONE/- text/html
1402454785.151 0 10.4.208.44 TCP_DENIED/407 3291 CONNECT
mtalk.google.com:5228 - HIER_NONE/- text/html
1402454785.174 0 10.4.208.44 TCP_DENIED/407 3296 CONNECT
mtalk.google.com:443 - HIER_NONE/- text/html
1402454785.198 0 10.4.208.44 TCP_DENIED/407 3291 CONNECT
mtalk.google.com:5228 - HIER_NONE/- text/html

[chro...@googlecode.com]

Comment #29 on issue 373181 by nets...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Forgot to mention version is 35.0.1916.153

[chro...@googlecode.com]

Comment #33 on issue 373181 by eaton.ja...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

We just had this same excatly problem, it was creating havok on our
firewall, creating around 1400-1500 messages per second, not sure what
version of Chrome it was. I'll get that on here tomorrow.

[chro...@googlecode.com]

Comment #36 on issue 373181 by testise...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Any chance this gets fixed anytime? Our proxies are hammered by the storm
of packets to mtalk.google.com:5228

[chro...@googlecode.com]

Comment #37 on issue 373181 by cben...@chromium.org: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

zea: We have a number of test authenticating proxies within Google that you
can use to try to reproduce some of these cases.

Is there a way to disable GCM via group policy or any other workaround
until these issues are addressed in Chrome?

[chro...@googlecode.com]

Comment #38 on issue 373181 by 25thbolt...@googlemail.com: Chromium packet

storm on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Extract from a Squid log at the point that a Chrome client began to send
millions of requests - if it's any help:

1402497313.452 570 10.x.x.x TCP_MISS/200 12977 CONNECT
login.live.com:443 user...@COMPANY.DOMAIN DIRECT/131.253.61.98 -
1402497389.511 1 10.x.x.x TCP_DENIED/403 3493 CONNECT
talk.google.com:5222 - NONE/- text/html
1402497410.518 1 10.x.x.x TCP_DENIED/407 3665 CONNECT
talk.google.com:443 - NONE/- text/html
1402497410.524 1 10.x.x.x TCP_DENIED/403 3502 CONNECT
talkx.l.google.com:5222 - NONE/- text/html
1402497431.530 1 10.x.x.x TCP_DENIED/407 3677 CONNECT
talkx.l.google.com:443 - NONE/- text/html
1402497472.729 1 10.x.x.x TCP_DENIED/407 3623 CONNECT
login.live.com:443 - NONE/- text/html
1402497472.899 240193 10.x.x.x TCP_MISS/200 3587 CONNECT
mail.google.com:443 user...@COMPANY.DOMAIN DIRECT/173.194.34.181 -
1402497473.355 623 10.x.x.x TCP_MISS/200 12977 CONNECT
login.live.com:443 user...@COMPANY.DOMAIN DIRECT/131.253.61.98 -
1402497556.358 1 10.x.x.x TCP_DENIED/403 3496 CONNECT
mtalk.google.com:5228 - NONE/- text/html
1402497556.364 1 10.x.x.x TCP_DENIED/407 3663 CONNECT
mtalk.google.com:443 - NONE/- text/html
1402497556.370 1 10.x.x.x TCP_DENIED/403 3496 CONNECT
mtalk.google.com:5228 - NONE/- text/html
1402497556.376 1 10.x.x.x TCP_DENIED/407 3663 CONNECT
mtalk.google.com:443 - NONE/- text/html
1402497556.381 1 10.x.x.x TCP_DENIED/403 3496 CONNECT
mtalk.google.com:5228 - NONE/- text/html
1402497556.386 1 10.x.x.x TCP_DENIED/407 3663 CONNECT
mtalk.google.com:443 - NONE/- text/html
1402497556.393 1 10.x.x.x TCP_DENIED/403 3496 CONNECT
mtalk.google.com:5228 - NONE/- text/html
[... 407/403 errors ad infinitum...]

[chro...@googlecode.com]

Updates:
Labels: M-36

Comment #40 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

#35, thanks! Those histograms were very helpful. I think I know what's
going on now.

The net::BackoffEntry code does a full exponential backoff calculation. In
the case of GCM, that means it calculates 2^(# of failures - 1) using a
double precision floating point variable. If Chrome has been running long
enough without a GCM connection, that failure count can easily reach above
1k. But, 64 bit doubles only have 11 bits of precision for the exponent, so
that calculation can result in an overflow/infinity result. This then
eventually turns into a NaN result when the jitter is incorporated, which
once the delay calculation completes results in a negative delay value and
therefore reuses the last valid backoff expiration time, despite a 30
second minimum delay. As a result, all requests from this point on behave
as if there were no backoff.

I estimate that with the current GCM backoff policy this issue will get hit
whenever a Chrome profile has been running for ~7 days without restart and
with GCM unable to connect.

Fix in the works.

In the meantime, workarounds include:
Letting unauthenticated requests to mtalk.google.com on ports 443 or 5228
through
Signing out of Chrome - GCM is currently only enabled for signed in users
Restarting Chrome periodically (< every 7 days)

We're also looking into options at our disposal for remotely disabling the
GCM feature specifically for a time.

[chro...@googlecode.com]

Updates:
Status: Started

Comment #41 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Labels: Hotlist-Enterprise ReleaseBlock-Stable

Comment #42 on issue 373181 by roy...@chromium.org: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Marking it as stable blocker for visibility. Proxy Auth is still common in
enterprises and this would be very bad.

[chro...@googlecode.com]

Comment #46 on issue 373181 by matthewy...@chromium.org: Chromium packet

storm on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

@zea, do we have an eta for the fix?

[chro...@googlecode.com]

Comment #47 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Fix is in review: https://codereview.chromium.org/337803004/. Should be
landing within the next couple days.

[chro...@googlecode.com]

Comment #49 on issue 373181 by bugdro...@chromium.org: Chromium packet
storm on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181#c49

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/6a4b3e16ae4d277a9274f21d3b07650f71a063fc

commit 6a4b3e16ae4d277a9274f21d3b07650f71a063fc
Author: z...@chromium.org
<z...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Wed Jun 18 19:58:42 2014

Backoff: Respect maximum delay in face of float overflow

Due to the 11 bit limitations for exponents in double precision, it's
possible
to overflow when calculating the backoff amount. Check for this overflow and
drop back to the max backoff delay if necessary.

BUG=373181
R=cben...@chromium.org

Review URL: https://codereview.chromium.org/337803004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@278153
0039d316-1c4b-4281-b951-d872f2087c98

[chro...@googlecode.com]

Comment #50 on issue 373181 by bugdro...@chromium.org: Chromium packet
storm on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181#c50

------------------------------------------------------------------
r278153 | z...@chromium.org | 2014-06-18T19:58:42.787225Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/base/backoff_entry_unittest.cc?r1=278153&r2=278152&pathrev=278153
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/base/backoff_entry.cc?r1=278153&r2=278152&pathrev=278153

Backoff: Respect maximum delay in face of float overflow

Due to the 11 bit limitations for exponents in double precision, it's
possible
to overflow when calculating the backoff amount. Check for this overflow and
drop back to the max backoff delay if necessary.

BUG=373181
R=cben...@chromium.org

Review URL: https://codereview.chromium.org/337803004

-----------------------------------------------------------------

[chro...@googlecode.com]

Updates:
Labels: Merge-Requested

Comment #52 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Yep, today's canary looks good.

[chro...@googlecode.com]

Comment #57 on issue 373181 by mslav...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

We observed many requests being denied by our webproxy due to NTLM auth
failing for web requests going to mtalk.google.com:5228 and
mtalk.google.com:443. Our web proxy requires NTLM auth and luckily this
applicaiton is smart enough to send a fin packet when the NTLM challenge is
presented. Concern is we have seen over 4.3 million hits on our web proxy
over the last 4 days. Userbase is using chrome V35.

[chro...@googlecode.com]

Comment #58 on issue 373181 by daniel.a...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

We have the same problem with two proxies Cisco WSA (Ironport). You have
any news? New release of Chrome? A workaround that can help us to reduce
the logs?

[chro...@googlecode.com]

Comment #59 on issue 373181 by mikkel.r...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

@daniel, We removed authentication on all transactions to mtalk.google.com.
This removed all TCP_DENIED/407 logs for our 4 WSA's generated by
mtalk.google.com. As you can see in http://imgur.com/a/VIUQS, this had
quite the impact.

[chro...@googlecode.com]

Comment #60 on issue 373181 by z...@chromium.org: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

FYI Chrome 36 has the fix to the issue, and should be coming out relatively
soon.

[chro...@googlecode.com]

Comment #61 on issue 373181 by daniel.a...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Sorry for the delay, @mikkel thank you very much for your help.
@zea thanks for the info.

[chro...@googlecode.com]

Comment #62 on issue 373181 by qbnc...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

I'm not sure how mandatory Google chat server connectivity is germane
to "moving the web forward." This is obviously an issue affecting
enterprise customers with proxy servers, especially ones using
authentication. Why is there no configuration available - via registry or
GPO .ADM files for Windows platforms as an example, that allow them to
selectively enable/disable features such as this in their environment? It
seems reasonable that a user would have some control over whether to use
very self-serving "features" being bolted onto the product like this, but
in too many cases we do not. If that information exists, it is well hidden
- every workaround we've seen indicates we need to modify our environment
to fit the product rather than the opposite.

[chro...@googlecode.com]

Comment #63 on issue 373181 by sulliv...@firemtn.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

At my site we've found a solution: Uninstall chrome. Google, are you
listening?

[chro...@googlecode.com]

Comment #64 on issue 373181 by tse...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Workstations are generating 50+ millions of request everyday to the proxy
server without authentication information. These Chrome workstations are
DDoS the proxy and AD.

Cannot wait further, our site has uninstalled Chrome!

[chro...@googlecode.com]

Comment #65 on issue 373181 by jake.eri...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

I would love to see this bug stamped out, I am on the verge of recommending
we also do a mass uninstall of Chrome if this behavior continues.

[chro...@googlecode.com]

Comment #66 on issue 373181 by mullins....@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

This issue is also heavily affecting our ability to log proxy traffic to
the point where it lags hours behind and this mtalk.google.com:5228/443 has
become 95% of our traffic (over 1 million entries in last hour).
We are also now discussing the removal of Chrome enterprise-wide.

Thanks Google.

[chro...@googlecode.com]

Comment #68 on issue 373181 by jjared.e...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Looks like this is only happening when you are logged in at google chrome?
Can somebody confirm this please?

[chro...@googlecode.com]

Updates:
Cc: pasta...@chromium.org binz...@chromium.org bar...@chromium.org
Labels: Cr-Enterprise

Comment #69 on issue 373181 by sas...@chromium.org: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #70 on issue 373181 by fgor...@chromium.org: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

RE #68 Yes, this only affects signed in users.

In version 35 and 36 GCM is only available to signed in users.

[chro...@googlecode.com]

Comment #72 on issue 373181 by tse...@gmail.com: Chromium packet storm on
port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Version 36 has been released for week. But we still found users' Chrome
generating a lot connections to mtalk.google.com without the proxy
authentication credential. Also, some users are without signed-in have
problem on this version.

Anyone has similar observations?

[chro...@googlecode.com]

Comment #74 on issue 373181 by christop...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

i am on version: Version 36.0.1985.125 m - still have problems with the
proxy log files
mtalk.google.com:443
mtalk.google.com:5528
are the problematic uri's.

still not solved in version 36 !

[chro...@googlecode.com]

Comment #75 on issue 373181 by kurtcheu...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

Agreed that Ver.36 is still affected!

for my case, some user were upgraded to Ver.36 but still generating 2XX
connection in a second.

[chro...@googlecode.com]

Comment #76 on issue 373181 by martin.c...@gmail.com: Chromium packet storm

on port 5228
http://code.google.com/p/chromium/issues/detail?id=373181

For those of you using squid 3.2+, have you tried using a deny_info to
return a page with an HTTP 500 instead of a 403 ? I seem to recall seeing
some code in chromium that treats http 500s differently.
(Disclaimer: I haven't tried this myself because I'm stuck with squid 3.1,
but I'm curious to see if it would fix it)

example:

acl no_mtalk_please dstdomain mtalk.google.com
http_access deny no_mtalk_please
deny_info 500:bogus_err_page no_mtalk_please


Doc: http://www.squid-cache.org/Doc/config/deny_info/

[chro...@googlecode.com]

Comment #77 on issue 373181 by allardpr...@gmail.com: Chromium packet storm
on port 5228
https://code.google.com/p/chromium/issues/detail?id=373181

#68. I have the same issue with Google Chrome on Ubuntu 14.04.1 LTS. I'm
using the latest stable version (38.0.2125.111) and I also see that Google
Chrome opens port 5228. I have connected Google Chrome with my Google
account to sync my data and when I unlink my account and restart Google
Chrome it doesn't open port 5228 until I add my account again.

[chro...@googlecode.com]

Comment #78 on issue 373181 by keithala...@gmail.com: Chromium packet storm

on port 5228
https://code.google.com/p/chromium/issues/detail?id=373181

There's more to this issue than what has been described here. I'm beginning
to think it is Heartbleed related. I've been having network issues on my
Mac OS systems since the Heartbleed announcement in April 2014. No problems
with Chromebooks (Ahem, problem is interface between Chrome and Mac OS or
Windows, i.e. Chrome implementation doesn't have full network libraries,
right?)

I have had issues with every stable MacOS release since then. And with two
different ISPs, Cox Cable and now Comcast. When I was with Cox using my
Netgear router, my router, yes again, MY ROUTER, was subjected DoS flood
attacks over UPnP ports. Traffic was occasionally intense enough to cause
the Cox cable modem to reboot repeatedly. My "cadillac" Netgear router had
UPnP enabled by default. Easy to turn off/block UPnP ports with a checkbox.

Now with Comcast, your network engineers at the AS15169 NOC facility in
Mountainview recently blocked my IP from Youtube servers, pushing a CAPTCHA
challenge to my Chromebook because they were receiving "a lot of requests
from my network." I did not respond to this
arbitrary "punishment/nonsense." Later in the day, I forwarded this thread
to n...@google.com and jo...@google.com and tried to be nice but ended up
sending a Howard Beale-like barrage loaded with insults.

I cannot use Chrome on my Macintosh systems anymore. I haven't been able to
track down the cause, the problem being the lack of any useful firewall
logs with my current Xfinity Comcast router (I plan to fix this soon) and
well, honestly, I'm tired of troubleshoot bugs created by
professional "coders" since 1985. (Yes, insult implied.)

Regardless, GCM is definitely involved, port 5228 is how I found this
thread. I have a Cloud-Ready Printer now and had a Classic Printer
registered previously.

On new MacBook Pro (now running Yosemite) waking from Sleep is an arduously
painful process, only if Chrome is running. First the dimmed screen with
progress bar is displayed, then there's close to 30 seconds of wait time
with an apparently usable screen but no cursor control. You can swipe your
finger back and forth over your trackpad for 30 seconds wondering why there
is no response. Isn't that fun!

This is apparently what was going on in the wee hours of the morning after
midnight the day after Christmas when I was accused of being a robot
watching too much Youtube. In this case though, my iMac in the basement
wired to the Xfinity modem/router/wifi box (which provides useless summary
firewall reports instead of true logfiles) was awakened as a 16-wheeler
rumbled by. On this system, Snow Leopard
(yeah, dual-core Intel but not supported by Mavericks+), there isn't any
GUI delay/freeze-ups but Chrome will be sending a lot of requests to GCM
servers.

How many times have your GCM servers been hacked, or should I say bled?
Honestly, I don't believe there's anything malicious going on here, just
the general clusterfuck that is the Internet today. Legitimate GCM users
might be incorrectly parsing records which have to be decoded in some way.
Beats the heck out of me. Sound like a nightmare to code. So imagine my
router being incorrectly identified as a UPnP service, or something along
those lines...

I recently noticed ROKU using Google DNS services (8.8.8.8 or something
like that?) and vaguely remember they updated firmware/software around the
time I had the UPnP DoS flood problems. I can't provide you with anything
useful for troubleshooting Google NOC related stuff but I've attached my
flood attack logs (not my current IP), well, so you believe me when I tell
you I've done all my own troubleshooting, have a clue about all this. No
reason for me to call the ISP Helpdesk, talk about a nightmare...

Attachments:
DoS Attacks TCP SYN FLOOD.txt 25.2 KB

[chro...@googlecode.com]

Comment #79 on issue 373181 by r...@fomar.com.pl: Chromium packet storm on
port 5228
https://code.google.com/p/chromium/issues/detail?id=373181

Why not add just a line
127.0.0.1 mtalk.google.com
to /etc/hosts or %sytemroot%\system32\drivers\etc\hosts

??

[chro...@googlecode.com]

Comment #80 on issue 373181 by paddyp1...@gmail.com: Chromium packet storm

on port 5228
https://code.google.com/p/chromium/issues/detail?id=373181

I have Version 47.0.2526.106 m installed and recorded a load test scenario
with the browser. On playback the call to mtalk are horrendous. We
captured the request during our recording with the following content. From
what I've read above it would appear to be a linked issue.

) � https://mtalk.google.com/ HTTP/1.1
chrome-47.0.2526.106 mcs.android.com 5233206082636596163" 5233206082636596163* 39635815748001640802 android-48a0153497f7c3c3:
Connection: keep-alive
Host: mtalk.google.com
Content-Length: 0

[chro...@googlecode.com]

Comment #81 on issue 373181 by hugh...@gmail.com: Chromium packet storm on
port 5228
https://code.google.com/p/chromium/issues/detail?id=373181

You could also put an entry in the PAC file... That is what we are doing...