netdev - Re: ping -I eth1 ....

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 6 Nov 2010 10:42:46 +0100
From:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To:	Thomas Graf <tgraf@...radead.org>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	Thomas Graf <tgr@...radead.org>
Subject: Re: ping -I eth1 ....

Thomas Graf <tgr@...radead.org> wrote on 2010/11/05 21:31:50:
>
> On Fri, Nov 05, 2010 at 04:54:18PM +0100, Joakim Tjernlund wrote:
> > Eric Dumazet <eric.dumazet@...il.com> wrote on 2010/11/05 16:06:54:
> > >
> > > > Hopefully most of that is legacy or just plain wrong? Unless
> > > > someone can say why only test IFF_UP one should consider changing them.
> > > >
> > >
> > > Most of the places are hot path.
> > >
> > > You dont want to replace one test by four tests.
> > >
> > > _This_ would be wrong :)
> >
> > Wrong is wrong, even if it is in the hot path :)
> > Perhaps it is time define and internal IFF_OPERATIONAL flag
> > which is the sum of IFF_UP, IFF_RUNNING etc.? Tht
> > way you still get one test in the hot path and can abstract
> > what defines an operational link.
>
> You definitely don't want to have your send() call fail simply because
> the carrier was off for a few msec or the routing daemon has put a link
> down temporarly. Also, the outgoing interface looked up at routing
> decision is not necessarly the interface used for sending in the end.
> The packet may get mangled and rerouted by netfilter or tc on the way.

But do you handle the case when the link is non operational for a long time?

>
> Personally I'm even ok with the current behaviour of sendto() while the
> socket is bound to an interface but if we choose to return an error
> if the interface is down we might as well do so based on the operational
> status.

Perhaps there is a better way. This all started when pppd hung because
of ping -I <ppp interface>, then someone pulled the cable for the on the link.

This is a strace where we have two ping -I,
ping -I p1-2-1-2-2 .. and ping -I p1-2-3-2-4 ..
Notice how pppd hangs for a long time in PPPIOCDETACH
As far as I can tell this is due to ping -I has claimed the ppp interfaces
and doesn't noticed that the link is down. Ideally ping should receive
a ENODEV as soon as pppd calls PPPIOCDETACH.


   0.000908 write(0, "Connection terminated.\n", 23) = 23
     0.000481 gettimeofday({1288952770, 566048}, NULL) = 0
     0.001553 ioctl(7, PPPIOCDETACH
Message from syslogd@...zil at Fri Nov  5 11:26:20 2010 ...
Brazil kernel: unregister_netdevice: waiting for p1-2-1-2-2 to become free. Usage count = 3
Message from syslogd@...zil at Fri Nov  5 11:26:20 2010 ...
Brazil kernel: unregister_netdevice: waiting for p1-2-3-2-4 to become free. Usage count = 3
Message from syslogd@...zil at Fri Nov  5 11:26:51 2010 ...
Brazil last message repeated 3 times
, 0xbfbc3398) = 0
    66.559216 connect(9, {sa_family=AF_PPPOX, sa_data="\0\0\0\0\0\0\0\252\273\314\335\356hd"}, 30) = 0
     0.000693 close(10)                 = 0
     0.000449 close(7)                  = 0
     0.009801 close(9)                  = 0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html