Alexander Motin wrote:
Alex Povolotsky wrote:
And, again, please show me your mpd.conf
Attached.
Thanks a lot; watchdog is armed, WITNESS and INVARIANTS on, running...
Alex.
___
freebsd-net@freebsd.org mailing list
Hello.
I've got the following problem...
My host is configured like this:
fxp0: internal interface, requires NAT
rl1: public interface, with static IP
xl0: bridged to rl1, with some public IP behind
ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw
50 divert 8668 ip from any to
Alexander Motin wrote:
Alex Povolotsky wrote:
And, again, please show me your mpd.conf
Attached.
Thanks, it seems to be more or less stable; however, throughput is quite
little, lots of packets lost and No buffer space available on attempt
to ping VPN addresses (only VPN is affected).
I
Alex Povolotsky wrote:
Thanks, it seems to be more or less stable; however, throughput is quite
little, lots of packets lost and No buffer space available on attempt
to ping VPN addresses (only VPN is affected).
Have you tried to disable PPTP windowing in mpd config? ENOBUFS is the
errno
Alexander Motin wrote:
Alex Povolotsky wrote:
Thanks, it seems to be more or less stable; however, throughput is
quite little, lots of packets lost and No buffer space available on
attempt to ping VPN addresses (only VPN is affected).
Have you tried to disable PPTP windowing in mpd config?
If memory serves me right, Andrea Venturoli wrote:
Hello.
I've got the following problem...
My host is configured like this:
fxp0: internal interface, requires NAT
rl1: public interface, with static IP
xl0: bridged to rl1, with some public IP behind
ipfw diverts any traffic through rl1
Alex Povolotsky wrote:
After disabling windowing and setting net.graph's, mpd4 refuses to work
and no ng interfaces ever created
lowering both tunables to 128000 solved the problem, will look more.
Oops! I have missed
kern.ipc.maxsockbuf=1048576
, which is required before those two tunes.
Bruce A. Mah wrote:
You didn't say which bridging driver or version of FreeBSD you're using,
but it sounds to me like you're using bridge(4), right?
Yes.
This is a
fairly well known problem, which I wrote a little bit about here:
On Wed, 21 Feb 2007, Julian Elischer wrote:
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
I have an Internet proxy that is running FreeBSD 5.4-RELEASE. This server has
been up and running beautifully for about a year and a half with no issues.
Just the other day I had a user try to connect to a host on the Internet and
her connection was failing. At first I thought that it
On Feb 22, 2007, at 1:45 PM, Jeremy Nelson wrote:
I have an Internet proxy that is running FreeBSD 5.4-RELEASE. This
server has been up and running beautifully for about a year and a
half with no issues.
Just the other day I had a user try to connect to a host on the
Internet and her
Hello!
Thanks to all who helped, I'm progressing.
The box seems to be unstable, however, it reboots with watchdog, not freeze.
After boot, I'm getting a message
Feb 22 20:58:12 gw kernel: Memory modified after free 0xc4524000(2048)
val=a028c0de @ 0xc4524000
Feb 22 20:58:12 gw kernel: Memory
Hello everyone,
I was wondering if you could help me with this one. I am
trying to do this one without any luck. How do you remote
install FReeBSD using FreeBSD? There doesn't seem to be any
documentation around to help me. No Step 1, Step 2 , Step 3 guide.
I have searched the web and
Rajen Jani (BT Yahoo! Broadband) wrote:
Hello everyone,
I was wondering if you could help me with this one. I am
trying to do this one without any luck. How do you remote
install FReeBSD using FreeBSD? There doesn't seem to be any
documentation around to help me. No Step 1, Step 2 ,
Hi Folks,
I am coming across a weird issue with FreeBSD 6.1, any help appreciated.
The problem is the following:
One thread (1) does a setsockopt, grabs a lock in udp_usrreq, calls
copyin which hits a pagefault, this leads to that thread sleeping by
calling msleep.
If memory serves me right, Andrea Venturoli wrote:
Bruce A. Mah wrote:
You didn't say which bridging driver or version of FreeBSD you're using,
but it sounds to me like you're using bridge(4), right?
Yes.
This is a
fairly well known problem, which I wrote a little bit about here:
To somehow limit searching area, I think you should try to disable all
possible additional functions like netflow, tee, DialOnDemand,
tcpmssfix, nat, vjcomp, compression, encryption and everything else you
have and can disable for some time without harm.
--
Alexander Motin [EMAIL PROTECTED]
17 matches
Mail list logo