Re: Problems with 8.1, PPPoE server, and Cisco client
On Tue, 9 Nov 2010, Paul Thornton wrote: Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. Unfortunately I have never seen the full ppp debug log I had initially asked for. Can't help without that. It would tell you why it didn't work. /bz -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
On 26/10/2010 18:55, Paul Thornton wrote: I've been taking another look at this after being dragged off onto other things for a few days, and hopefully have some more information that might help point in the right direction for a fix / where to debug next. On 20/10/2010 17:16, Julian Elischer wrote: 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 Cisco client does work to a Cisco router acting as a PPPoE server - I used a 891 (client) to a 3945 (server) and using an established setup that is known to work, I collected a happy tcpdump. Of course that doesn't tell us why there was such an issue with the FreeBSD ppp server and it looks very similar to me. I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. Thanks to everyone for their help with this. So here is the dump from a known good setup, IOS at both ends - starting from the CHAP success point again. This time, both ends play the game and agree amongst themselves what they will and won't do as expected (many thanks to Ian here for the commentary as to what was going on in the exchanges I have): 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, Name vt123456...@vdsl01.v 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 0.0.0.0 0x: 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) 0x: 0101 0004 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0301 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: c021 0802 000a Rejected unknown Protocol (0x8207) Rejected Packet 0x: 0101 0006 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0102 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0202 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, flags [none], proto ICMP (1), length 100) 109.71.174.50 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, flags [none], proto ICMP (1), length 100) 217.65.161.4 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 The ping here is the start of real data flowing - I used this setup for about 30 minutes of web browsing with no problems. Paul. ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. Paul. ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
On 09/11/2010 20:16, Paul Thornton wrote: Sorry for that unedited copy of the last mail to the list. Finger trouble in mail client. Must try harder! Paul. ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
On 11/9/10 12:18 PM, Paul Thornton wrote: Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. take especial care with netmasks and network definitions if you have any Paul. ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
I've been taking another look at this after being dragged off onto other things for a few days, and hopefully have some more information that might help point in the right direction for a fix / where to debug next. On 20/10/2010 17:16, Julian Elischer wrote: 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 Cisco client does work to a Cisco router acting as a PPPoE server - I used a 891 (client) to a 3945 (server) and using an established setup that is known to work, I collected a happy tcpdump. Of course that doesn't tell us why there was such an issue with the FreeBSD ppp server and it looks very similar to me. I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. Thanks to everyone for their help with this. So here is the dump from a known good setup, IOS at both ends - starting from the CHAP success point again. This time, both ends play the game and agree amongst themselves what they will and won't do as expected (many thanks to Ian here for the commentary as to what was going on in the exchanges I have): 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, Name vt123456...@vdsl01.v 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 0.0.0.0 0x: 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) 0x: 0101 0004 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0301 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: c021 0802 000a Rejected unknown Protocol (0x8207) Rejected Packet 0x: 0101 0006 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0102 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0202 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, flags [none], proto ICMP (1), length 100) 109.71.174.50 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, flags [none], proto ICMP (1), length 100) 217.65.161.4 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 The ping here is the start of real data flowing - I used this setup for about 30 minutes of web browsing with no problems. Paul. ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
On 10/19/10 10:06 PM, Ian Smith wrote: On Tue, 19 Oct 2010, Paul Thornton wrote: Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 - 217.65.167.1): File exists From memory, 'File exists' means more like 'route exists' yes in 8.x the routing code changed somewhat. it is possible it is trying to put in a route that we now already put in automatically. Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open - lcp Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
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 vt123456...@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) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: 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) 0x: 80fd
Re: Problems with 8.1, PPPoE server, and Cisco client
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 vt123456...@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) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: 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] ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
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) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: 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) 0x: 8021 0107 0022 IP-Addr Option (0x03), length 6: 0.0.0.0 0x: Pri-DNS Option (0x81), length 6: 0.0.0.0 0x: Pri-NBNS Option (0x82), length 6: 0.0.0.0 0x: Sec-DNS Option (0x83), length 6: 0.0.0.0 0x: Sec-NBNS Option (0x84), length 6: 0.0.0.0 0x: 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) 0x: 8021 0407 0010 Pri-NBNS Option (0x82), length 6: 0.0.0.0 0x: Sec-NBNS Option (0x84), length 6: 0.0.0.0 0x: 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) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: 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) 0x: 8021 0109 0016 IP-Addr Option (0x03), length 6: 0.0.0.0
Re: Problems with 8.1, PPPoE server, and Cisco client
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) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: 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) 0x: 8021 0107 0022 IP-Addr Option (0x03), length 6: 0.0.0.0 0x: Pri-DNS Option (0x81), length 6: 0.0.0.0 0x: Pri-NBNS Option (0x82), length 6: 0.0.0.0 0x: Sec-DNS Option (0x83), length 6: 0.0.0.0 0x: Sec-NBNS Option (0x84), length 6: 0.0.0.0 0x: 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) 0x: 8021 0407 0010 Pri-NBNS Option (0x82), length 6: 0.0.0.0 0x: Sec-NBNS Option (0x84), length 6: 0.0.0.0 0x: 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) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: 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
Problems with 8.1, PPPoE server, and Cisco client
Hi all, I'm hoping that someone can point me in the right direction to get enough debug to troubleshoot a very annoying connection problem with PPPoE to a Cisco. I have a freshly installed 8.1-RELEASE amd64 box with a very simple PPPoE daemon setup on it. This works fine for a test WinXP and Mac OS X client so I know that fundamentally that side of things should be OK. I have also used a similar setup (under 7.0) with all sorts of consumer routers doing PPPoE and it just works. The server I'm testing with has VLANs on top of igb interfaces, and I haven't seen any other network issues. Using a Cisco 800 series as the client, however, things start off working fine - connects up OK, authenticates, etc. but then it immediately disconnects. There is no clear error as to why the disconnect happens at either end - hence my confusion. I've tried several routers (some direct Ethernet link, some via VDSL) and have upgraded to the latest IOS in an attempt to make this work, nothing changes. Have also tried with 7.2-RELEASE in case it was an 8.X issue - again, same problem seen. Any hints to help debug this (from either end) would be much appreciated. Thanks, Paul. Info follows: FreeBSD vdsl02a 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Oct 19 14:48:21 UTC 2010 r...@vdsl01a:/usr/src/sys/amd64/compile/PPPOE-ROUTER-2 amd64 ppp.conf: default: set log Chat Command Phase#turn on some logging. See man ppp.conf enable pap#turn on chap and pap accounting enable chap allow mode direct #turn on ppp bridging disable proxy #turn on ppp proxyarping disable ipv6cp#don't currently support v6 set mru 1492 #set mru below 1500 (PPPoE MTU issue) set mtu 1492 #set mtu below 1500 (PPPoE MTU issue) set timeout 0 enable lqr echo set echoperiod 5 accept dns set dns 217.65.160.42 set radius /etc/ppp/radius.conf set ifaddr 217.65.168.254/32 # access VLAN PPPoE definitions cv1004e: set device PPPoE:vlan1004:test cv1005e: set device PPPoE:vlan1005:test The daemon is running with the following command: /usr/libexec/pppoed -P /var/run/pppoed-1005.pid -a test -l cv1005e vlan1005 The RADIUS plumbing works as expected, and the router gets past authentication and gets the correct IP address. ppp.log shows: Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Using interface: tun0 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Created in closed state Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable pap Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable chap Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable proxy Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable ipv6cp Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mru 1492 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mtu 1492 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set timeout 0 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable lqr echo Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set echoperiod 5 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: accept dns Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set dns 217.65.160.42 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set radius /etc/ppp/radius.conf Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set ifaddr 217.65.168.254/32 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: cv1005e: set device PPPoE:vlan1005:test Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: PPP Started (direct mode). Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Establish Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: closed - opening Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Link is a netgraph node Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Connected! Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: opening - carrier Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: carrier - lcp Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Authenticate Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: his = none, mine = CHAP 0x05 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE dropped (got id 1, not 2) Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE (16 bytes from vt123456...@vdsl01) Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius: Request sent Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius(auth): ACCEPT received Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: IP 217.65.167.1 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Route: 217.65.167.64/29 217.65.167.1 1 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: MTU 1492 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Netmask 255.255.255.255 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: SUCCESS Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR,
Re: Problems with 8.1, PPPoE server, and Cisco client
On 10/19/10 1:32 PM, Paul Thornton wrote: Hi all, I'm hoping that someone can point me in the right direction to get enough debug to troubleshoot a very annoying connection problem with PPPoE to a Cisco. I have a freshly installed 8.1-RELEASE amd64 box with a very simple PPPoE daemon setup on it. This works fine for a test WinXP and Mac OS X client so I know that fundamentally that side of things should be OK. I have also used a similar setup (under 7.0) with all sorts of consumer routers doing PPPoE and it just works. The server I'm testing with has VLANs on top of igb interfaces, and I haven't seen any other network issues. Using a Cisco 800 series as the client, however, things start off working fine - connects up OK, authenticates, etc. but then it immediately disconnects. There is no clear error as to why the disconnect happens at either end - hence my confusion. I've tried several routers (some direct Ethernet link, some via VDSL) and have upgraded to the latest IOS in an attempt to make this work, nothing changes. Have also tried with 7.2-RELEASE in case it was an 8.X issue - again, same problem seen. Any hints to help debug this (from either end) would be much appreciated. Thanks, Paul. Immediate things to look at: 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). 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. 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
Re: Problems with 8.1, PPPoE server, and Cisco client
On Tue, 19 Oct 2010, Paul Thornton wrote: default: set log Chat Command Phase#turn on some logging. See man ppp.conf increase the log level for your test. According to the Cisco debug log the O(ther), which would be the FreeBSD to my understanding, sends a TERMREQ and closes the connection. Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 - 217.65.167.1): File exists Not sure why that happens. Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: lcp - open Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Network Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open - lcp Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Terminate And here it goes but the missing, probably lcp, information is missing in the log due to our log level. *Oct 19 20:19:52.139: Vi2 LCP: State is Open *Oct 19 20:19:52.147: Vi2 CHAP: I SUCCESS id 1 len 13 msg is Welcome!! *Oct 19 20:19:52.147: Vi2 PPP: Phase is FORWARDING, Attempting Forward *Oct 19 20:19:52.147: Vi2 PPP: Queue CCP code[1] id[1] *Oct 19 20:19:52.147: Vi2 PPP: Queue IPCP code[1] id[1] *Oct 19 20:19:52.151: Vi2 PPP DISC: Lower Layer disconnected *Oct 19 20:19:52.151: Vi2 LCP: O TERMREQ [Open] id 2 len 4 And here it goes away. And thanks to Cisco you cannot say why either here. The line above could be a hint if you can find it but ... /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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
Re: Problems with 8.1, PPPoE server, and Cisco client
Just out of interest, Could you post the relevant Cisco configs. On 10/19/10, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Tue, 19 Oct 2010, Paul Thornton wrote: default: set log Chat Command Phase#turn on some logging. See man ppp.conf increase the log level for your test. According to the Cisco debug log the O(ther), which would be the FreeBSD to my understanding, sends a TERMREQ and closes the connection. Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 217.65.168.254 - 217.65.167.1): File exists Not sure why that happens. Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: lcp - open Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Network Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: deflink: open - lcp Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: bundle: Terminate And here it goes but the missing, probably lcp, information is missing in the log due to our log level. *Oct 19 20:19:52.139: Vi2 LCP: State is Open *Oct 19 20:19:52.147: Vi2 CHAP: I SUCCESS id 1 len 13 msg is Welcome!! *Oct 19 20:19:52.147: Vi2 PPP: Phase is FORWARDING, Attempting Forward *Oct 19 20:19:52.147: Vi2 PPP: Queue CCP code[1] id[1] *Oct 19 20:19:52.147: Vi2 PPP: Queue IPCP code[1] id[1] *Oct 19 20:19:52.151: Vi2 PPP DISC: Lower Layer disconnected *Oct 19 20:19:52.151: Vi2 LCP: O TERMREQ [Open] id 2 len 4 And here it goes away. And thanks to Cisco you cannot say why either here. The line above could be a hint if you can find it but ... /bz -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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
