Archie Cobbs wrote:
>
> Olivier Cherrier writes:
> > Ho, I think that I found my problem ... maybe
> > In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it
>
> MPPE encryption piggybacks on MPPC compression. You can have
> either or both of 'E' and/or 'C'. Mpd only suppor
In message <[EMAIL PROTECTED]>, Boris Popo
v writes:
> Before starting import process for smbfs, I would like to
>introduce new API which greatly simplifies process of packaging data into
>mbufs and fetching it back (in fact, similar API already presented in the
>tree, but it is private to t
Hello.
I'd like to share some thought on what happened to me: I had an external ADSL modem
from
Alcatel connected (with a straight cable, since the device has a reversed ethernet
port) to
a RealTek card on a FreeBSD 4.1-RELEASE box.
I used the simple line in rc.conf:
ifconfig_
On Thu, 8 Feb 2001, Andrea Venturoli wrote:
> My wonderings are: _ "mediaopt full-duplex" does not work, while it's
> documented in the rl man page; isn't this a bug?
According to your email, mediaopt full-duplex works, but only if it is
specified concurrently with media keyword. half-duplex doe
On Wed, 7 Feb 2001, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > Jayanth did make one point that an application could assume that
> > the error return from accept was in regards to the listening socket
> > instead of the new socket, so that may be a concern.
>
> Yes I have always assumed t
In article [EMAIL PROTECTED]> you write:
>Jonathan Lemon writes:
>> Jayanth did make one point that an application could assume that
>> the error return from accept was in regards to the listening socket
>> instead of the new socket, so that may be a concern.
>
>Yes I have always assumed this to
In article
[EMAIL PROTECTED]>
you write:
>
>On Wed, 7 Feb 2001, Archie Cobbs wrote:
>
>> Jonathan Lemon writes:
>> > Jayanth did make one point that an application could assume that
>> > the error return from accept was in regards to the listening socket
>> > instead of the new socket, so that
Luigi Rizzo wrote:
> interesting dump... because it shows a bogus "length"
> parameter passed to ed_pio_readmem().
Bosko and I were discussing my problem offline a couple of weeks ago,
and in the course of a single morning I managed to create about 15
crashes. A couple of them were just
> Bosko and I were discussing my problem offline a couple of weeks ago,
you see, a couple of weeks ago the whole bridging-related
code had all sort of race conditions involving pointers to memory
areas about to be freed. I think/hope to have fixed most of them
now so it is probably worthwhile con
On Thu, Feb 08, 2001 at 03:32:03PM -0500, Andrea Venturoli wrote:
> So I issued an ifconfig and saw that the card was set to media autoselect (NONE).
> I tried with
>
> ifconfig rl1 inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt
>half-duplex
>
> but it would not accept th
Julian Elischer writes:
> > Olivier Cherrier writes:
> > > Ho, I think that I found my problem ... maybe
> > > In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it
> >
> > MPPE encryption piggybacks on MPPC compression. You can have
> > either or both of 'E' and/or 'C'. Mp
Robert Watson writes:
> > Jonathan Lemon writes:
> > > Jayanth did make one point that an application could assume that
> > > the error return from accept was in regards to the listening socket
> > > instead of the new socket, so that may be a concern.
> >
> > Yes I have always assumed this to b
Jonathan Lemon writes:
> >> Jayanth did make one point that an application could assume that
> >> the error return from accept was in regards to the listening socket
> >> instead of the new socket, so that may be a concern.
> >
> >Yes I have always assumed this to be true. If the connection is
>
On Thu, Feb 08, 2001 at 10:12:43AM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > >> Jayanth did make one point that an application could assume that
> > >> the error return from accept was in regards to the listening socket
> > >> instead of the new socket, so that may be a concern.
> >
>From what I've been able to dig up on the net it appears that the only
promising work on mobile IPv4 for FreeBSD (at U Oregon) pretty much
dried up in 1998. Do any of you know of any current work being done to
integrate mobile IPv4 into FreeBSD?
--lyndon
To Unsubscribe: send mail to [EMAIL PRO
Boris Popov wrote:
[...]
> Not exactly so. 'option LIBMBUF' will just connect the source file
> to kernel makefile. There is no need for any #ifdef's in the code.
Right. But I assume LIBMBUF will absolutely be needed if code that
uses the routines is compiled. What I just meant to say was:
>It should work with all Windows clients as long as they don't
>require MS-CHAP version 2 authentication.
>
Yes, it works.
It works fine.
But there is no encryption of data between MPD and windows clients... When I
do some work in a such connection, I can read data with a tcpdump ...
Nevertheles
http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
This is a call for testers for a netgraph module that can be used to
aggregate 2 or 4 ethernet interfaces into a single interface. Basically,
it lets you do things like the following:
# kldload ./ng
So, ip_output.c contains the following:
#ifdef vax
#include
#endif
...
#ifndef vax
if (m->m_len % sizeof(int32_t))
goto bad;
#endif
and maybe it would be the case to remove the first block and the
conditiona
Hi,
it occurs to me that there is a potential infinite loop in
most if not all ethernet drivers. Basically, on a
receive interrupt, such drivers loop around the status word
until the receive queue is drained.
If the body of the loop takes approx the same as
the packet interarrival time, you migh
< said:
> it occurs to me that there is a potential infinite loop in
> most if not all ethernet drivers. Basically, on a
> receive interrupt, such drivers loop around the status word
> until the receive queue is drained.
One possible right way to deal with this is to get rid of the
two-level int
On Thu, 8 Feb 2001, Bill Paul wrote:
> http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
> http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
>
> This is a call for testers for a netgraph module that can be used
> to aggregate 2 or 4 ethernet interfaces into a single interface.
> Basically, it lets
On Thu, 8 Feb 2001, Ian Dowse wrote:
> It may be beneficial to use separate structs for the build and
> breakdown operations. The two cases have slightly different
> requirements: the mb_count field is only useful when building, and
> mb_pos is only strictly necessary when breaking down mbuf chai
On Thu, 8 Feb 2001, Bosko Milekic wrote:
> in mb_init(), the m->m_pkthdr.rcvif = NULL; can be ommitted, as
> MGETHDR() will do that. The m->m_len = 0 should stay for now.
Ok.
> drivers that pre-allocate mbufs + clusters, they typically know the
> `count'), it turns out that it is cheape
At 9:09 PM -0500 2/8/01, Garrett Wollman wrote:
>One possible right way to deal with this is to get rid of the
>two-level interrupt scheme (for fast interfaces at least) and push the
>packets all the way through the network stack. This will ensure that
>if packets are arriving faster than we can
Boris Popov wrote:
[...]
> > For this to work, though, m_getm() needs to be modified to free
all of
> > `top' chain if it can't get either a cluster or an mbuf. I don't
know
> > if this was intentional, but it seems to me that there is a subtle
> > problem in m_getm() as it is now:
> >
> > if (l
On Thu, 8 Feb 2001, Bosko Milekic wrote:
> any case, if we do move this to uipc_mbuf.c, we need to do one of the
> following:
>
> (a) make m_getm() free what it allocated in previous loop iterations
> before it failed (as described above) or
>
> (b) leave m_getm() the way it is BUT write an add
Luigi wrote:
> Try the following patch: near line 2209 of if_ed.c
> - if ((len > sizeof(struct ed_ring)) &&
> + if ((len > ETHER_HDR_LEN + sizeof(struct ed_ring)) &&
I did, and it appears to avoid panics. I downloaded 400 MB worth of
data just now, over my home DSL line,
Mark Peek wrote:
>
> At 9:09 PM -0500 2/8/01, Garrett Wollman wrote:
> >One possible right way to deal with this is to get rid of the
> >two-level interrupt scheme (for fast interfaces at least) and push the
> >packets all the way through the network stack. This will ensure that
> >if packets ar
29 matches
Mail list logo
