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 [EMAIL 
 > PROTECTED]
 > 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to