Has anyone looked at kern/68110?
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110
Jon Noack
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hi Andre,
On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote:
> Here is the next preview patch for the ipfw to pfil_hooks conversion:
>
> http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
>
> This patch significantly cleans up ip_input.c and ip_output.c.
>
> The following is
Andre Oppermann wrote:
> Here is the next preview patch for the ipfw to pfil_hooks conversion:
>
> http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
>
> This patch significantly cleans up ip_input.c and ip_output.c.
That would be a very a nice thing, but it looks like this bre
On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote:
...
> > Consider this a FYI. It is very much a WIP at the moment. I want
> > to get this into the tree in before 5.3 code freeze.
>
> In fact, our real world tests shown the current -CURRENT comparing to
> RELENG_5_2 is in a very b
Maxim Konovalov <[EMAIL PROTECTED]> writes:
> In fact, our real world tests shown the current -CURRENT comparing to
> RELENG_5_2 is in a very bad shape.
You'll have to substantiate that. All *my* real world tests show that
-CURRENT is a lot more stable and functional than RELENG_5_2.
>
On Tue, 22 Jun 2004, 11:23+0200, Dag-Erling Sm?rgrav wrote:
> Maxim Konovalov <[EMAIL PROTECTED]> writes:
> > In fact, our real world tests shown the current -CURRENT comparing to
> > RELENG_5_2 is in a very bad shape.
>
> You'll have to substantiate that. All *my* real world tests show that
> -C
On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote:
> On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote:
> ...
> > > Consider this a FYI. It is very much a WIP at the moment. I want
> > > to get this into the tree in before 5.3 code freeze.
> >
> > In fact, our real world tests sho
Maxim Konovalov <[EMAIL PROTECTED]> writes:
> Yesterday -CURRENT leaks kernel memory very quickly and panics after
> 10 - 15 mins up.
Nope. That bug was introduced on June 9th, almost two weeks ago, and
it was fixed less than twelve hours later. I have several machines
already running yesterday'
On Mon, Jun 21, 2004 at 11:36:21PM +0200, Andre Oppermann wrote:
> Here is the next preview patch for the ipfw to pfil_hooks conversion:
>
> http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
>
> This patch significantly cleans up ip_input.c and ip_output.c.
>
assorted comment
- Original Message -
From: "Andre Oppermann" <[EMAIL PROTECTED]>
Sent: Monday, June 21, 2004 11:36 PM
> This patch significantly cleans up ip_input.c and ip_output.c.
>
> The following is included in this patch:
>
> o Remove all ipfw related cruft from ip_input() and ip_output()
> o
On Tue, 22 Jun 2004, 11:49+0200, Dag-Erling Sm?rgrav wrote:
> Maxim Konovalov <[EMAIL PROTECTED]> writes:
> > Yesterday -CURRENT leaks kernel memory very quickly and panics after
> > 10 - 15 mins up.
>
> Nope. That bug was introduced on June 9th, almost two weeks ago, and
Nope :-)
$ ident /usr/
Maxim Konovalov <[EMAIL PROTECTED]> writes:
> $ ident /usr/src-5-current/sys/kern/uipc_syscalls.c
Wrong file - but this is pointless, anyway. You are generalizing from
a single data point. I can show you a room full of servers that can't
run 5.2.1 due to bugs in the ACPI support code and in two
Jon Noack wrote:
>
> Has anyone looked at kern/68110?
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110
The situation is a little bit complicated. I agree that having RFC3522
is a good thing.
However there is a political problem with the author of the rfc3522 of
DFBSD. He is also still a
Maxim Konovalov wrote:
>
> Hi Andre,
>
> On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote:
>
> > Here is the next preview patch for the ipfw to pfil_hooks conversion:
> >
> > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
> >
> > This patch significantly cleans up ip_i
Ian FREISLICH wrote:
>
> Andre Oppermann wrote:
> > Here is the next preview patch for the ipfw to pfil_hooks conversion:
> >
> > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
> >
> > This patch significantly cleans up ip_input.c and ip_output.c.
>
> That would be a very a
Maxim Konovalov wrote:
>
> On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote:
>
> > On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote:
> > ...
> > > > Consider this a FYI. It is very much a WIP at the moment. I want
> > > > to get this into the tree in before 5.3 code freeze.
> >
Angelo Turetta wrote:
>
> - Original Message -
> From: "Andre Oppermann" <[EMAIL PROTECTED]>
> Sent: Monday, June 21, 2004 11:36 PM
>
> > This patch significantly cleans up ip_input.c and ip_output.c.
> >
> > The following is included in this patch:
> >
> > o Remove all ipfw related cru
Andre Oppermann wrote:
> > There have been about 5 PRs (most with patches) in the past years
> > which all claim to fix this problem indicating that here is a need
> > for a fix. We rely on the fix in kern/64240 to collect traffic
> > accounting information for billing and statistical purposes. T
Luigi Rizzo wrote:
>
> On Mon, Jun 21, 2004 at 11:36:21PM +0200, Andre Oppermann wrote:
> > Here is the next preview patch for the ipfw to pfil_hooks conversion:
> >
> > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
> >
> > This patch significantly cleans up ip_input.c and i
On Tue, 22 Jun 2004, 13:38+0200, Andre Oppermann wrote:
> Maxim Konovalov wrote:
> >
> > Hi Andre,
> >
> > On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote:
> >
> > > Here is the next preview patch for the ipfw to pfil_hooks conversion:
> > >
> > > http://www.nrg4u.com/freebsd/ipfw-pfilhook
I tried the ng_pppoe.c, ng_pppoe.h from latest STABLE.
But got compile errors. Instead of tracing the source
i just downloaded the 4.10 STABLE and ITS WORKING.
Seems the problem was exactly as pointed out. Gleb
thanks a TON for keeping my hopes alive with your
prompt replies. I dont have to get ba
Hi all,
Whilst scanning GNATS, I found a number of PRs relating to requests
for tcp_wrappers functionality and some outright bugfixes. Rather than
commit these as-is, I think we should push the changes back to Wietse,
as we maintain tcp_wrappers on a vendor branch.
The PRs in question are:
http:
Synopsis: TCP's advertised window is not scaled immediately upon discovering use of
Window scale option
Responsible-Changed-From-To: jlemon->freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Tue Jun 22 15:42:10 GMT 2004
Responsible-Changed-Why:
Throw this one over to the -net lis
Synopsis: proper TCP_NOPUSH/TCP_CORK compatibility
Responsible-Changed-From-To: jesper->freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Tue Jun 22 15:48:52 GMT 2004
Responsible-Changed-Why:
Throw this one open to the -net list
http://www.freebsd.org/cgi/query-pr.cgi?pr=24959
__
Hi,
> On Tue, 22 Jun 2004 16:32:07 +0100
> Bruce M Simpson <[EMAIL PROTECTED]> said:
bms> Whilst scanning GNATS, I found a number of PRs relating to requests
bms> for tcp_wrappers functionality and some outright bugfixes. Rather than
bms> commit these as-is, I think we should push the ch
Synopsis: IPsec transport mode precludes filtering on underlying transport header
Responsible-Changed-From-To: guido->net
Responsible-Changed-By: bms
Responsible-Changed-When: Tue Jun 22 16:48:10 GMT 2004
Responsible-Changed-Why:
Seems relevant to current work being done by andre@ and
others in t
On Wed, 23 Jun 2004, Hajimu UMEMOTO wrote:
> > On Tue, 22 Jun 2004 16:32:07 +0100
> > Bruce M Simpson <[EMAIL PROTECTED]> said:
>
> bms> Whilst scanning GNATS, I found a number of PRs relating to requests
> bms> for tcp_wrappers functionality and some outright bugfixes. Rather than
> bms>
<><><><>NETWORK CONFIG/SETUP: <><><><>
+++ISP -> DSL(high-speed) -> Modem> FreeBSD51 server machine in at Gateway "vr0"
(192.168.0.1)
+++Freebsd machine LAN Interface at "ed0" (192.168.0.3) -> HUB
+++HUB> 1) 192.168.0.2 - WinXP #1 machine 2) 192.168.0.3 - Freebsd machine in at "ed0"
3) 192.16
Hi,
Historically the Rhyolite routed has resided in src/sbin/routed.
However, this code is maintained on a vendor branch, and as such,
should really reside in src/contrib/routed and be referenced by
the Makefile in src/sbin/routed accordingly.
Would we be able to move it with a repocopy? Or woul
On Sun, Jun 20, 2004 at 06:52:05PM +0100, David Malone wrote:
> On Sun, Jun 20, 2004 at 02:54:34PM +0100, Josef Karthauser wrote:
> > I should have said that the atheros web site states that the 511T and
> > the 311T use the same chipset, which is the AR5002G, but that the
>
> I know someone with
I applied the attached patch to -CURRENT from around April which is
currently running on my local CVS server. Basic tests with sshd and
ftp didn't result in any unexpected behaviour. I suspect I really need
to be running an application similar to the one Jayanth is running
to unravel things further
On Tue, 22 Jun 2004, Bruce M Simpson wrote:
> I applied the attached patch to -CURRENT from around April which is
> currently running on my local CVS server. Basic tests with sshd and ftp
> didn't result in any unexpected behaviour. I suspect I really need to be
> running an application similar t
On Tue, 22 Jun 2004, Ian FREISLICH wrote:
> Andre Oppermann wrote:
> > Here is the next preview patch for the ipfw to pfil_hooks conversion:
> >
> > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
> >
> > This patch significantly cleans up ip_input.c and ip_output.c.
>
>
Just to note that I've posted you feedback on this patch off-list.
Regards,
BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tue, Jun 22, 2004 at 07:11:19PM -0400, Robert Watson wrote:
> so->so_state |= (head->so_state & SS_NBIO);
In the end this is what it boils down to. I've committed this and
an appropriate manual page update.
Regards,
BMS
___
[EMAIL PROTECTED] ma
On Wed, 23 Jun 2004, Bruce M Simpson wrote:
> On Tue, Jun 22, 2004 at 07:11:19PM -0400, Robert Watson wrote:
> > so->so_state |= (head->so_state & SS_NBIO);
>
> In the end this is what it boils down to. I've committed this and an
> appropriate manual page update.
Since you're looking at th
On Tue, Jun 22, 2004 at 09:04:35PM -0400, Robert Watson wrote:
> Since you're looking at the propagation of head so_state to new socket
> so_state, you might want to look at the similar statement in sonewconn(),
> which copies so_state from head to the new socket, and adds the SS_NOFDREF
> flag. S
On Tuesday 22 June 2004 02:27 pm, Bruce M Simpson wrote:
> Hi,
>
> Historically the Rhyolite routed has resided in src/sbin/routed.
>
> However, this code is maintained on a vendor branch, and as such,
> should really reside in src/contrib/routed and be referenced by
> the Makefile in src/sbin/rout
Hello,
I am looking at methods to rate limit a single socket to a specific
pipe or rate with FreeBSD. I would like to make an Apache module that
could do its outgoing rate limit *in* kernel, making the module very
simple, and more accurate by using the kernel todo the rate limiting.
I hav
hi,
(B
(Bplease take a look at mod_netnice. it uses netnice, another in-kernel
(Btraffic control primitive on the platform. since you can control each
(Bsocket with netnice, i think it's easy to extend the module to meet
(Byour needs.
(B
(Bhttp://www.netnice.org/app_modnetnice.html
On Fri, Jun 18, 2004 at 05:08:40PM -0400, Barney Wolff wrote:
> Pardon an ignorant question, but what happens to unfortunate people who
> have to talk to both Linux and non-quirky servers at the same time? Is
> there a way to detect what flavor of server you're talking to and adjust
> accordingly?
On Fri, Jun 18, 2004 at 05:35:07PM -0500, Dan Nelson wrote:
> Linux kernels 2.4.26 and above have fixed this particular bug, so the
> need for a compatibility hack on our end is not as great anymore.
Agreed. I have abandoned work on this for now. If anyone is in desperate
need for this, I can re-j
Andre Oppermann <[EMAIL PROTECTED]> said:
> Jon Noack wrote:
> >
> > Has anyone looked at kern/68110?
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110
> The situation is a little bit complicated. I agree that having RFC3522
> is a good thing.
> However there is a political problem with
On Tue, 2004-06-22 at 23:55 -0400, Takashi Okumura wrote:
> hi,
>
> please take a look at mod_netnice. it uses netnice, another in-kernel
> traffic control primitive on the platform. since you can control each
> socket with netnice, i think it's easy to extend the module to meet
> your needs.
>
>
44 matches
Mail list logo
