Re: Unable to login with PPPoE (2.10-RELEASE x86)

[Georg Bege <therion@xxxxxxxxxxxx>]

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!