Re: ng_ppp: how to send NGM_PPP_SET_CONFIG?

2003-06-28 Thread Archie Cobbs 
Gleb Smirnoff wrote:
> ngctl <<
> mkpeer iface dummy ipx
> msg ng0: point2point {};
> mkpeer .:dummy ppp inet inet
> name .:dummy.inet ppp0
> connect ppp0: cp0: link0 rawdata
> 
> ifconfig ng0 x.x.x.x x.x.x.y up
> 
> Trying to ping x.x.x.y i get: Device not configured
> Trying to ping x.x.x.x i get: No route to host
> 
> If I connect to ppp0's bypass hook, I see data coming in.
> 
> In ng_ppp(4) it is said that node needs to be configured first, but 
> I can't find the way to send NGM_PPP_SET_CONFIG message in ASCII form.

You need a userland daemon, such as mpd (see ports), to control
the ng_ppp node. With mpd try the "ng" device type.

-Archie

__
Archie Cobbs *Halloo Communications* http://www.halloo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: something wrong with fxp driver ?

2003-06-28 Thread Ying-Chieh Liao 
On Fri, Jun 27, 2003 at 15:40:22 -0700, Doug White wrote:
> On Fri, 27 Jun 2003, Ying-Chieh Liao wrote:
> > On Fri, Jun 27, 2003 at 09:28:31 -0400, Robert Watson wrote:
> > > You might compare the dmesg output from before/after and see if there are
> > > any obvious changes in IRQ allocation, shared interrupts, etc.  Perhaps
> > > the changes in interrupt routing have resulted in some new behavior.
> > I lost my old kernel :<
> In the future, 'make reinstall' is your friend :)

ok, I give up
I think I have to revert my system back to 5.1-R
-- 
self-producing in python :
l='l=%s;print l%%`l`';print l%`l`
-- Frank Stajano


pgp0.pgp
Description: PGP signature

using memory after freed in tcp_syncache (syncache_timer())

2003-06-28 Thread Don Bowman 
syncache_timer()
 ...
/*
 * syncache_respond() may call back into the syncache to
 * to modify another entry, so do not obtain the next
 * entry on the timer chain until it has completed.
 */
(void) syncache_respond(sc, NULL);
nsc = TAILQ_NEXT(sc, sc_timerq);
tcpstat.tcps_sc_retransmitted++;
TAILQ_REMOVE(&tcp_syncache.timerq[slot], sc, sc_timerq);

so what happens is that syncache_respond() calls ip_output,
which ends up calling ip_input, which ends up doing something
that causes 'sc' to be freed. Now 'sc' is freed, we return
to syncache_timer(), and then we use it in nsc = TAILQ_NEXT(...)
line.

This particular part of the problem was introduced in
1.23 of tcp_syncache.c in response to another bug that i had
found.

Does anyone have a suggestion on a proper fix?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: using memory after freed in tcp_syncache (syncache_timer())

2003-06-28 Thread Don Bowman 
From: Don Bowman
 ...
It appears this may also occur in syncache_add():
in this case, syncache_respond() alters the list.

sc->sc_tp = tp;
sc->sc_inp_gencnt = tp->t_inpcb->inp_gencnt;
if (syncache_respond(sc, m) == 0) {
s = splnet();
TAILQ_REMOVE(&tcp_syncache.timerq[sc->sc_rxtslot],
sc, sc_timerq);
SYNCACHE_TIMEOUT(sc, sc->sc_rxtslot);
splx(s);
tcpstat.tcps_sndacks++;
tcpstat.tcps_sndtotal++;
}
*sop = NULL;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"