Problem about ppp -nat

Sun Nov 30 06:28:19 PST 2008

Hi all,

> set log phase chat connect carrier link ipcp ccp ID0 TUN command
I still can't dial using this configuration...

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.

> 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.
[...]
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.

>>  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.

> 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 at 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!
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
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
Nov 30 17:01:06 bsdhost ppp[978]: tun0: Phase: deflink: Disconnected!
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
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")
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

> Just as an aside, as you're not using any keep-state rules: you should
> do NAT before a check-state, so packets match dynamic rules after NAT.
Okay I shall.

> More specifically the interface, here tun0, must exist before using
> divert sockets using that interface.  natd(8) says:
Yes, I agreed as said earlier.

> You've probably noticed that tun0 doesn't go away when you close ppp, so
> it's sufficient to have run ppp once before using the divert rule.  In
> any case I doubt this'd really do any harm (apart from not working :)
Yes, I have long noticed it.

> 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.

> 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
00100 check-state
...

After presence of tun0 (after dialing) ...
# sh /etc/ipfw.rules
Flush all rules.
ipfw: ipfw_ctl invalid option 56
ipfw: setsockopt(IP_FW_NAT_CFG): Invalid argument
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
But I just can't pass step 3, unless I unload ipdivert.
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?

I think I should go on with ipfw nat, but to correct some syntax in /etc/ipfw.rules.

Thank you.
Pongthep