Ian Smith wrote:
On Tue, 20 Feb 2007, Julian Elischer wrote:
admin wrote:
Wrong: the implied check-state done by the limit lets the connection
through (i.e. performs the action) iff there's state recorded for it
(src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet
Hi list,
A late followup on this issue. Due to physical location constraints
and production environment, I finally have the chance to relook into
this issue. I'm planning to perform these actions tomorrow:-
1. Apply Doug's IPMI patches from
http://www.ambrisko.com/doug/bge_ipmi.patch (actually
Hello Alex,
Tuesday, February 20, 2007, 6:35:14 PM, you wrote:
AP RELATIVELY easy. It happens about once a day or more often; but it
AP requires someone to press Reset.
I had the same problem with mpd4.0b3 and mpd4.0b4 and Freebsd built
from RELENG_6 branch at the beggining of the year. I used
Alex Povolotsky wrote:
Is there anybody here who can say I'm running mpd with 400 pptp
connections, and it works without a flaw?
I am running 100 mpd servers, and they work without a flaw.
I mean 400 ACTIVE connections.
And I have 10k PPPoE users and some amount of PPTP. I have 700 ACTIVE
Alexander Motin wrote:
Alex Povolotsky wrote:
Is there anybody here who can say I'm running mpd with 400 pptp
connections, and it works without a flaw?
I am running 100 mpd servers, and they work without a flaw.
I mean 400 ACTIVE connections.
And I have 10k PPPoE users and some amount of
Alex Povolotsky wrote:
Hmm... May I ask you to show your dmesg, kernel config and mpd configs?
I have heard several rumors about system lockup with mpd.
I have heard only one and that person answered me that problem was
solved by avoiding of routing loop, when tunnel traffic was routed
Alexander Motin wrote:
Alex Povolotsky wrote:
Hmm... May I ask you to show your dmesg, kernel config and mpd
configs? I have heard several rumors about system lockup with mpd.
I have heard only one and that person answered me that problem was
solved by avoiding of routing loop, when tunnel
Alex Povolotsky wrote:
And, again, please show me your mpd.conf
Attached.
--
Alexander Motin [EMAIL PROTECTED]
Optima Telecom
default:
log -bund -fsm -lcp
set console ip 127.0.0.1
set console user xxx yyy
set console open
set netflow node netflow
http://wiki.freebsd.org/NetworkRfcCompliance
Please begin wiki-whacking!
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
--- Bruce M. Simpson [EMAIL PROTECTED] wrote:
satimis wrote:
Hi folks,
FreeBSD-6.2-amd64
...
The onboard NIC seems not detected.
In the absence of required information, I speculate your machine has
msk(4) or another recent chipset which may be supported in
FreeBSD-CURRENT
On Wed, Feb 21, 2007 at 02:50:27PM +, Bruce M Simpson wrote:
http://wiki.freebsd.org/NetworkRfcCompliance
before it is too late to change, maybe it is the case to
spell RFC as all capital letters ?
As it is now, i misread it as NetworkRfCompliance and thought
it was something related to
Luigi Rizzo wrote:
On Wed, Feb 21, 2007 at 02:50:27PM +, Bruce M Simpson wrote:
http://wiki.freebsd.org/NetworkRfcCompliance
before it is too late to change, maybe it is the case to
spell RFC as all capital letters ?
It would surely be better named NetworkStandardsCompliance as
Hi,
I'm not sure if this is really a bug but it doesn't look all fine to me.
When I do a /etc/rc.d/netif restart it does restart the network
interfaces but doesn't replace the default route that it just erased
even if it is specified in rc.conf correctly. I found that I should also
restart
Ian Smith wrote:
On Tue, 20 Feb 2007, Julian Elischer wrote:
admin wrote:
Wrong: the implied check-state done by the limit lets the connection
through (i.e. performs the action) iff there's state recorded for it
(src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet
Synopsis: Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Wed Feb 21 20:36:28 UTC 2007
Responsible-Changed-Why:
Over to maintainer.
Martin Turgeon wrote this message on Wed, Feb 21, 2007 at 11:55 -0500:
I'm not sure if this is really a bug but it doesn't look all fine to me.
When I do a /etc/rc.d/netif restart it does restart the network
interfaces but doesn't replace the default route that it just erased
even if it is
Kevin Downey a écrit :
On 2/21/07, Martin Turgeon [EMAIL PROTECTED] wrote:
Hi,
I'm not sure if this is really a bug but it doesn't look all fine to me.
When I do a /etc/rc.d/netif restart it does restart the network
interfaces but doesn't replace the default route that it just erased
even if
John-Mark Gurney a écrit :
Martin Turgeon wrote this message on Wed, Feb 21, 2007 at 11:55 -0500:
I'm not sure if this is really a bug but it doesn't look all fine to me.
When I do a /etc/rc.d/netif restart it does restart the network
interfaces but doesn't replace the default route
18 matches
Mail list logo
