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=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 > priority: 0 > groups: tun egress > status: active > inet 1.2.3.4 --> 1.2.3.1 netmask 0xffffffff > > 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 that way), I just wanted to test it.: > > > > -----------------------snip----------------------------- > > root@aquina /etc/ppp> cat ppp.linkup > > MYADDR: > > delete default > > add default HISADDR > > -----------------------snip----------------------------- > > > > Im going to attach my ppp.log again (renamed ppp_2.log). > > > > You'll notice a specific line: > >> Jul 7 19:16:24 aquina ppp[337]: tun0: Warning: 84.63.128.1: Change > > route failed: errno: No such process< > > > > I think that this is about the problem, but Im pretty unsure how to > > interpret that. > > > > cheers > > Georg > > > > Am Donnerstag, den 07.07.2011, 10:05 +0000 schrieb Chris Turner: > >> > >> 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:4e172cca844721635267679!
