Date: Wed, 20 Oct 2010 15:23:22 +0100 From: Paul Thornton <prt@prt.org> To: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client Message-ID: <4CBEFB5A.80704@prt.org> In-Reply-To: <4CBE0846.1090203@freebsd.org> References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 19/10/2010 22:06, Julian Elischer wrote: > Wireshark understands all the protocols in question so get packet > captures of good and > bad sessions (as similar as you can) and see what is different. > (wireshark reads > tcpdump files so it's easy to capture). As is often the case, the packets on the wire start telling the story of what is happening... still not sure about the why, but progress is being made. Thanks for that nudge. 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. 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. 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 ! In terms of the routing, the route being added as a result of the Framed-Route radius attribute does have the correct syntax. For some reason, it had failed to add the /29 route to the routing table in my logs taken yesterday - although that now works fine. That may still be a potential issue but I don't think it is relevant now. To describe what addresses are what (and two of these have changed since yesterday as I was using some that were already occasionally used elsewhere on the network): WAN IP address of router: 217.65.167.128 /32 - set by RADIUS Framed-IP-Address value. LAN subnet of router: 217.65.167.160 /29 - set by RADIUS Framed-Route value. Router's LAN interface has 217.65.167.161/29. IP address of PPPoE server's end of PPP link: 217.65.168.254 VLAN 1005 is just the access side; it has the clients attached to it and has no IP address. Everything happening on there is PPPoE only. The server has another interface which is network side that carries traffic to and from the rest of the world. > also for fun you might look at the documentation for running mpd.. I > dont' remember if it > can do a pppoe SERVER but I vaguely remember that it can. I did once try mpd in the past - I remember it being hard to find any decent documentation for it; especially around PPPoE as a server. It looks very flexible as an option so I may have another crack at it if I can't make the standard ppp work. Does anyone know of any good howto for mpd and pppoe servers? My google skills have lacked severely so far. 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? (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 > 14:40:27.741765 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 12: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 6, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 80fd 0106 000a > MPPC Option (0x12), length 6: > 0x0000: 0000 0001 > 14:40:27.741834 d8:d3:85:c1:5e:ed > 18:a9:05:db:8e:5c, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x20] unknown (0x80fd), length 12: unknown ctrl-proto (0x80fd), Conf-Reject (0x04), id 6, length 12 > encoded length 10 (=Option(s) length 6) > 0x0000: 80fd 0406 000a > MPPC Option (0x12), length 6: > 0x0000: 0000 0001 > 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 > 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 > 14:40:27.742343 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Ack (0x02), id 1, length 6 > 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 > 14:40:27.756103 18:a9:05:db:8e:5c > d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x20] unknown (0x80fd), length 18: unknown ctrl-proto (0x80fd), Term-Request (0x05), id 8, length 18 > encoded length 16 (=Option(s) length 12) > 0x0000: 80fd 0508 0010 > 14:40:27.756150 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), Term-Ack (0x06), id 8, length 6 > 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 > 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 > 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 > 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 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 > 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 > 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 > 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"] 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. Regards, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CBEFB5A.80704>