Most likely we need to update one of the baseline files, probably this one:
https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/site_tests/security_NetworkListeners/baseline.arc

The actual error:

9/29 13:12:22.214 ERROR|security_NetworkLi:0128| Unexpected network listener: chrome 127.0.0.1:fido
09/29 13:12:22.231 WARNI|security_NetworkLi:0135| Missing expected network listener: x11vnc 127.0.0.1:5900
09/29 13:12:22.250 WARNI|security_NetworkLi:0135| Missing expected network listener: x11vnc [::1]:5900

and the baseline:

https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/site_tests/security_NetworkListeners/baseline

This particular board does not have ARC++, so I'm not sure what 'fido' refers to here. Neither why the lack of x11vnc. There's a TODO there, so maybe it was fixed?

I found this CL, but nothing recent: https://chromium-review.googlesource.com/#/c/354510/

Mike posted this: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-dev/svApZGmMrXQ

Stefan, or Mike, do you know what's going on here? 

Greg, I wasn't able to find any relevant CLs in a minute of poking around, but maybe you can find which CL started causing these failures? I'm also not sure how this made it through the CQ - maybe it was chumped?

To be clear, we shouldn't be looking at baseline.arc but baseline. The boards that are failing don't have ARC++ enabled. The ARC++-enabled boards all seem to be passing (with a warning that sslh and :5037 are not open, like it expects. maybe this is a result of some changes we made recently where we need to explicitly opt-in to open those ports).

The x11vnc is just a warning and is not the reason for the failure of the test. It just means that the test has detected that there's no port open for x11vnc on those DUTs, even though x11vnc is whitelisted.
On most DUTs (including all ARC++ ones) that's expected since we no longer use X, but the TODO points to one board that could potentially still have this port open, which is why x11vnc is still whitelisted.

The real issue is the "chrome 127.0.0.1:fido" entry. The test detects that there is a port open that is not whitelisted, so it throws an error.

#4, baseline and baseline.arc are best thought of as whitelists of ports than can be open.
We allow sslh and 5037 on ARC++ DUTs as they can be open on test machines but they don't have to be. If they're not open the test throws a warning but does not fail. Same for x11vnc on non-ARC++ boards.

Not sure what the entry "chrome 127.0.0.1:fido" means. gnubby!?!

FIDO is bluetooth I think? Jeff, Vincent, do you know anything about this?

https://codereview.chromium.org/2306473002

$ grep ^fido /etc/services 
fido            60179/tcp                       # fidonet EMSI over TCP

it just means something is listening on port 60179.  it might be a stable port, or it might be a random one.  don't know if there's a way to query chrome directly to find out why it's using a specific port.

Haven't found any suspect CLs yet, but I did find unresolved Issue 513743 from over a year ago, which includes the failure:

/tmp/cbuildbotzAlt7P/test_harness/all/SimpleTestUpdateAndVerify/2_autotest_tests/results-06-security_NetworkListeners/security_NetworkListeners
07/24 04:47:32.457 ERROR|security_NetworkLi:0113| Unexpected network listener: chrome 127.0.0.1:fido

scheib@ - You've done some work in this neighborhood recently (e.g.  Issue 643013 )... any insights?

Greg: Looks like that failure was a one-off:
https://uberchromegw.corp.google.com/i/chromeos.chrome/builders/peach_pit-tot-chrome-pfq-informational

There were some other failures since then, but don't appear to be this one, and the latest build has succeeded. Maybe we should just close this bug.

i suspect it's a flake which means it might disappear now, but it can come back anytime

It's also possible there was a CL that has since gotten reverted. This test has actually been very stable historically: https://wmatrix.googleplex.com/unfiltered?tests=security_NetworkListeners

I think we can probably observe this for a few days and close it if there's no re-occurrence?

@glevin: Comment #9 already demonstrated that the 127.0.0.1:fido isn't related to the BT FIDO service.

achuith@ - I'm gardening next week as well.  I'll close it in a week if there's no relapse.

This builder had 12 straight successes yesterday and today (in-between unrelated failures), and I saw no repeat of this failure last week.  As per Comments 11 & 15, I'm closing this as an apparent one-off.