Kill socket for certain routes

[Martin Husemann]

Hi folks,

PR kern/35196 discusses an issue with connected TCP sockets where the local
address becomes "permantently" invalid - i.e. a ppp interface that
disconnects and on reconnect gets a new address.

Should we

(a) add a timeout to drop such connections after a reasonable time if
the local address they are bound to does not become valid again?
(b) add a manual way to kill such sockets, for example by an extension
of the route(8) command?

Is there some easy way to stop the kernel automatically from sending packets
with a "currently" not valid local address? Either by just dropping the packets
or leaving them queueed?

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[SODA Noriyuki]

Post by Martin Husemann

On Fri, 8 Dec 2006 11:18:35 +0100,

Should we
(a) add a timeout to drop such connections after a reasonable time if
the local address they are bound to does not become valid again?

You mean by default?
If so, I object to do so.
Current behavior is rather useful in some cases.
If one needs automatic timeout, SO_KEEPALIVE does the trick.

[Martin Husemann]

Post by SODA Noriyuki
You mean by default?

I won't fight for the default, but it needs to be configurable, of course.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by SODA Noriyuki

Post by Martin Husemann

On Fri, 8 Dec 2006 11:18:35 +0100,

Should we
(a) add a timeout to drop such connections after a reasonable time if
the local address they are bound to does not become valid again?

You mean by default?
If so, I object to do so.
Current behavior is rather useful in some cases.
If one needs automatic timeout, SO_KEEPALIVE does the trick.

It would be nice if we could make SO_KEEPALIVE more useful by allowing
the user to change the period.

We should not add a timeout to drop connections. Instead we should provide
a way for the user to drop them, like tcpdrop on OpenBSD and the patch in

http://users.ece.gatech.edu/~dheeraj/netbsd.html

I don't particularly like the sysctl interface, but I don't have a better
suggestion. In my opinion we should add it.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Christos Zoulas
We should not add a timeout to drop connections. Instead we should provide
a way for the user to drop them, like tcpdrop on OpenBSD and the patch in
http://users.ece.gatech.edu/~dheeraj/netbsd.html
I don't particularly like the sysctl interface, but I don't have a better
suggestion. In my opinion we should add it.

This would be a very nice general capability, though "socketdrop" (one
might want to drop UDP sockets bound to the vanished address etc.)
might be a more general capability.

Perry


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Perry E. Metzger

Post by Christos Zoulas
We should not add a timeout to drop connections. Instead we should provide
a way for the user to drop them, like tcpdrop on OpenBSD and the patch in
http://users.ece.gatech.edu/~dheeraj/netbsd.html
I don't particularly like the sysctl interface, but I don't have a better
suggestion. In my opinion we should add it.

This would be a very nice general capability, though "socketdrop" (one
might want to drop UDP sockets bound to the vanished address etc.)
might be a more general capability.

The UDP bound problem probably needs fixing in the daemons because
some of them might not be prepared to deal with this kind of failure.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Perry E. Metzger]

Post by Christos Zoulas

Post by Perry E. Metzger
This would be a very nice general capability, though "socketdrop" (one
might want to drop UDP sockets bound to the vanished address etc.)
might be a more general capability.

The UDP bound problem probably needs fixing in the daemons because
some of them might not be prepared to deal with this kind of failure.

That's fine -- build the tool, and if it doesn't work in some
instances that is okay. Better to let the user have a general capability.

Perry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Christos Zoulas

Post by Perry E. Metzger
This would be a very nice general capability, though "socketdrop" (one
might want to drop UDP sockets bound to the vanished address etc.)
might be a more general capability.

The UDP bound problem probably needs fixing in the daemons because
some of them might not be prepared to deal with this kind of failure.

Can we bring them into a state where it always returns EHOSTUNREACH?
That is an error a daemon is expected to deal with and the logic
equivalent for many of this cases.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Fri, 8 Dec 2006 22:17:48 +0000 (UTC)

Post by Christos Zoulas

Post by Perry E. Metzger

Post by Christos Zoulas
We should not add a timeout to drop connections. Instead we should
provide a way for the user to drop them, like tcpdrop on OpenBSD
and the patch in
http://users.ece.gatech.edu/~dheeraj/netbsd.html
I don't particularly like the sysctl interface, but I don't have a
better suggestion. In my opinion we should add it.

