Re: [PATCH] pppoe: Use workqueue to die properly when a PADT is received

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(Cc: linux-ppp@xxxxxxxxxxxxxxx, mostrows@xxxxxxxxx)

Hello!

Simon Farnsworth schrieb am Thu, 19 Feb 2015 21:24:28 +0000:

When a PADT frame is received, the socket may not be in a good state to
close down the PPP interface. The current implementation handles this by
simply blocking all further PPP traffic, and hoping that the lack of traffic
will trigger the user to investigate.

Use schedule_work to get to a process context from which we clear down the
PPP interface, in a fashion analogous to hangup on a TTY-based PPP
interface. This causes pppd to disconnect immediately, and allows tools to
take immediate corrective action.

Tested-by: Christoph Schulz <develop@xxxxxxxxxx>

I tested your patch von top of 3.14.33 and 3.18.7 together with a slightly modified pppd based on Debian's pppd-2.4.6-3 (which is almost identical to pppd 2.4.7). The client now indeed receives PADT feedback immediately. Closing a PPPoE connection on the server side

Feb 20 16:45:44 swing local2.notice pppoe-server-wrapper[20154]: circ4: pppoe-server died with exit code 0, cleaning up

leads to immediate hangup on the client side:

Feb 20 16:45:44 sandbox local2.notice pppd[539]: Modem hangup

Formerly, the LCP echo timeout had to be reached. On the server side:

Feb 20 14:56:53 swing local2.notice pppoe-server-wrapper[12744]: circ4: pppoe-server died with exit code 0, cleaning up

On the client side:

Feb 20 14:57:01 sandbox local2.info pppd[15575]: No response to 2 echo-requests Feb 20 14:57:01 sandbox local2.notice pppd[15575]: Serial link appears to be disconnected.

Note that the short detection of the terminated link (~ 8 s) stems from very aggressive LCP echo settings (lcp-echo-interval "3", lcp-echo-failure "2"). Typically, these timeouts are much larger to accomodate for bad links. Often the client recognizes a dead link only after two to three minutes (lcp-echo-interval "30", lcp-echo-failure "5").

However, note also that your patch causes pppd (or rather the rp-pppoe plugin) to wonder about the socket closed by the kernel:

Feb 20 16:45:44 sandbox local2.err pppd[539]: Failed to disconnect PPPoE socket: 114 Operation already in progress

I don't fully understand the code there; it seems that the plugin *connects* the PPPoE session socket in order to *disconnect* it:

static void
PPPOEDisconnectDevice(void)
{
    struct sockaddr_pppox sp;

    sp.sa_family = AF_PPPOX;
    sp.sa_protocol = PX_PROTO_OE;
    sp.sa_addr.pppoe.sid = 0;
    memcpy(sp.sa_addr.pppoe.dev, conn->ifName, IFNAMSIZ);
    memcpy(sp.sa_addr.pppoe.remote, conn->peerEth, ETH_ALEN);
    if (connect(conn->sessionSocket, (struct sockaddr *) &sp,
                sizeof(struct sockaddr_pppox)) < 0)
        error("Failed to disconnect PPPoE socket: %d %m", errno);
    close(conn->sessionSocket);
    /* don't send PADT?? */
    if (conn->discoverySocket >= 0)
        close(conn->discoverySocket);
}


Regards,
--
Christoph Schulz

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




[Index of Archives]     [Linux Audio Users]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux