Thanks bill and john ,

>>I am trying to run iij-ppp on my lc630.

>Funny you should ask... I just spent last night trying
>to run the same thing on a Sparc 2 running NetBSD/Sparc 1.3.

>>Now no communication is failed tty00 to modem.
>>that is mean
>>I enter ppp and term , following message is out
>>>ppp
>>User Process PPP. Written by Toshiharu OHNO.
>>Using interface: tun0
>>Interactive mode
>>ppp ON mac> term
>>OpenModem: Cannot get modem status: Inappropriate ioctl for device  
 139440
>> 4 1
>>Failed to open modem.
>>ppp ON mac> quit

>Same here. It appears to not open the modem correctly (if at all).

>Also, it appears to not read the config files correctly (or not at all).

>Out of curiousity, does the string "139440" appear anywhere in your
>ppp.conf file?
>That is not the default name for the modem device (tty01), so I wondered
>if it
>picked up part of the phone number or something. This would tell us if
>the
>program was at least reading the ppp.conf file.

I think cofile is correctly

>ppp
User Process PPP. Written by Toshiharu OHNO.
Using interface: tun0
Interactive mode
ppp ON mac> load ibm
ppp ON mac> show modem
device: /dev/tty00  speed: 38400
cs8, no parity, CTS/RTS on.
connect count: 0
outqlen: 0
DialScript  = ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT&F&D0 OK-AT-OK  
 \dATDP\
T TIMEOUT 40 CONNECT
LoginScript =
PhoneNumber(s) = XXXXXXXX
ppp ON mac>

I use dial or term command then modem's TR is flush and
OpenModem: Cannot get modem status: Inappropriate ioctl for device 139440  
  message is appear.



>>my mchine
>>    Q630, MacBSD1.3

>It's not a hardware problem, unless it's (possible) word-order-related.
>Personally, I suspect stdio issues.

I think so.

>>    iij-ppp include FreeBSD2.2.5

>Same here.

>>        I changed the source
>>              if_tun.h ,if_tun.c, libiotcl.h ->iotcl
        

>This is where I differ. I modified ppp/tun.c, instead, to set the
>IFF_POINTOPOINT
>mode according to the current IOCTLs. The if_tun.[ch] files were
>replacemnt kernel
>files for NetBSD 1.0. The tun driver has evolved (and diverged)
>considerably since
>then.

>I don't think, though, that this is the problem unless it is*totally*
>screwing up the
>application. If it was just the tun driver, I would *expect* it to
>connect, but not
>work (or at least not allow net connections).

I want to know your diffs
I only change the follow

if_tun.c

static int
tunioctl(dev, cmd, data, flag, p)
 dev_t  dev;
 u_long  cmd;
 caddr_t  data;
 int  flag;
 struct proc *p;
{
 int  unit = minor(dev), s;
 struct tun_softc *tp = &tunctl[unit];
+  struct tuninfo *tunp;

 switch (cmd) {
+  case TUNSIFINFO:
+          tunp = (struct tuninfo *)data;
+   tp->tun_if.if_mtu = tunp->mtu;
+   tp->tun_if.if_type = tunp->type;
+   tp->tun_if.if_baudrate = tunp->baudrate;
+   break;
+  case TUNGIFINFO:
+   tunp = (struct tuninfo *)data;
+   tunp->mtu = tp->tun_if.if_mtu;
+   tunp->type = tp->tun_if.if_type;
+   tunp->baudrate = tp->tun_if.if_baudrate;
+   break;
 case TUNSDEBUG:
  tundebug = *(int *)data;
  break;


if_tun.h

+ struct tuninfo {
+ int baudrate;  /* linespeed */
+ short mtu;   /* maximum transmission unit */
+ u_char type;   /* ethernet, tokenring, etc. */
+ u_char dummy;   /* place holder */
+ };

+ #define TUNSIFINFO _IOW('t', 91, struct tuninfo)
+ #define TUNGIFINFO _IOR('t', 92, struct tuninfo)




defs.c

void
randinit()
{
+ #ifdef __FreeBSD__  | __NetBSD__
   static int initdone;

   if (!initdone) {
     initdone = 1;
     srandomdev();
   }
 #else
   srandom(time(NULL)^getpid());
 #endif
 }



Othe source

include libiotcl.h   replace  to   include iotcl.h




>As for those who wonder why one would use iij-ppp instead of the
>included pppd, I
>offer three reasons:

>1) Seamless integration of ip-nat and demand-dial ppp functionality.

>2) Familiarity... some of us do run other BSD variants on our x86 boxen.

>3) Diversity- the Unix way. :-)

>Any thoughts?
><<<John>>>

I want to use ip-nat.