From owner-freebsd-questions@FreeBSD.ORG Mon Dec 1 14:00:30 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEF0A1065677 for ; Mon, 1 Dec 2008 14:00:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 88A498FC24 for ; Mon, 1 Dec 2008 14:00:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mB1E0Aao073148; Tue, 2 Dec 2008 01:00:10 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 2 Dec 2008 01:00:10 +1100 (EST) From: Ian Smith To: Pongthep Kulkrisada In-Reply-To: <20081130142757.GA926@gmail.com> Message-ID: <20081201235157.J34249@sola.nimnet.asn.au> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Andrew , freebsd-questions@freebsd.org, Fbsd1 , Manolis Kiagias Subject: Re: Problem about ppp -nat X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 14:00:30 -0000 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