Date: Tue, 2 Dec 2008 01:00:10 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Pongthep Kulkrisada <ptkrisada@gmail.com> Cc: Andrew <awd@awdcomp.net>, freebsd-questions@freebsd.org, Fbsd1 <fbsd1@a1poweruser.com>, Manolis Kiagias <sonic2000gr@gmail.com> Subject: Re: Problem about ppp -nat Message-ID: <20081201235157.J34249@sola.nimnet.asn.au> In-Reply-To: <20081130142757.GA926@gmail.com> References: <20081123120013.8EDF310657E3@hub.freebsd.org> <20081124012858.J43853@sola.nimnet.asn.au> <20081128163044.GA1850@gmail.com> <20081129222143.R34249@sola.nimnet.asn.au> <20081130142757.GA926@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Nov 2008, Pongthep Kulkrisada wrote:
> Hi all,
>
> > set log phase chat connect carrier link ipcp ccp ID0 TUN command
> I still can't dial using this configuration...
Yes sorry, that was from a really old system, from backups.
> # ppp -background isp
> Loading /lib/libalias_cuseeme.so
> Loading /lib/libalias_ftp.so
> Loading /lib/libalias_irc.so
> Loading /lib/libalias_nbt.so
> Loading /lib/libalias_pptp.so
> Loading /lib/libalias_skinny.so
> Loading /lib/libalias_smedia.so
I'm surprised ppp would load these unless -nat was specified somewhere?
My newest system that used ppp is 5.5-STABLE, up till last August, but
I'm not up with it on 6 or 7, still this does look rather odd to me.
Perhaps someone else could confirm whether ppp always loads these
libalias modules, whether intending to use them or not?
> Working in background mode
> Using interface: tun0
> Warning: carrier: Invalid log value
> Warning: link: Invalid log value
> Warning: usage: set log [local] [+|-]all|async|cbcp|ccp|chat|command|connect|debug|dns|hdlc|id0|ipcp|lcp|lqm|phase|physical|radius|sync|tcp/ip|timer|tun...
> Attempting redial
> Attempting redial
> Attempting redial
>
> I then removed ``carrier'' and ``link''. It always keeps redialing without
> hearing dialing tone from the modem. So I removed ``connect'' again. The result was still the same.
Sorry again. On 5.5 I just used 'log Phase LCP IPCP CCP tun command'
once everything was running smoothly, using several different modems.
> > Try /dev/cuaa0. At least in the olden days, cuad0 was configured more
> > for dialin rather than dialout. This may? explain the next two lines:
> It keeps redialing without hearing any tone from the modem. So I
> switched back to /dev/cuad0. Then dial; now I hear dialing tone from
> the modem but warning message of ``Child failed (errdead)'' occured
> then line dropped. And can not connect. I tried it many times. Note
> that /dev/cuad0 appeared in my
> /usr/share/examples/ppp/ppp.conf.sample, not /dev/cuaa0. If I
> remember correctly I changed from cuaa0 to cuad0 when I upgraded from
> FBSD5.4R to FBSD6.2R.
Ok. I hadn't realised that ppp had changed so much. Wish someone who
knows a bit more about the current situation would comment ..
> [...]
> Working in background mode
> Using interface: tun0
> Child failed (errdead)
>
> >> set ctsrts off # enables software flow control
> >> set accmap 000a0000 # comments out these 2 lines for hardware flow control
> > Not sure why you don't want to use hardware flow control? Is this with
> > a regular external modem? Anyway, I've always used ctsrts (with cuaa0).
> 5 year ago, I downloaded this ppp.conf from some web site. But
> anyway, I did follow your suggestion i.e. hardware flow control. It
> still doesn't work as ``Child failed''. Actually I don't know so much
> in this area (flow control). I only code C on *Unix. I rarely do this
> kind of things e.g. system setup or configuration. And yes, it is a
> regular external modem.
I spent about 15 years debugging user problems with dialup modems; it
can be really difficult without first knowing the modem type and it's
internal config - however that doesn't seem to be your problem here.
> >> add! default HISADDR # Add a (sticky) default route
> >> [...]
> >> add 0 0 HISADDR
> > You probably don't want both those add statements. Try taking out the
> > first one, and replacing the last one with the add! default HISADDR.
> I changed it before dialing.
>
> > Unsure if you need an 'enable pap' as well, maybe default. Can't hurt.
> I added it before dialing. But all failed. I think it is probably caused by
> ipdivert.
Well as mentioned above, if ppp is loading libalias modules also, there
definitely could be some conflict there .. but I'm now out of my depth.
> > Anyway, some extra logging should show you when and how it fails, if it
> > still does ..
> Nov 30 17:00:00 bsdhost newsyslog[960]: logfile turned over due to size>100K
> Nov 30 17:00:16 bsdhost ppp[977]: Phase: Using interface: tun0
> Nov 30 17:00:16 bsdhost ppp[977]: Phase: deflink: Created in closed state
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE)
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: set device /dev/cuad0
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: set speed 115200
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: disable pred1
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: deny pred1
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: disable lqr
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: deny lqr
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 180 CONNECT
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: set redial 3 20
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: default: enable dns
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: ID0: 0x28389e78 = fopen("/etc/ppp/ppp.conf", "r")
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: set phone 0123456789
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: set authname myname@myisp.com
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: set authkey **********
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: set timeout 0
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: set openmode active
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: accept pap
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: enable pap
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: Command: ego: add! default HISADDR
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: ID0: 10 = socket(17, 3, 0)
> Nov 30 17:00:16 bsdhost ppp[977]: tun0: ID0: -1 = write(10, data, 140)
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: ID0: 0x28389e78 = fopen("/var/run/tun0.pid", "w")
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Phase: PPP Started (background mode).
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Phase: bundle: Establish
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Phase: deflink: closed -> opening
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: ID0: 0 = uu_lock("cuad0")
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: ID0: 0 = open("/dev/cuad0", 6)
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: ID0: 0x28389e78 = fopen("/var/run/cuad0.if", "w")
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Phase: deflink: Connected!
That all looks about normal.
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Phase: deflink: opening -> dial
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Phone: 1222
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: deflink: Dial attempt 1 of 20
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Send: AT^M
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Expect(5): OK
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Received: AT^M^M
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Received: OK^M
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Send: ATE1Q0^M
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Expect(5): OK
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Received: ATE1Q0^M^M
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Received: OK^M
I've always used E0 myself, but again, if it's been working ok ..
> Nov 30 17:00:16 bsdhost ppp[978]: tun0: Chat: Send: ATDT1222^M
> Nov 30 17:00:18 bsdhost ppp[978]: tun0: Chat: Expect(180): CONNECT
> Nov 30 17:00:49 bsdhost ppp[978]: tun0: Chat: Received: ATDT1222^M^M
> Nov 30 17:00:49 bsdhost ppp[978]: tun0: Chat: Received: CONNECT 115200^M
> Nov 30 17:00:49 bsdhost ppp[978]: tun0: Phase: deflink: dial -> carrier
> Nov 30 17:00:50 bsdhost ppp[978]: tun0: Phase: deflink: /dev/cuad0: CD detected
> Nov 30 17:00:50 bsdhost ppp[978]: tun0: Phase: deflink: carrier -> login
> Nov 30 17:00:50 bsdhost ppp[978]: tun0: Phase: deflink: login -> lcp
Right: at this point the next thing you should see is like:
Jul 13 00:18:47 paqi ppp[32861]: tun0: Phase: bundle: Authenticate
Jul 13 00:18:47 paqi ppp[32861]: tun0: Phase: deflink: his = PAP, mine = none
Jul 13 00:18:47 paqi ppp[32861]: tun0: Phase: Pap Output: smithi ********
Jul 13 00:18:48 paqi ppp[32861]: tun0: Phase: Pap Input: SUCCESS (Greetings!!)
Jul 13 00:18:48 paqi ppp[32861]: tun0: IPCP: Using trigger address 0.0.0.0
Jul 13 00:18:48 paqi ppp[32861]: tun0: Phase: deflink: lcp -> open
Jul 13 00:18:48 paqi ppp[32861]: tun0: Phase: bundle: Network
Jul 13 00:18:48 paqi ppp[32861]: tun0: IPCP: FSM: Using "deflink" as a transport
Jul 13 00:18:48 paqi ppp[32861]: tun0: IPCP: deflink: State change Initial --> Closed
Jul 13 00:18:48 paqi ppp[32861]: tun0: IPCP: deflink: LayerStart.
Jul 13 00:18:48 paqi ppp[32861]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed
etc.
That is, on connect it should then procede to authentication. There's
no sign of that. Whether failing at your end or the other is unclear;
maybe logging LCP might provide more of a clue, but I'm not sure ..
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: Disconnected!
.. but it looks like the other end hung up on you after ~18 seconds.
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: lcp -> logout
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: logout -> hangup
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: Disconnected!
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: Connect time: 50 secs: 434 octets in, 295 octets out
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: 1 packets in, 5 packets out
The rest looks like about normal closedown ..
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: total 14 bytes/sec, peak 109 bytes/sec on Sun Nov 30 17:00:55 2008
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = unlink("/var/run/cuad0.if")
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = uu_unlock("cuad0")
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: hangup -> closed
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = socket(17, 3, 0)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 148 = write(0, data, 148)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = socket(17, 3, 0)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 148 = write(0, data, 148)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = socket(2, 2, 0)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = ioctl(0, 3223349521, 0xbfbfea5c)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = ioctl(0, 2149607696, 0xbfbfea5c)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: bundle: Dead
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = ioctl(7, 2148037723, 0xbfbfeb00)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: PPP Terminated (normal).
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = socket(2, 2, 0)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = ioctl(0, 3223349521, 0xbfbfe6bc)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = ioctl(0, 2149607696, 0xbfbfe6bc)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: ID0: 0 = unlink("/var/run/tun0.pid")
.. except the below; I'm not familiar with these messages at all.
> Nov 30 17:01:06 bsdhost ppp[977]: tun0: Phase: Parent: Child failed (errdead)
> Nov 30 17:01:06 bsdhost ppp[978]: tun0: Chat: Parent notified of failure
> > I was under the impression that divert had to be built into the kernel,
> > but perhaps kldload ipdivert works allright with 7.x.
> divert(4) of FBSD7.0R stated that
> ipfw_load="YES"
> ipdivert_load="YES"
> are alternatives to ``options IPFIREWALL'' and ``options IPDIVERT''.
> So I put these 2 lines in /boot/loader.conf. And don't have to compile kernel.
> Then reboot and dial as described above
Ok, thanks for confirming that, and sorry for the sidetrack.
[..]
> > There's another way to bring up ppp (so creating tun0) without dialing
> > out until you're ready; using ppp -auto, with a dial filter rule/s. See
> > ppp(8) and the examples in /usr/share/examples/ppp/ppp.conf.sample ..
> > maybe something like:
> >
> > set filter dial 0 0 0 icmp src eq 8
> >
> > which will only dial upon seeing an outbound ping packet. You could
> > specify some address rather than 0 0 if you want to be more specific.
> It's very good suggestion. But for now I just can't bring up the
> connection. So I can't test it for now.
Fair enough.
> > Perhaps others can say if it's ok to kldload ipdivert after ipfw these
> > days? In any case, this could mean coincidence rather than causation.
> > You've not shown error messages from ppp.log indicating disconnection?
> Please see above.
>
> > Two things you should always check if there are problems passing traffic
> > through an interface that's apparently 'UP':
> > # ifconfig # make sure addresses, netmasks, etc make sense.
> > # netstat -finet -ran # check the default and other routes make sense.
> Yes I always do that when connected.
>
> > I can't say whether it
> > would get upset if tun0 was specified and didn't yet exist, but expect
> > it'll just ignore any packets that don't match the specified interface,
> > though I can't test that here now. Something like this should work:
> >
> > # ipfw nat 123 config if tun0 log deny_in same_ports unreg_only reset
> > # ipfw add [number] nat 123 ip4 from any to any via tun0
> >
> > where 123 is an arbitary number,and ip4 is more specific than 'all'
> At boot time ...
> Flush all rules.
> ipfw: unknown interface name tun0
> ipfw: getsockopt(IP_FW_ADD): Invalid argument
Hmm. I have rules for natd via ng0, which also doesn't exist at boot,
without any such complaints, but that's on a 5.5-STABLE box.
> 00100 check-state
> ...
>
> After presence of tun0 (after dialing) ...
> # sh /etc/ipfw.rules
> Flush all rules.
> ipfw: ipfw_ctl invalid option 56
What's that about? You haven't shown the rule that produced that ..
> ipfw: setsockopt(IP_FW_NAT_CFG): Invalid argument
.. or that. Again I wonder about those libalias modules ppp loaded ..
and whether you also had ipdivert loaded while trying ipfw nat? These
may be mutually exclusive, but I can't actually try it here currently.
> ipfw: getsockopt(IP_FW_ADD): Invalid argument
> 00100 check-state
> ...
>
> > Well you can solve your loading-order problem with ppp -auto and a dial
> > filter as above. Then you're free to choose between natd and ipfw nat,
> > or even ppp -nat if you want. Personally I quit using ppp in favour of
> > mpd4, and that works well for me (yes with natd, though on a 5.5 system)
> Well I loaded modules (ipfw and ipdivert) at boot time in /boot/loader.conf.
> 1. So at first these modules are loaded at boot time.
> 2. Secondly, rc.conf was read, which in turn enabling gateway and ipfw.
> 3. Then issue ppp command
> 4. Then natd -interface tun0
> 5. Then insert these commands to /etc/ipfw.rules as the first two rules.
> /sbin/ipfw add divert natd all from any to any via tun0
> /sbin/ipfw add pass all from any to any
> then run the ipfw script to load the new rules.
> sh /etc/ipfw.rules
Which other rules?
> But I just can't pass step 3, unless I unload ipdivert.
And your ppp.conf or ppp command definitely doesn't mention -nat?
> Please don't suspect my system. It had just been very freshly
> installed from CDs before I tried everything. And without ipdivert
> being loaded into the kernel, I can dial and browse any sites and
> very fast with my /etc/ppp/ppp.conf. Should note a bug?
Maybe it is. I'm out of ideas anyway, and noone else has come forward.
> I think I should go on with ipfw nat, but to correct some syntax in /etc/ipfw.rules.
Well I'm pretty sure you shouldn't load ipdivert as well as using ipfw
nat, but I've been almost 100% wrong so far so perhaps best ignore me :)
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081201235157.J34249>