Problems with 8.1, PPPoE server, and Cisco client
Alireza Torabi
alireza.torabi at gmail.com
Wed Oct 20 16:57:54 UTC 2010
have you tried pap instead of chap on Cisco dialer?
On 10/20/10, Ian Smith <smithi at nimnet.asn.au> 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
More information about the freebsd-net
mailing list