Date: Wed, 20 Oct 2010 09:16:45 -0700 From: Julian Elischer <julian@freebsd.org> To: Paul Thornton <prt@prt.org> Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client Message-ID: <4CBF15ED.6080606@freebsd.org> In-Reply-To: <4CBEFB5A.80704@prt.org> References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/20/10 7:23 AM, Paul Thornton wrote: > 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 > ! > > > > > > 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): > [...] > And here is the similar section from the Cisco router, it all goes > downhill quickly (address ending 5e:ed is the server): > have you tried to connect this cisco router to anything else pppoe? (take it home and make it connect to your ISP for example?) The command from the server to set an address seems ok so I wonder if there is some setting on the cisco that doesn't like it. Unfortunately, despite having worked for cisco, my IOS foo is pretty weak. >> 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"] >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CBF15ED.6080606>