a look at the current `customers' for sppp, which are
> > sys/i4b/driver/i4b_sppp.c (for a driver that uses dialup connections),
> > and sys/i386/isa/if_{ar,cx,sr}.c for drivers that use hardware links
> > (like HDLC lines) without dialling.
> >
> > > - Is there
As Julian Elischer wrote:
> of course if you want to be really generic, we've just added the
> netgraph code to -current which implements a lot more than the
> rather specialised sppp code.
Sure, i was only answering a question.
--
cheers, J"org
[EMAIL PROTECTED] -- http://www.sax.de/~joerg/
f_{ar,cx,sr}.c for drivers that use hardware links
> (like HDLC lines) without dialling.
>
> > - Is there any resource about using the sppp driver. The sppp man page =
> > isn't satisfying at all.
>
> See above.
>
> > --=_NextPart_000_01C7_01BF09C7.C5ECB6F0
&g
"Daniel Hilevich" <[EMAIL PROTECTED]> wrote:
> In my case, although, I want to use the IFF_AUTO (dial on demand)
> option and this is where ifconfig can not help me. In the auto mode,
> the sppp driver should initialize the lcp machine when it gets a new
> message to
x,sr}.c for drivers that use hardware links
(like HDLC lines) without dialling.
> - Is there any resource about using the sppp driver. The sppp man page =
> isn't satisfying at all.
See above.
> --=_NextPart_000_01C7_01BF09C7.C5ECB6F0
> Content-Type: text/html;
> ch
> At 05:54 AM 9/30/99 -0400, W Gerald Hicks wrote:
> >
> >> doing state machines with switch statements is a big mess.
> >
> >Still, you'll find a lot of them around. Do you have a favored
> >technique for coding complex state machines? (I'm a collector :)
>
>
> yes, state tables. Clean and ea
> > Are you busy with a leased line driver or a dialup/isdn kind of driver?
> > I have been busy fixing sppp to work properly with leased line drivers
> > again, but am not finished with it yet. :-/ Hopefully I won't break
> > the isdn handling at the same time.
> >
>
> I'm writing this pseudo dr
At 05:54 AM 9/30/99 -0400, W Gerald Hicks wrote:
>
>> doing state machines with switch statements is a big mess.
>
>Still, you'll find a lot of them around. Do you have a favored
>technique for coding complex state machines? (I'm a collector :)
yes, state tables. Clean and easy to modify.
>
>
u are absolutely right when it comes to handling the sppp driver in manual
mode. The user creates a Up event using ifconfig and a Open event moves the
fsm from Starting(1) to Req-Sent(6).
In my case, although, I want to use the IFF_AUTO (dial on demand) option and
this is where ifconfig can not hel
> doing state machines with switch statements is a big mess.
Still, you'll find a lot of them around. Do you have a favored
technique for coding complex state machines? (I'm a collector :)
One scheme I've been using for quite some time is to use a function
pointer as a 'state variable', somet
>
> My problem is that when you get the first CONF_REQ message, the driver's
> state is INITIAL.
> The call to the RCR function return with the value 1 but, no one changes the
> state to STATE_ACK_SENT. I think the fix should be like this (line 1274):
>
>
> rv = (cp->RCR)(sp, h,
When you trying to establish connection from one peer (local) to another
> > (remote), you sent a CONF_REQ message to the remote peer. The remote
peer
> > should answer with a CONF_ACK message. In the code of the sppp driver
> > (net/if_spppsubr.c, lines 1321 - 1357) you can s
> > When you trying to establish connection from one peer (local) to
another
> > (remote), you sent a CONF_REQ message to the remote peer. The remote
peer
> > should answer with a CONF_ACK message. In the code of the sppp driver
> > (net/if_spppsubr.c, lines 1321 - 13
e across this situation and I think it's
> a bug:
> When you trying to establish connection from one peer (local) to another
> (remote), you sent a CONF_REQ message to the remote peer. The remote peer
> should answer with a CONF_ACK message. In the code of the sppp driver
> (ne
Mark Tinguely scribbled this message on Sep 29:
> The sppp
> is more efficient than ppp and pppd because it does not have to map
> the packets from kernel space to user space and then back again, plus the
> advatages not having to service interrupts on each character, the
> synchronous link does n
> When you trying to establish connection from one peer (local) to another
> (remote), you sent a CONF_REQ message to the remote peer. The remote peer
> should answer with a CONF_ACK message. In the code of the sppp driver
> (net/if_spppsubr.c, lines 1321 - 1357) you can see tha
(deletes and edits)
> But, in the later case, the control messages are queued to
> the control queue (sp->pp_cpq) which the if_start functions
> doesn't have access to.
in the ISDN (sys/i4b/driver) code, the interface target of the
if_start(), there is a call to sppp_dequeue() which gets the top
As I understand from rfc1661, the state, which the remote machine should be
after sending a CONF_ACK message, is ack_send. The sppp driver doesn't work
properly and I think that this is on of the reasons.
- Original Message -
From: Dennis <[EMAIL PROTECTED]>
To: Daniel Hilev
mote peer
>should answer with a CONF_ACK message. In the code of the sppp driver
>(net/if_spppsubr.c, lines 1321 - 1357) you can see that the remote peer
>send's a CONF_ACK message to the local peer
>(in the line: rv = (cp->RCR)(sp, h, len);) but doesn't change it state t
While trying to use the sppp, I came across this situation and I think it's
a bug:
When you trying to establish connection from one peer (local) to another
(remote), you sent a CONF_REQ message to the remote peer. The remote peer
should answer with a CONF_ACK message. In the code of the
I'm currently working on a driver that
provides point to point connection and I would like to use the sppp driver
in order to get PPP stack over it.
I have few questions about the sppp
driver:
- As I understood from the code,
the sppp driver prepends the ppp frame over the given da
21 matches
Mail list logo
