have you tried pap instead of chap on Cisco dialer?
On 10/20/10, Ian Smith <smi...@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 vt123456...@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-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
