Problems with 8.1, PPPoE server, and Cisco client
Ian Smith
smithi at nimnet.asn.au
Wed Oct 20 16:39:19 UTC 2010
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
More information about the freebsd-net
mailing list