From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 16:57:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80A9106566C for ; Wed, 20 Oct 2010 16:57:54 +0000 (UTC) (envelope-from alireza.torabi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57F9B8FC0A for ; Wed, 20 Oct 2010 16:57:54 +0000 (UTC) Received: by vws1 with SMTP id 1so2190547vws.13 for ; Wed, 20 Oct 2010 09:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YTCi+Xehb70V2xQYJnKtYtbb8st7RmIu1lI9+w6+Kfk=; b=bJ4L+s0HhfI30A5a32o2qUcwCous+QUeMNT42zdE5gswC7eKPSL14UFnUp/JhHrNWy q8rM72Ig/IRb6Vg1M2AyoTb+cdYdtqomBQZSGOy+O7P43/W9YBaAUO67StuczPl1ZaE/ NbvoGZv7bRLPuYQvCVsNk7zaInZukmFEuBg1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=To1wlYfJKVwikKUwJaHacgKn1fHVzigDAoZ/onvACTfc5jllK4R3TVXZhrZAgfgPsM Gs8bKa+r7V2iNyvwhr5O7bDtfhOnw/IASIyunARHdbG0tGRPocuYB2Jzb56UuHW6DxhI 3X8q2ow1ToKnY/YNZnbhkXpFacYSxZMxcPks8= MIME-Version: 1.0 Received: by 10.229.91.77 with SMTP id l13mr6649217qcm.282.1287593873363; Wed, 20 Oct 2010 09:57:53 -0700 (PDT) Received: by 10.229.11.143 with HTTP; Wed, 20 Oct 2010 09:57:53 -0700 (PDT) In-Reply-To: <20101021024340.D9562@sola.nimnet.asn.au> References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> <20101021024340.D9562@sola.nimnet.asn.au> Date: Wed, 20 Oct 2010 17:57:53 +0100 Message-ID: From: Alireza Torabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:57:54 -0000 have you tried pap instead of chap on Cisco dialer? On 10/20/10, Ian Smith wrote: > On Wed, 20 Oct 2010, Paul Thornton wrote: > > [..] > > > With a Windows XP client (I know, it was nearby though) the following > > things happen: > > > > Server -> Client PPP CHAP Success (Welcome!! message). > > Server -> Client PPP CCP config request > > Server -> Client IPCP Config request (setting IP address of server end) > > Client -> Server PPP CCP config request > > - and they carry on here working fine - > > > > With the Cisco client, things break at this point: > > Server -> Client PPP CHAP Success (Welcome!! message). > > Server -> Client PPP CCP Config request > > Server -> Client IPCP Config Request (setting IP address of server end) > > Client -> Server Termination request > > Server -> Client Termination ack > > > > So either that CCP request or the IPCP request is upsetting the Cisco. > > My money's on IPCP or maybe LCP so far .. > > > However, even with its debugging fully on for PPP, it isn't clear why. > > Initially, my server was requesting deflate compression and VJ > > compression - so I disabled all compression options in ppp.conf but it > > made no difference. The tcpdumps were taken after compression was > disabled. > > Good idea, keeps the logging reasonable meanwhile .. > > > The cisco config being used on the WAN interface and Dialer interface > > for testing is as follows. This is an 891 and so is an Ethernet WAN > > port (no VDSL or other cable interface to add problems): > > > > interface GigabitEthernet0 > > no ip address > > ip accounting output-packets > > duplex auto > > speed auto > > pppoe enable group global > > pppoe-client dial-pool-number 1 > > ! > > interface Dialer0 > > description PPPoE dialer > > mtu 1492 > > ip address negotiated > > no ip redirects > > no ip proxy-arp > > ip accounting output-packets > > encapsulation ppp > > ip tcp adjust-mss 1452 > > dialer pool 1 > > dialer-group 1 > > ppp mtu adaptive > > ppp authentication chap callin optional > > ppp chap hostname VT123456789@vdsl01 > > ppp chap password 0 LetMeIn123 > > ! > > ! > > ip route 0.0.0.0 0.0.0.0 Dialer0 > > ! > > dialer-list 1 protocol ip permit > > ! > > Left to those who speak cisco .. > > > Here is part of the tcpdump with the XP client, starting at the CHAP > > success message. I've included quite a lot as there seems to be > > something going on with IPCP and setting DNS addresses - is this normal? > > Looks pretty normal. Omitting 'unknown ctrl-proto (0x80fd)' MPPC stuff: > > > (address ending 5e:ed is the server): > > > > > 14:40:27.733755 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 35: PPPoE [ses 0x20] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > > > 14:40:27.733764 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > > 14:40:27.733770 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 32: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x0000: 8021 0101 000a > > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x0000: d941 a8fe > > we want this address. > > > > 14:40:27.741992 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 36: IPCP, > Conf-Request (0x01), id 7, length 36 > > > encoded length 34 (=Option(s) length 30) > > > 0x0000: 8021 0107 0022 > > > IP-Addr Option (0x03), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > it's open to persuasion for all these. > > > > 14:40:27.742107 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 38: PPPoE [ses 0x20] IPCP (0x8021), length 18: IPCP, > Conf-Reject (0x04), id 7, length 18 > > > encoded length 16 (=Option(s) length 12) > > > 0x0000: 8021 0407 0010 > > > Pri-NBNS Option (0x82), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-NBNS Option (0x84), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > we don't do NBNS. > > > > 14:40:27.742559 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 12: IPCP, > Conf-Ack (0x02), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x0000: 8021 0201 000a > > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x0000: d941 a8fe > > it's happy with our IP addr. > > > > 14:40:27.756230 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Request (0x01), id 9, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 0109 0016 > > > IP-Addr Option (0x03), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Pri-DNS Option (0x81), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > > Sec-DNS Option (0x83), length 6: 0.0.0.0 > > > 0x0000: 0000 0000 > > it still needs these. > > > > 14:40:27.756316 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Nack (0x03), id 9, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 0309 0016 > > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > > 0x0000: d941 a780 > > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > > 0x0000: d941 a02a > > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > > 0x0000: ffff ffff > > so we offer it these. > > > > 14:40:27.771794 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Request (0x01), id 10, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 010a 0016 > > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > > 0x0000: d941 a780 > > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > > 0x0000: d941 a02a > > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > > 0x0000: ffff ffff > > it asks for just what we've offered, ok .. > > > > 14:40:27.779058 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE > S (0x8864), length 44: PPPoE [ses 0x20] IPCP (0x8021), length 24: IPCP, > Conf-Ack (0x02), id 10, length 24 > > > encoded length 22 (=Option(s) length 18) > > > 0x0000: 8021 020a 0016 > > > IP-Addr Option (0x03), length 6: 217.65.167.128 > > > 0x0000: d941 a780 > > > Pri-DNS Option (0x81), length 6: 217.65.160.42 > > > 0x0000: d941 a02a > > > Sec-DNS Option (0x83), length 6: 255.255.255.255 > > > 0x0000: ffff ffff > > so we ack those. Ready to roll at IPCP level. > > > And here is the similar section from the Cisco router, it all goes > > downhill quickly (address ending 5e:ed is the server): > > > > > 14:59:44.053482 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 35: PPPoE [ses 0x21] CHAP (0xc223), length 15: CHAP, > Success (0x03), id 1, Msg Welcome!! > > > 14:59:44.053491 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown > ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 > > > 14:59:44.053498 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, > Conf-Request (0x01), id 1, length 12 > > > encoded length 10 (=Option(s) length 6) > > > 0x0000: 8021 0101 000a > > > IP-Addr Option (0x03), length 6: 217.65.168.254 > > > 0x0000: d941 a8fe > > we want this IP address. > > > > 14:59:44.059344 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE > S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, > Term-Request (0x05), id 2, length 6 > > and it requests termination, that's it. Any reason the Cisco might > reject that address? It's not even being too polite about it, not even > a friendly Conf-Reject .. > > > > 14:59:44.059739 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, > Term-Ack (0x06), id 2, length 6 > > we ack its termination request. > > > > 14:59:44.060925 54:75:d0:38:ca:7a > d8:d3:85:c1:5e:ed, ethertype PPPoE > D (0x8863), length 60: PPPoE PADT [ses 0x21] > > > 14:59:44.060939 d8:d3:85:c1:5e:ed > 54:75:d0:38:ca:7a, ethertype PPPoE > D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error "session > closed"] > > dunno. > > > Many thanks for ideas, suggestions, etc. so far. I'm not well clued up > > on the inner workings of PPP so any pointers to understand the IPCP or > > CCP requests that seem to be causing the problem would be welcome. > > I suspect that the ppp log from Greeting past LCP close including LCP, > IPCP and (why not?) CCP logging with the cisco might show what's not > acceptable, and to whom .. > > cheers, Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >