Rodrigo Cano writes:
> In the pppoe.if I put:
>
> rge0 // the name of my interface, which is already plumbed.
OK. You can use "sppptun query" to make sure that the interface is
properly configured.
> In the file located in /ect/ppp/peers/myserver, I would like you to tell me
> what to put:
I'll assume that the leading "-" on each line and the trailing "//"
are just a typographical convention. The system doesn't support
parsing either of those in that file.
> -sppptun //I guess that this is for plumbing.
Yes. It tells pppd to use /dev/sppptun to access the PPPoE tunnel.
> -plugin pppoe.so //just a library needed i guess.
Yes. It contains the PPPoE glue code, which knows how to send and
receive packets over the /dev/sppptun connection.
> -connect "/ust/lib/inet/pppoec rge0" //not the slightest idea.
Not "ust" -- that should be "usr". If you actually wrote "ust" in
your configuration file (isn't this just a cut-n-paste?), then that'll
result in a non-working connection.
As for what it does -- see the pppoec(1M) man page. This utility does
the PPPoE neogtiation. It locates the server and starts a new
session. When it has finished running, the session is running PPP as
pppd expects.
It's analogous in function to "/usr/bin/chat" when used with a modem.
When you run PPP over a modem, the modem isn't initially connected and
isn't speaking PPP. The function of "chat" is to dial the phone and
get the peer to start speaking PPP, and it then exits to hand back
control to pppd. "pppoec" does effectively the same thing, but with
PPPoE.
> -noccp //don't remeber actually, but I retained that it was ok
That's not really required, but since CCP (data compression) is
unlikely to converge -- ISPs usually don't support it, and if they do,
they generally use a non-free algorithm that pppd doesn't support --
disabling it is reasonable.
There are a small number of ISPs that will simply fail to operate if
you leave CCP enabled. They're broken, of course, and not following
the RFCs correctly, but dealing with ISP problems is a large part of
the battle here.
> -noauth //yeah, I don't need my ISP to auth.
Correct.
> -user //I guess that here I should put client name given by the ISP, in
> windows it is [EMAIL PROTECTED], should I put this one?
Yes! Otherwise, you've got an invalid configuration. The "user"
option (as documented in the pppd(1M) man page) requires an argument.
> -password //the password given to me by the isp right?
That's one way to do it. That option takes an argument -- the
password to use.
The safe way to do this is with /etc/ppp/pap-secrets. You would
ordinarily add a line in there that looks like this:
[EMAIL PROTECTED] * "your password here"
> -noipdefault //no idea
That stops pppd from suggesting an IP address to your ISP. Ideally,
it shouldn't be necessary, but many ISPs have bug-ridden systems that
will drop the connection if the client system makes any suggestions.
> -defaultrout // again, no idea.
That's misspelled. It should be "defaultroute". If you actually
wrote "defaultrout" in your configuration file, it would cause the
link to fail.
That option is documented in pppd(1M). It tells pppd to create a
default route on your system.
> Now in the /etc/ppp/options I think these options are right:
>
> -lock
> -nodefaultroute
> -noproxyarp
Those seem fine.
> I grabbed the template options.ttyname and rename it options.sppptun, I have
> no idea of the baud rate.
There is no "baud rate."
You shouldn't need an options.sppptun file at all. It's superfluous
in a configuration like this. I'd remove that.
> I run the command touch /etc/ppp/options
> No output from that so I guess it was fine.
I don't understand. You already have that file ... why would you be
running "touch" on it ... ?
> Finally, i run the command pppd debug updetach call myIsp //the same name
> that the file in /etc/ppp/peers/myIsp
That sounds fine, but don't leave us in suspense. What happens?
> I know that my ISP uses PAP for authentication, but I don't know if I must
> modify the pap files, and what should I put.
As above -- either use the "password" option or configure
/etc/ppp/pap-secrets correctly.
> My computer is supposed to detect the IP of my ISP right?.
It'll negotiate the endpoint addresses with the peer according to RFC
1332. You'll see the results via syslog, your terminal (since you
included the debugging option "updetach"), and via "ifconfig -a".
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
