New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 669328 link

Starred by 1 user
Status: Archived
Owner:
█ ejcaruso@chromium.org
Last visit 15 days ago
Closed: Dec 2016
Cc:
mnissler@chromium.org
█ kirtika@chromium.org
█ cernekee@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

shill: prevent crashes in cases where remote breaks connection

Project Member Reported by ejcaruso@chromium.org, Nov 29 2016 
Currently, when e.g. RTNL handlers in shill call into Sockets::Send and Sockets::SendTo, we don't pass any flags. This means that if we try to write bytes to a connection that the other end has broken, we're going to eat SIGPIPE and then shill will abort.

We would rather just return an error and log the EPIPE since remote actors shouldn't be able to crash the shill process.

Comment 1 by kirtika@chromium.org, Nov 29 2016 

correct me if I am wrong - the RTNL connection is typically to the driver in the kernel? Is there a graceful reason why the other end of the connection would break? (maybe the driver switches sockets or something). 
If not, might this indicate that the driver isn't alive (and we have a lot of those bugs in the field, where the wifi interface is not present), and is probably a different problem?

Comment 2 by mnissler@chromium.org, Nov 29 2016 

I think RTNL is a bad example. Shill actually has sockets open that are connected to network services, it's arguably bad if the peer could crash shill by closing the connection at the wrong time.

Comment 3 by ejcaruso@chromium.org, Nov 29 2016 

Ah, you're right. This does also happen in a VPN driver, though.

Comment 4 by ejcaruso@chromium.org, Dec 5 2016

Status: Fixed (was: Started)
CL landed: https://chromium-review.googlesource.com/c/414211/

Marking fixed.

Comment 5 by dchan@google.com, Mar 4 2017

Labels: VerifyIn-58

Comment 6 by dchan@google.com, Apr 17 2017

Labels: VerifyIn-59

Comment 7 by dchan@google.com, May 30 2017

Labels: VerifyIn-60

Comment 8 by dchan@chromium.org, Aug 1 2017

Labels: VerifyIn-61

Comment 9 by dchan@chromium.org, Oct 14 2017

Status: Archived (was: Fixed)
►

Sign in to add a comment