Re: Unable to login with PPPoE (2.10-RELEASE x86)
Ach - I meant '-s' 1492 not '-p' doh But yeah - this is only meaningful if the different routes are taken into consideration - e.g. network(ip)[router](ip)network(ip)[router](ip)network ... e.g. if the don't fragment bit is set and the MTU mismatches the ping will / won't fit 'through the pipe' where network is the pipe - but this can generally come later after you can 100% ping the remote end of the tunnel - so step #1 is verifying the remote connection simply to the other end of the pppoe link. As I remember, the mtu has to be 1492 because of encapsulating an extra frame for the ethernet layer so 1500 (standard IP? payload size) - 8 (ethernet header) = 1492 Unfortunately without knowing the local/remote ends of the PPP link tunnel it's hard to tell what's going on here - Your previous 'ifconfig' output didn't seem to show an active tun device - and the log attached doesn't seem to match the IP you're pinging - so I'm not clear what the pings are showing here.. Jul 7 04:24:05 aquina ppp[337]: tun0: IPCP: myaddr 84.62.131.143 hisaddr = 84.62.128.1 the tun device should look something somewhat like this: (happens to be from OpenBSD because thats where I have a running tun device handy - but it's pretty close on dragonfly) tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500 priority: 0 groups: tun egress status: active inet 1.2.3.4 -- 1.2.3.1 netmask 0x so if it doesn't have the 'UP' and the inet 1234 - 1231 it's most likely a ppp configuration issue - though your log does appear to be negotiating properly. if it *does* have the local/remote IP's, it's probably a routing or MTU issue. First step would be to ping the 'remote' address. hope this helps more cheers On 07/07/11 12:30, Georg Bege wrote: Hi I just tried your MTU/MRU suggestion, but I doubt it has anything to do with that. I commented set mru out, also adjusted a lil' bit on the config. However you'll see that within my ppp.log there's a warning that mru setting will be adjusted to 1492 as well. ---snip- root@aquina ~ ping -p 1500 84.63.152.118 PATTERN: 0x1500 PING 84.63.152.118 (84.63.152.118): 56 data bytes 64 bytes from 84.63.152.118: icmp_seq=0 ttl=64 time=0.099 ms 64 bytes from 84.63.152.118: icmp_seq=1 ttl=64 time=0.085 ms 64 bytes from 84.63.152.118: icmp_seq=2 ttl=64 time=0.084 ms 64 bytes from 84.63.152.118: icmp_seq=3 ttl=64 time=0.082 ms 64 bytes from 84.63.152.118: icmp_seq=4 ttl=64 time=0.084 ms 64 bytes from 84.63.152.118: icmp_seq=5 ttl=64 time=0.089 ms 64 bytes from 84.63.152.118: icmp_seq=6 ttl=64 time=0.085 ms ^C --- 84.63.152.118 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.082/0.087/0.099/0.005 ms ---snip- ---snip- root@aquina ~ ping -p 1500 84.63.128.1 PATTERN: 0x1500 PING 84.63.128.1 (84.63.128.1): 56 data bytes ^C --- 84.63.128.1 ping statistics --- 34 packets transmitted, 0 packets received, 100.0% packet loss ---snip- ---snip- root@aquina ~ ping -p 1492 84.63.152.118 PATTERN: 0x1492 PING 84.63.152.118 (84.63.152.118): 56 data bytes 64 bytes from 84.63.152.118: icmp_seq=0 ttl=64 time=0.101 ms 64 bytes from 84.63.152.118: icmp_seq=1 ttl=64 time=0.086 ms 64 bytes from 84.63.152.118: icmp_seq=2 ttl=64 time=0.081 ms 64 bytes from 84.63.152.118: icmp_seq=3 ttl=64 time=0.085 ms 64 bytes from 84.63.152.118: icmp_seq=4 ttl=64 time=0.086 ms 64 bytes from 84.63.152.118: icmp_seq=5 ttl=64 time=0.083 ms 64 bytes from 84.63.152.118: icmp_seq=6 ttl=64 time=0.083 ms ^C --- 84.63.152.118 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.081/0.086/0.101/0.006 ms ---snip- ---snip- root@aquina ~ ping -D -p 1492 84.63.128.1 PATTERN: 0x1492 PING 84.63.128.1 (84.63.128.1): 56 data bytes ^C --- 84.63.128.1 ping statistics --- 35 packets transmitted, 0 packets received, 100.0% packet loss ---snip- As you can see, no change - whether options I use, it wont matter much. Im also going to paste my updated ppp.conf again: ---snip- # ppp.conf (PPPoE) default: set log Phase Chat LCP IPCP CCP tun command enable lqr disable dns disable ipv6cp set mtu 1492 arcor: set speed sync set device PPPoE:re0 set authname *somebody* set authkey *secret* set ifaddr 10.0.0.1/0 10.0.0.2/0 ---snip- On behalf of someone within #dragonflybsd @ efnet I moved the routing rules to ppp.linkup (he had it
Re: Unable to login with PPPoE (2.10-RELEASE x86)
Hi I've to say that I've got it to work finally! I was playing with it yesterday evening, and suddenly it work - Im unsure if it was a typo or whatever - really dont get it. But its okay now! Thanks for your help. cheers Georg On Fri, 2011-07-08 at 10:18 -0500, Chris Turner wrote: Ach - I meant '-s' 1492 not '-p' doh But yeah - this is only meaningful if the different routes are taken into consideration - e.g. network(ip)[router](ip)network(ip)[router](ip)network ... e.g. if the don't fragment bit is set and the MTU mismatches the ping will / won't fit 'through the pipe' where network is the pipe - but this can generally come later after you can 100% ping the remote end of the tunnel - so step #1 is verifying the remote connection simply to the other end of the pppoe link. As I remember, the mtu has to be 1492 because of encapsulating an extra frame for the ethernet layer so 1500 (standard IP? payload size) - 8 (ethernet header) = 1492 Unfortunately without knowing the local/remote ends of the PPP link tunnel it's hard to tell what's going on here - Your previous 'ifconfig' output didn't seem to show an active tun device - and the log attached doesn't seem to match the IP you're pinging - so I'm not clear what the pings are showing here.. Jul 7 04:24:05 aquina ppp[337]: tun0: IPCP: myaddr 84.62.131.143 hisaddr = 84.62.128.1 the tun device should look something somewhat like this: (happens to be from OpenBSD because thats where I have a running tun device handy - but it's pretty close on dragonfly) tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500 priority: 0 groups: tun egress status: active inet 1.2.3.4 -- 1.2.3.1 netmask 0x so if it doesn't have the 'UP' and the inet 1234 - 1231 it's most likely a ppp configuration issue - though your log does appear to be negotiating properly. if it *does* have the local/remote IP's, it's probably a routing or MTU issue. First step would be to ping the 'remote' address. hope this helps more cheers On 07/07/11 12:30, Georg Bege wrote: Hi I just tried your MTU/MRU suggestion, but I doubt it has anything to do with that. I commented set mru out, also adjusted a lil' bit on the config. However you'll see that within my ppp.log there's a warning that mru setting will be adjusted to 1492 as well. ---snip- root@aquina ~ ping -p 1500 84.63.152.118 PATTERN: 0x1500 PING 84.63.152.118 (84.63.152.118): 56 data bytes 64 bytes from 84.63.152.118: icmp_seq=0 ttl=64 time=0.099 ms 64 bytes from 84.63.152.118: icmp_seq=1 ttl=64 time=0.085 ms 64 bytes from 84.63.152.118: icmp_seq=2 ttl=64 time=0.084 ms 64 bytes from 84.63.152.118: icmp_seq=3 ttl=64 time=0.082 ms 64 bytes from 84.63.152.118: icmp_seq=4 ttl=64 time=0.084 ms 64 bytes from 84.63.152.118: icmp_seq=5 ttl=64 time=0.089 ms 64 bytes from 84.63.152.118: icmp_seq=6 ttl=64 time=0.085 ms ^C --- 84.63.152.118 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.082/0.087/0.099/0.005 ms ---snip- ---snip- root@aquina ~ ping -p 1500 84.63.128.1 PATTERN: 0x1500 PING 84.63.128.1 (84.63.128.1): 56 data bytes ^C --- 84.63.128.1 ping statistics --- 34 packets transmitted, 0 packets received, 100.0% packet loss ---snip- ---snip- root@aquina ~ ping -p 1492 84.63.152.118 PATTERN: 0x1492 PING 84.63.152.118 (84.63.152.118): 56 data bytes 64 bytes from 84.63.152.118: icmp_seq=0 ttl=64 time=0.101 ms 64 bytes from 84.63.152.118: icmp_seq=1 ttl=64 time=0.086 ms 64 bytes from 84.63.152.118: icmp_seq=2 ttl=64 time=0.081 ms 64 bytes from 84.63.152.118: icmp_seq=3 ttl=64 time=0.085 ms 64 bytes from 84.63.152.118: icmp_seq=4 ttl=64 time=0.086 ms 64 bytes from 84.63.152.118: icmp_seq=5 ttl=64 time=0.083 ms 64 bytes from 84.63.152.118: icmp_seq=6 ttl=64 time=0.083 ms ^C --- 84.63.152.118 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.081/0.086/0.101/0.006 ms ---snip- ---snip- root@aquina ~ ping -D -p 1492 84.63.128.1 PATTERN: 0x1492 PING 84.63.128.1 (84.63.128.1): 56 data bytes ^C --- 84.63.128.1 ping statistics --- 35 packets transmitted, 0 packets received, 100.0% packet loss ---snip- As you can see, no change - whether options I use, it wont matter much. Im also going to paste my updated ppp.conf again: ---snip- # ppp.conf (PPPoE)
Re: Unable to login with PPPoE (2.10-RELEASE x86)
On 07/08/11 11:15, Georg Bege wrote: Hi I've to say that I've got it to work finally! I was playing with it yesterday evening, and suddenly it work - Im unsure if it was a typo or whatever - really dont get it. But its okay now! Nice! I forgot to warn about the 'dreaded ppp.conf indenting' issue so maybe that was it :D care to paste the ppp.conf back so any errant googlers are satisfied in the future? cheers, - Chris
Re: Unable to login with PPPoE (2.10-RELEASE x86)
Hello Sadly this is not working, in fact the default route *does* get written. My route show output looks like this: The funny thing is, addresses do get resolved (if I dont have any default) I dont get anything (no dns/resolving). But ping doesnt get through nor any kind of connection. ---snip- Routing tables Internet: Destination Gateway Flags default 84.63.128.1 UG dslb-084-063-128-001.pools.arcor 84.63.128.140 UH localhost127.0.0.1 UH 192.168.2link#8 U dns19.arcor-ip.de84.63.128.1 UGH Internet6: Destination Gateway Flags localhostlocalhost UH fe80::%re0 link#1 U fe80::beae:c5ff:feb7:a940%re0bc:ae:c5:b7:a9:40 UH fe80::%lo0 fe80::1%lo0 U fe80::1%lo0 link#5 UH fe80::%wlan0 link#8 U fe80::da5d:4cff:feba:d47a%wlan0 d8:5d:4c:ba:d4:7a UH ff01:: localhost U ff02::%re0 link#1 U ff02::%lo0 localhost U ff02::%wlan0 link#8 U ff02::%tun0 fe80::beae:c5ff:feb7:a940%tun0 U ---snip- cheers Georg Am Donnerstag, den 07.07.2011, 13:03 +0900 schrieb YONETANI Tomokazu: Hi. On Thu, Jul 07, 2011 at 04:47:23AM +0200, Georg Bege wrote: I actually never had a lot of issue regarding this, but now Im running out of ideas. Whatever I try Im not able to use PPPoE to login to my internet (which is essential for the purpose of this box). I seem to get an IP but I cannot ping anything (eg. no routing?) ppp.log: Jul 7 04:24:05 aquina ppp[337]: tun0: IPCP: myaddr 84.62.131.143 hisaddr = 84.62.128.1 Jul 7 04:24:05 aquina ppp[337]: tun0: Warning: 84.62.128.1: Change route failed: errno: No such process Try this command to replace the current default route to hisaddr above # route change default 84.62.128.1 If ping works after this, change the last line in ppp.conf from add default HISADDR to add! default HISADDR Cheers. -- Georg Bege ther...@ninth-art.de !DSPAM:4e15736c844721718360748!
Re: Unable to login with PPPoE (2.10-RELEASE x86)
On Thu, Jul 07, 2011 at 10:50:46AM +0200, Georg Bege wrote: The funny thing is, addresses do get resolved (if I dont have any default) I dont get anything (no dns/resolving). But ping doesnt get through nor any kind of connection. Do I have this correct: - without the route assignment, dns lookups are working - with the route assignment, dns lookups are not working? I didn't actually see the address assignment in your ifconfig output - was the ppp0 device output truncated or ? If I am correct, it sounds like perhaps some data is flowing but not all - which could indicate an MTU mismatch Though I don't have direct pppoe experience on FreeBSD/DragonFly - I did once use the OpenBSD implementation (which uses a userspace daemon rather than the netgraph device) - I had some issues with the mtu matchup which caused some issues - My archived configuration had : set mtu max 1492 # set mru max 1492 so you might try commenting out the mru portion? What does the ping of e.g. the remote gateway, show exactly? host unreachable or something else? Its been a while since I debugged an MTU mismatch but iirc if you can ping the gateway but not something else (like say your upstream dns server ) and the routes look ok (and tcpdump is showing the packets flowing out ) you can set some combination of ping -p and -D to detect the mismatch again, IIRC, I think e.g.: ping -p 1500 routed IP? gateway IP? ping -p 1492 routed IP? gateway IP? - works ping -D -p 1492 routed IP? gateway IP? - works ping -D -p 1500 routed IP? gateway IP? - fails or something like this - I'd verify what I'm saying with some searching :D or maybe someone can chime in? that wouldn't explain why the config is working on one but not the other, though I do recall that some of the default settings might be different w/r/t freebsd, etc. in ppp from previous adventures with PPP (using GSM devices) good luck! Cheers, - Chris
Re: Unable to login with PPPoE (2.10-RELEASE x86)
Thanks for your ideas. Well no without any route assignment - of course I dont get anything. With the default route assignment which gets set despite the error message I can resolve hosts but cant ping anything. I'll consider the mtu/mru settings - fact is that I prior to this didnt have set them at all and I got a warning saying they get adjusted 1500. But maybe it is as you say, that I have to adjust mtu but not mru. I have to say Im not really skilled with the internals of PPP(oE). If I do ping for now I dont get anything, no error message - maybe a timeout but I didnt wait that long. I'll also check with your ping cmd suggestions, cant check now - I'll do so in the evening. cheers Georg On Thu, 2011-07-07 at 10:05 +, Chris Turner wrote: On Thu, Jul 07, 2011 at 10:50:46AM +0200, Georg Bege wrote: The funny thing is, addresses do get resolved (if I dont have any default) I dont get anything (no dns/resolving). But ping doesnt get through nor any kind of connection. Do I have this correct: - without the route assignment, dns lookups are working - with the route assignment, dns lookups are not working? I didn't actually see the address assignment in your ifconfig output - was the ppp0 device output truncated or ? If I am correct, it sounds like perhaps some data is flowing but not all - which could indicate an MTU mismatch Though I don't have direct pppoe experience on FreeBSD/DragonFly - I did once use the OpenBSD implementation (which uses a userspace daemon rather than the netgraph device) - I had some issues with the mtu matchup which caused some issues - My archived configuration had : set mtu max 1492 # set mru max 1492 so you might try commenting out the mru portion? What does the ping of e.g. the remote gateway, show exactly? host unreachable or something else? Its been a while since I debugged an MTU mismatch but iirc if you can ping the gateway but not something else (like say your upstream dns server ) and the routes look ok (and tcpdump is showing the packets flowing out ) you can set some combination of ping -p and -D to detect the mismatch again, IIRC, I think e.g.: ping -p 1500 routed IP? gateway IP? ping -p 1492 routed IP? gateway IP? - works ping -D -p 1492 routed IP? gateway IP? - works ping -D -p 1500 routed IP? gateway IP? - fails or something like this - I'd verify what I'm saying with some searching :D or maybe someone can chime in? that wouldn't explain why the config is working on one but not the other, though I do recall that some of the default settings might be different w/r/t freebsd, etc. in ppp from previous adventures with PPP (using GSM devices) good luck! Cheers, - Chris !DSPAM:4e158f3a844724810620489!
Unable to login with PPPoE (2.10-RELEASE x86)
Good day to you all I recently installed Dragonfly BSD on some box of mine - potentially replacing my old router. Im not really a beginner, did use various BSDs before but using FreeBSD most of the time. I actually never had a lot of issue regarding this, but now Im running out of ideas. Whatever I try Im not able to use PPPoE to login to my internet (which is essential for the purpose of this box). I seem to get an IP but I cannot ping anything (eg. no routing?) I'll attach my ppp.conf and a ppp.log (for the logging options I used, see the conf.) Of course my auth is correct, else I wouldnt get an IP actually. I compile my own kernel now, but for now I keep running the generic stuff: ---snip- re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet6 fe80::beae:c5ff:feb7:a940%re0 prefixlen 64 scopeid 0x1 ether bc:ae:c5:b7:a9:40 media: Ethernet autoselect (100baseTX full-duplex) status: active ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2290 ether d8:5d:4c:ba:d4:7a media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: associated lp0: flags=8810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500 faith0: flags=8002BROADCAST,MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 ppp0: flags=8010POINTOPOINT,MULTICAST mtu 1500 sl0: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.2.1 netmask 0xfff8 broadcast 192.168.2.7 inet6 fe80::da5d:4cff:feba:d47a%wlan0 prefixlen 64 scopeid 0x8 ether d8:5d:4c:ba:d4:7a media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: associated ssid ninth-art.net channel 7 (2442 MHz 11g) bssid d8:5d:4c:ba:d4:7a regdomain ETSI country DE indoor ecm authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs tun0: flags=8010POINTOPOINT,MULTICAST mtu 1492 ---snip- (as you can see I've setup my wireless card already) uname -a: ---snip- DragonFly aquina.ninth-art.net 2.10-RELEASE DragonFly v2.10.1.1.gf7ba0-RELEASE #1: Mon Apr 25 19:48:10 UTC 2011 r...@pkgbox32.dragonflybsd.org:/usr/obj/usr/src/sys/GENERIC i386 ---snip- kldstat: ---snip- Id Refs AddressSize Name 1 21 0xc010 83ac14 kernel 21 0xc093b000 1680cif_ath.ko 33 0xc0952000 62aecath_hal.ko 42 0xc09b5000 4b44 ath_rate.ko 51 0xc09ba000 7754cacpi.ko 61 0xc0a32000 133c4ahci.ko 71 0xc0a46000 9708 ehci.ko 82 0xc0a5 b8a0 dm.ko 91 0xc0a5c000 18d80dm_target_crypt.ko 101 0xc1975000 1ca0 wlan_xauth.ko 111 0xd2b4 9000 netgraph.ko 121 0xd2b0e000 4000 ng_ksocket.ko 131 0xd2b12000 3000 ng_ether.ko 141 0xd2b49000 4000 ng_pppoe.ko 151 0xd2b4d000 3000 ng_socket.ko ---snip- PS.: Another issue of mine (which might be minor) is that whether Im loading pf.ko or not I dont get the /dev/pf actually. cheers -- Georg Bege ther...@ninth-art.de !DSPAM:4e151e44844721308043045! Jul 7 04:24:04 aquina ppp[337]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook duibr1) Jul 7 04:24:04 aquina ppp[337]: tun0: Phase: Received NGM_PPPOE_SESSIONID Jul 7 04:24:04 aquina ppp[337]: tun0: Phase: Received NGM_PPPOE_SUCCESS Jul 7 04:24:04 aquina ppp[337]: tun0: Phase: deflink: carrier - login Jul 7 04:24:04 aquina ppp[337]: tun0: Phase: deflink: login - lcp Jul 7 04:24:04 aquina ppp[337]: tun0: LCP: FSM: Using deflink as a transport Jul 7 04:24:04 aquina ppp[337]: tun0: LCP: deflink: State change Initial -- Closed Jul 7 04:24:04 aquina ppp[337]: tun0: LCP: deflink: State change Closed -- Stopped Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: deflink: LayerStart Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: ACFCOMP[2] Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: PROTOCOMP[2] Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: ACCMAP[6] 0x Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: MRU[4] 1492 Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: MAGICNUM[6] 0x526c492e Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: QUALPROTO[8] proto c025, interval 3ms Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: deflink: State change Stopped -- Req-Sent Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: deflink: RecvConfigReq(4) state
Re: Unable to login with PPPoE (2.10-RELEASE x86)
Hi. On Thu, Jul 07, 2011 at 04:47:23AM +0200, Georg Bege wrote: I actually never had a lot of issue regarding this, but now Im running out of ideas. Whatever I try Im not able to use PPPoE to login to my internet (which is essential for the purpose of this box). I seem to get an IP but I cannot ping anything (eg. no routing?) ppp.log: Jul 7 04:24:05 aquina ppp[337]: tun0: IPCP: myaddr 84.62.131.143 hisaddr = 84.62.128.1 Jul 7 04:24:05 aquina ppp[337]: tun0: Warning: 84.62.128.1: Change route failed: errno: No such process Try this command to replace the current default route to hisaddr above # route change default 84.62.128.1 If ping works after this, change the last line in ppp.conf from add default HISADDR to add! default HISADDR Cheers.
