Re: pppoe
On 24.03.12 17:34, Andrey N. Oktyabrski wrote: I will wait some days... Less than one day :-( Symptoms are: - wifi works fine, I can log in to the machine by ssh. - I can use Internet from the machine - I can not use Internet from local net. PF NAT or routing do not work. PF restart/reload does not help. Reboot only. How can I debug it? What I must see? What information can be useful for developers? It does not happens when pf is disabled.
Re: pppoe
On 24.03.12 17:34, Andrey N. Oktyabrski wrote: On 24.03.12 11:55, Francois Tigeot wrote: On Sat, Mar 24, 2012 at 10:03:19AM +0400, Andrey N. Oktyabrski wrote: On 24.03.12 09:06, Andrey N. Oktyabrski wrote: PF NAT do not work with tun0 This is not correct: it works but only day or two. This is normal if your ppp connection does not come with a static IP address. Yes, I do it this way. Hmmm... I wrote it in wrong place. I haven't static IP address, I mean I use the (tun0) expression. You should use a rule only specifying the interface name (tun0) in that case;
Re: pppoe
On 24.03.12 11:55, Francois Tigeot wrote: On Sat, Mar 24, 2012 at 10:03:19AM +0400, Andrey N. Oktyabrski wrote: On 24.03.12 09:06, Andrey N. Oktyabrski wrote: PF NAT do not work with tun0 This is not correct: it works but only day or two. This is normal if your ppp connection does not come with a static IP address. Yes, I do it this way. You should use a rule only specifying the interface name (tun0) in that case; this one should do the trick: nat on $ext_if inet from !($ext_if) -> ($ext_if:0) This is my rules for now: $ egrep -v '^#|^$' /etc/pf.conf ext_if="tun0" eth_if="fxp0" int_if="wlan0" wifi_if="ath0" eth_net="192.168.1.0/24" int_net="192.168.2.0/24" scrub in nat on $ext_if from $int_net -> ($ext_if:0) nat on $eth_if from $int_net -> ($eth_if:0) pass in quick keep state pass out quick keep state I will wait some days... The 'inet' keyword prevents pf from nating IPv6 traffic. Is it critical when tun0 configured without ipv6? I have added it. P.S. Without NAT ppp eats less CPU, but not too much less. There is PIII processor - may be it is a normal load for it...
Re: pppoe
On Sat, Mar 24, 2012 at 10:03:19AM +0400, Andrey N. Oktyabrski wrote: > On 24.03.12 09:06, Andrey N. Oktyabrski wrote: > >PF NAT do not work with tun0 > This is not correct: it works but only day or two. This is normal if your ppp connection does not come with a static IP address. You should use a rule only specifying the interface name (tun0) in that case; this one should do the trick: nat on $ext_if inet from !($ext_if) -> ($ext_if:0) The 'inet' keyword prevents pf from nating IPv6 traffic. -- Francois Tigeot
Re: pppoe
On 24.03.12 09:06, Andrey N. Oktyabrski wrote: PF NAT do not work with tun0 This is not correct: it works but only day or two.
Re: pppoe
On 24.03.12 03:54, Nuno Antunes wrote: As far as I know, ppp is currently the only way to configure PPPoE sessions on DragonFly. The ppp userland program makes use of ng_pppoe kernel counterpart to deal with the PADIs/PADOs etc of the PPPoE session. Thank you, I have seen it by the ngctl utility. So the real issue is a NAT. PF NAT do not work with tun0, and no more kernel NAT implementations in the dfly at now. I love Darren Reed's ipnat, but it has been removed from dfly. FreeBSD has kernel NAT (which is really ng_nat if I understand correctly) for the ipfw, but dfly uses old versions of the netgraph and ipfw. So, no other solutions at the moment. Your configuration seems correct. You should get a tun0 interface with an ip address if everything goes well. Yes, it works, but eats too much CPU from time to time. This is not fatal for me, but I always like to have a best configuration :-) There is one more thing which seems strange for me: from time to time I see two or even three addresses on the tun0. Is it normal? Must I to worry about it?
Re: pppoe
2012/3/19 Andrey N. Oktyabrski : > Good day. > > How can I configure PPPoE interface? Now I use "ppp" program with this > configuration: > pppoe: > set device PPPoE:fxp0 #Interface to adsl-modem-bridge > set authname > set authkey > set dial > set login > add default HISADDR > nat enable yes > > $ ps ax | grep ppp > 254 ?? SLs 4:39.48 /usr/sbin/ppp -quiet -ddial -nat pppoe > > ... and see this in the "top": > 254 root 0 6460K 0K RUN 0 4:42 4:42 16.11% ppp > > > Is it possible to use anything other than "ppp"? ng_pppoe? How to configure > it? "man ng_pppoe" does not give me any useful information. Can anybody to > give me and example? Or I must compile mpd and use it? Hi, As far as I know, ppp is currently the only way to configure PPPoE sessions on DragonFly. The ppp userland program makes use of ng_pppoe kernel counterpart to deal with the PADIs/PADOs etc of the PPPoE session. Your configuration seems correct. You should get a tun0 interface with an ip address if everything goes well. Cheers Nuno
pppoe
Good day. How can I configure PPPoE interface? Now I use "ppp" program with this configuration: pppoe: set device PPPoE:fxp0#Interface to adsl-modem-bridge set authname set authkey set dial set login add default HISADDR nat enable yes $ ps ax | grep ppp 254 ?? SLs 4:39.48 /usr/sbin/ppp -quiet -ddial -nat pppoe ... and see this in the "top": 254 root 0 6460K 0K RUN 0 4:424:42 16.11% ppp Is it possible to use anything other than "ppp"? ng_pppoe? How to configure it? "man ng_pppoe" does not give me any useful information. Can anybody to give me and example? Or I must compile mpd and use it?
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)
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. > > (ip)[router](ip)(ip)[router](ip) ... > > e.g. if the don't fragment bit is set and the MTU mismatches > the ping will / won't fit 'through the pipe' where > 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 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 pack
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. (ip)[router](ip)(ip)[router](ip) ... e.g. if the don't fragment bit is set and the MTU mismatches the ping will / won't fit 'through the pipe' where 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 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 ---sni
Re: Unable to login with PPPoE (2.10-RELEASE x86)
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 + 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? > >
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 > ping -p 1492 > -> works > ping -D -p 1492 > -> works > ping -D -p 1500 > -> 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!
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 ping -p 1492 -> works ping -D -p 1492 -> works ping -D -p 1500 -> 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)
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 !DSPAM:4e15736c844721718360748!
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.
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=8843 mtu 1500 options=1b inet6 fe80::beae:c5ff:feb7:a940%re0 prefixlen 64 scopeid 0x1 ether bc:ae:c5:b7:a9:40 media: Ethernet autoselect (100baseTX ) status: active ath0: flags=8843 mtu 2290 ether d8:5d:4c:ba:d4:7a media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lp0: flags=8810 mtu 1500 faith0: flags=8002 mtu 1500 lo0: flags=8049 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 wlan0: flags=8843 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 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=8010 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 !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 = Req-Sent Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: MRU[4] 1492 Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: MAGICNUM[6] 0x5c512db9 Jul 7 04:24:05 aquina ppp[337]: tun0: LCP: deflink: SendConfigAck(4) state = Req-Se
