DragonFly users List (threaded) for 2011-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
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=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
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
