On Sun, 11 Feb 2001, Luigi Rizzo wrote:
> > I don't have a dmesg.boot, only a dmesg.yesterday and dmesg.today.
> > What specifically should I be looking for?
>
> whether or not you have "options BRIDGE' in your kernel config file.
> (or a message saying "BRIDGE ..." when the system boots)
> > whether or not you have "options BRIDGE' in your kernel config file.
> > (or a message saying "BRIDGE ..." when the system boots)
>
> My kernel config doesn't have the BRIDGE option so I guess the
> bridging code is part of ET's drivers.
yes, i suspected so...
luigi
>
> Chee
On Mon, 12 Feb 2001, Luigi Rizzo wrote:
> > > whether or not you have "options BRIDGE' in your kernel config file.
> > > (or a message saying "BRIDGE ..." when the system boots)
> >
> > My kernel config doesn't have the BRIDGE option so I guess the
> > bridging code is part of ET's drivers.
>
In message <[EMAIL PROTECTED]>, Boris Popo
v writes:
> No, in the current implementation mb_get* functions will work
>properly. But mb_put* will fail. This can be avoided by implementing
>alignment-safe set* macros (which can be written in two variants - first
>form is for aligned objects an
Hello Peter Blok,
Monday, February 12, 2001, 00:21:56, you wrote:
PB> My DSL provider (KPN - mxstream) needs a PPTP connection. I am trying to
PB> use netgraph-mpd to make this work. Any experience good or bad with this?
mpd-netgraph _really_ _good_ software, ...but need some patches.
I'm rig
On Sun, Feb 11, 2001 at 01:55:16AM -0800, Alfred Perlstein wrote:
> The sysctl for somaxconn is an int, however the queue limits in the
> socket structures are 'short' this can cause some bad behavior if
> one sets somaxconn to more than 32k.
>
> A) So, do we bump the sockets to use 'int' for so
I have a question about brigding in FreeBSD:
I'm running a server with 3 NICs. I'd like to bridge packets only between
two interfaces, while the third one could still be used as interface that
is not bridged.
Interfaces are: ep0,xl0,de0.
Now i'd like to bridge packets only between xl0 and de0,
the method you suggest should work but you need a recent -stable
(as of feb.10 2001) to make it work as expected
cheers
luigi
>
> I'm running a server with 3 NICs. I'd like to bridge packets only between
> two interfaces, while the third one could still be used as interface that
Bill Paul writes:
> > > 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:
>
> You know, so far I've gotten close to a dozen replies to this e-mail,
> b
Kris Kennaway writes:
> Did you guys agree on a commit-worthy fix yet?
I wasn't party to the issue that generated this thread in the first
place, but.. I think the concensus is that if accept(2) returns
an error then this will break some applications, so instead it
should return a socket which w
On Mon, Feb 12, 2001 at 09:56:26AM -0800, Archie Cobbs wrote:
> Kris Kennaway writes:
> > Did you guys agree on a commit-worthy fix yet?
>
> I wasn't party to the issue that generated this thread in the first
> place, but.. I think the concensus is that if accept(2) returns
> an error then this
* Jonathan Lemon <[EMAIL PROTECTED]> [010212 06:46] wrote:
> On Sun, Feb 11, 2001 at 01:55:16AM -0800, Alfred Perlstein wrote:
> > The sysctl for somaxconn is an int, however the queue limits in the
> > socket structures are 'short' this can cause some bad behavior if
> > one sets somaxconn to mo
* Peter Wemm <[EMAIL PROTECTED]> [010211 05:30] wrote:
>
> For what it's worth, we found (at Yahoo) that excessively large listen
> queues tend to cause more problems than they solve. The circumstances are
> probably different, but we found that on one particular application, a
> queue of 10 was
> Date: Sat, 10 Feb 2001 15:29:17 +0100
> From: Rainer Clasen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: call for testers: port aggregation netgraph module
>
> On Thu, Feb 08, 2001 at 01:25:09PM -0800, Bill Paul wrote:
> > http://www.freebsd.org/~wpaul/FEC/
Jonathan Lemon writes:
> > > Did you guys agree on a commit-worthy fix yet?
> >
> > I wasn't party to the issue that generated this thread in the first
> > place, but.. I think the concensus is that if accept(2) returns
> > an error then this will break some applications, so instead it
> > shoul
>> No, as this is the current behavior. The change will be for accept
>> to return an error, on the basis that 1) most apps already do the
>> wrong thing now anyway, and 2) it brings us closer to a 'standard',
>> e.g.: what other systems are doing as well.
>
>I don't understand then.
>
>What is
On Mon, Feb 12, 2001 at 04:51:48PM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > > > Did you guys agree on a commit-worthy fix yet?
> > >
> > > I wasn't party to the issue that generated this thread in the first
> > > place, but.. I think the concensus is that if accept(2) returns
> >
> struct sockaddr_in sin;
>
> len = sizeof(sin);
> fd = accept(s, (struct sockaddr *)&sin, &len);
> if (fd == -1)
> err(1, "accept");
> printf("peer address: %s\n", inet_ntoa(sin.sin_addr));
>
>The bug with this code is that it blindly uses ``sin'' after
[EMAIL PROTECTED] writes:
> >And what do you mean by ``most apps already do the wrong thing now''?
>
> for background (like when this happens) see previous articles
> on this thread.
>
> current behavior: return 0-length sockaddr.
Yeah, that is totally broken.
Hmm.. how long
Jonathan Lemon writes:
> It seems to me that the odds of an application being able to correctly
> handle an error return from accept() are far greater than the odds that
> the code correctly checks 'len' upon return from accept. This, combined
> with the standard, seems to be rationale enough to
On Mon, Feb 12, 2001 at 06:34:29PM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > It seems to me that the odds of an application being able to correctly
> > handle an error return from accept() are far greater than the odds that
> > the code correctly checks 'len' upon return from accept
>> for background (like when this happens) see previous articles
>> on this thread.
>> current behavior: return 0-length sockaddr.
>Yeah, that is totally broken.
>Hmm.. how long has this been the "current behavior" ?
>ISTR at one time you would instead get the actual sockaddr of th
22 matches
Mail list logo
