Unclear if broadcast sockets are enabled on ChromeOS.

Sadly, cannot view the logs (expired?). @reporter: Can you provide more details?

Sorry about that. Here's a more recent build:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/chromeos-amd64-generic-rel-vm-tests/3859

And if that expires too, you can always pick a recent build on the fyi bot where the test is running & always failing in the same way:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/chromeos-amd64-generic-rel-vm-tests

The bot is running tests in cros VMs. I'm not sure what a broadcast socket is, but perhaps they're indeed not relevant for chromeos environments?

Ah, thanks for the FYI links :)

I'm away from my ChromeOS devices, but do you know offchance if they have a default route & network? From the log it looks like they should (since you're SSHing it), but maybe it's an artifact of the QEMU setup?

We disable this test on other platforms dependent on config - https://cs.chromium.org/chromium/src/net/socket/udp_socket_unittest.cc?rcl=d6a9497984526d151d178bfe8ec9dd1b1c84597c&l=292 - but it'd require a bit more CrOS experience to know. Since the logs aren't showing where it's hanging, it'd be some printf-debugging / stepping through with a debugger.

[bpastene]:  Don't suppose you could respond to comment #4?

Ah, missed that; sry

Re #4: Yeah, that's correct. It's a QEMU VM with a default route bridged to the host + a port on the host forwarded to the ssh port in the VM. (You can see the qemu setup here if it helps:
https://codesearch.chromium.org/chromium/src/third_party/chromite/scripts/cros_vm.py?rcl=d81364a25e1e01848eddbd45a2e5fb2b9598bbb8&l=303)

I'm no stranger to gdb'ing tests in the VM, so I ran a quick trace and it looks like this is the line hanging:
https://codesearch.chromium.org/chromium/src/net/socket/udp_socket_unittest.cc?rcl=d544d1bebcb21e0f0a7bceaf36776d1cace5c33c&l=329

Not sure what that indicates; I didn't see anything amiss before it got to that point

The QEMU VM is using user-mode networking i.e. slirp [1]. As far as I can see it doesn't handle broadcasts except for bootp.

The test itself is now disabled on ChromeOS.

Do we have a configuration where we run net_unittests on real Chrome OS hardware?

[1] https://git.qemu.org/?p=qemu.git;a=tree;f=slirp;hb=HEAD

Assigning to myself until we have a way forward.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/125e3706552dac87ba77175c5f277cb84edc4d7b

commit 125e3706552dac87ba77175c5f277cb84edc4d7b
Author: Asanka Herath <asanka@chromium.org>
Date: Fri Aug 17 02:13:26 2018

[net] Update bug annotation for disabled LocalBroadcast test.

Bug:  852590 
Change-Id: I78e5723c29974aa43b48e1559a258c5830a7d220
Reviewed-on: https://chromium-review.googlesource.com/1178809
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583939}
[modify] https://crrev.com/125e3706552dac87ba77175c5f277cb84edc4d7b/net/socket/udp_socket_unittest.cc

> Do we have a configuration where we run net_unittests on real Chrome OS hardware?

Not yet, but I'm working on that in bug 866062 (won't be anytime soon)

Cool.

So there are two things of concern here:

1. Slirp is a pretty quirky stack. We shouldn't be banking on the correctness of Chrome's code based on tests passing against it. However we should fix tests that fail against it since running our network stack under QEMU with Slirp is a perfectly valid configuration.

2. This test and the corresponding PPAPI tests[1] send a broadcast packet on the default route -- likely a physical interface -- during testing. It also listens on all interfaces on a fixed port for the broadcasted packet. This is not great behavior for a unittest. And not just because the test could pass if the same test was running on another host on the same broadcast domain.

   We don't have good system level tests for platforms other than Android / ChromeOS. Arguably, the VM tests with their captive networks are perhaps the only places where this kind of test should run.

Until such time we have a framework for system level tests, I'm of the opinion that this set of tests shouldn't be run by default :-(.

So we have a couple of options here:

1. Remove these tests altogether and never re-add them because nobody's going to do the work.

2. Keep them as-is. They've provided valuable test coverage so far, and nobody's complained about seeing mysterious broadcast UDP packets saying "first message" and "second message" on their networks.

In the case of 2. we should try to re-enable on Chrome OS on platforms other than the QEMU VMs with Slirp.

mmenke: WDYT?

[1]: PPAPI UDP socket broadcast tests use the same pattern. https://cs.chromium.org/chromium/src/ppapi/tests/test_udp_socket.cc?rcl=26cd0cc920a31e2f6aea430d51a33114b8c8593d&l=253 . Extensions should have a test with parallel behavior but it appears the corresponding extensions API is untested (?).

I'm not sure we want to just disable every broadcast test we have - the PPAPI integration tests, in particular, seem useful.  That having been said, sending real broadcasts does seem pretty concerning.  Looks like sending broadcast packets to 127.255.255.255 may work on some platforms?

If there were only unit tests, I'd tend to favor removing the tests.

(Are we still waiting on logs from comment #2, or should the Needs-Feedback label get removed? Sounds like we know what's going on?)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/596e9d8808f1553d9a1ec147681293f821a2976d

commit 596e9d8808f1553d9a1ec147681293f821a2976d
Author: Asanka Herath <asanka@chromium.org>
Date: Thu Oct 04 20:03:26 2018

[net/socket/udp] Broadcast on loopback instead of all interfaces.

The loopback test was broadcasting on all available interfaces and also
listening on all interfaces for a message in order to verify that the
broadcast flag is correctly set. This is not good. Stop doing that.

Instead, this change switches the test so that it only broadcasts on the
loopback interface. Unfortunately, listening on 127.0.0.1 doesn't work
for receiving braodcast messages, so the test still listens on all
interfaces.

Bug:  852590 
Change-Id: I728251dcd13d06f67c0cf4db89aa07918179c323
Reviewed-on: https://chromium-review.googlesource.com/c/1262596
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596814}
[modify] https://crrev.com/596e9d8808f1553d9a1ec147681293f821a2976d/net/socket/udp_socket_unittest.cc