This would be a very nice general capability, though
"socketdrop" (one might want to drop UDP sockets bound to the
vanished address etc.) might be a more general capability.

The UDP bound problem probably needs fixing in the daemons because
some of them might not be prepared to deal with this kind of failure.

How about returning the same error that an ICMP ICMP_UNREACH_PORT
returns? (It's a particular case of Destination Unreachable).



--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bill Studenmund]

Post by Steven M. Bellovin
On Fri, 8 Dec 2006 22:17:48 +0000 (UTC)

Post by Christos Zoulas

Post by Perry E. Metzger
This would be a very nice general capability, though
"socketdrop" (one might want to drop UDP sockets bound to the
vanished address etc.) might be a more general capability.

The UDP bound problem probably needs fixing in the daemons because
some of them might not be prepared to deal with this kind of failure.

How about returning the same error that an ICMP ICMP_UNREACH_PORT
returns? (It's a particular case of Destination Unreachable).

If I understand things right, the problem is that we have a server
listening on bound sockets. Are servers used to getting ICMP_UNREACH_PORT
on the bound socket? On a send, yes, they should understand that! But I
didn't think many of them would be expecting an error once bind()
succeeded.

To be honest, I think TCP daemons still have this problem. If the daemon
is configured to bind to specific addresses, it has to know when they
change. Then it can redo the binding process.

Take care,

Bill

[Steven M. Bellovin]

On Fri, 8 Dec 2006 11:18:35 +0100

Post by Martin Husemann
Hi folks,
PR kern/35196 discusses an issue with connected TCP sockets where the
local address becomes "permantently" invalid - i.e. a ppp interface
that disconnects and on reconnect gets a new address.
Should we
(a) add a timeout to drop such connections after a reasonable time if
the local address they are bound to does not become valid again?
(b) add a manual way to kill such sockets, for example by an
extension of the route(8) command?
Is there some easy way to stop the kernel automatically from sending
packets with a "currently" not valid local address? Either by just
dropping the packets or leaving them queueed?

I have a similar need. In particular, I have an EVDO wireless card
which is less happy -- i.e., it often drops the call -- if it sees an
outbound packet with an invalid source address.

What I'd really like is an ifconfig or sysctl option preventing a
packet from leaving an interface if the source address doesn't match.
Since that doesn't exist, my ppp-up and ppp-down scripts manipulate my
pf or ipf filters to do the same thing.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Steven M. Bellovin
I have a similar need. In particular, I have an EVDO wireless card
which is less happy -- i.e., it often drops the call -- if it sees an
outbound packet with an invalid source address.

Source address as in MAC address or source address as in IP address?

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Fri, 08 Dec 2006 14:26:46 +0100

Post by Joerg Sonnenberger

Post by Steven M. Bellovin
I have a similar need. In particular, I have an EVDO wireless card
which is less happy -- i.e., it often drops the call -- if it sees
an outbound packet with an invalid source address.

Source address as in MAC address or source address as in IP address?

Source IP address.

EVDO is a CDMA cellular technology. My card shows up as ucom0; I set
up a PPP connection to the provider's network. (My understanding is
that PPP is actually terminated by the card, which then speaks
something else over the wireless link, but that's not really relevant
here.) Sometimes, the connection will drop, especially if I use the
card from a moving train (which is, in fact, how I'm sending this note;
I'm on my way from New Jersey to Washington, DC). When that happens, I
have to redial and I get a different source address. (The other end
gets *very* unhappy if I configure pppd to ask for my old IP address.)




--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Steven M. Bellovin
I have a similar need. In particular, I have an EVDO wireless card
which is less happy -- i.e., it often drops the call -- if it sees an
outbound packet with an invalid source address.
What I'd really like is an ifconfig or sysctl option preventing a
packet from leaving an interface if the source address doesn't match.
Since that doesn't exist, my ppp-up and ppp-down scripts manipulate my
pf or ipf filters to do the same thing.

But what you want really is mostly a firewall feature. I can see an
ifconfig flag to say 'only pass packets matching my src addr', though.
That would make things easier.