On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote:
> Crist J. Clark writes:
> > No, RFC1122 is a set of requirements for hosts implementing _the
> > Internet protocol._
>
> OK...
>
> > > By your argument, the kernel should also block admin attempts to
> > > configure RFC 1918 addresse
On Tue, Feb 19, 2002 at 09:00:42AM +0200, Girnet Vladimir wrote:
> >
> OK, I use such rulez:
> ipfw pipe 10 config bw 33600bit/s queue 5K
> ipfw pipe 11 config bw 64Kbit/s queue 10K
> ipfw pipe 12 config bw 128Kbit/s queue 15K
>
> and, the rule - ipfw add 500 pipe XX ip from any to a.b.c.d/e
> -Original Message-
> From: Luigi Rizzo [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 19, 2002 8:38 AM
> To: Girnet Vladimir
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: network buffer problem
>
>
> On Tue, Feb 19, 2002 at 08:21:01AM +0200, Girnet Vladimir wrote:
> >
> > I found,
On Tue, Feb 19, 2002 at 08:21:01AM +0200, Girnet Vladimir wrote:
>
> I found, that NO_MATTER what type of interface do you use on FreeBSD 4.5R.
> When DUMMYNET is enabled, and use some pipe rulez, ping with packets more
> than 4096 always got
> ping: sendto: No buffer space available
The "al
>On Mon, 18 Feb 2002, Randy Bush wrote:
> > If you have 4.5 and enough memory one option is to use
> > MAXUSERS=0 and remove and "options NMBCLUSTERS"
>>
>> that's how it is now.
>>
>> before the latest builds, it uses to be MAXUSERS=96. maybe i should
>> revert that.
>>
>> and i have to open t
Justin Hawkins writes:
> > Yes, this is the same problem. Mpd and the kernel have both
> > been modified since that posting:
> >
> > - mpd will disallow the 'fatal' scenario
> > - the 'fatal' scenario is no longer fatal, i.e., instead of the
> > kernel panicing, it will just return the 'deadlock
Crist J. Clark writes:
> No, RFC1122 is a set of requirements for hosts implementing _the
> Internet protocol._
OK...
> > By your argument, the kernel should also block admin attempts to
> > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an
> > interface. That would put a lot of p
I suggest that you get Archie to walk over to the next desk and
ask Van Jacobson. There's nothing like getting it from the
Horse's mouth (so to speak).
On Mon, 18 Feb 2002, Crist J. Clark wrote:
> On Mon, Feb 18, 2002 at 07:02:48PM -0800, Archie Cobbs wrote:
> >
> > Note that the RFC you are h
On Mon, Feb 18, 2002 at 07:02:48PM -0800, Archie Cobbs wrote:
> Ruslan Ermilov writes:
> > > > ping -s 127.1 1.2.3.4
> > > > telnet -S 127.1 1.2.3.4
> > >
> > > If someone explicitly overrides source-address selection, they are
> > > presumed to know WTF they are doing, and the kernel should not
On Mon, 18 Feb 2002, Randy Bush wrote:
> > If you have 4.5 and enough memory one option is to use
> > MAXUSERS=0 and remove and "options NMBCLUSTERS"
>
> that's how it is now.
>
> before the latest builds, it uses to be MAXUSERS=96. maybe i should
> revert that.
>
> and i have to open the box s
> As i suspected, you have a quite small number of mbuf clusters
> in the system. I am unsure on how much memory you have and how
> your box is used, but mbufs are used quite a bit in the system.
128mb
heavy net use: apache/ssl servers, 100k/day email service, ...
> If you have 4.5 and enough me
On Mon, 18 Feb 2002, Archie Cobbs wrote:
> Yes, this is the same problem. Mpd and the kernel have both
> been modified since that posting:
>
> - mpd will disallow the 'fatal' scenario
> - the 'fatal' scenario is no longer fatal, i.e., instead of the
> kernel panicing, it will just return the 'd
Ruslan Ermilov writes:
> > > ping -s 127.1 1.2.3.4
> > > telnet -S 127.1 1.2.3.4
> >
> > If someone explicitly overrides source-address selection, they are
> > presumed to know WTF they are doing, and the kernel should not be
> > trying to second-guess them.
> >
> That "someone" could be a bad g
Lars Eggert writes:
> this doesn't look like the same bug described in the link you posted.
> The other bug caused negotiation to completely fail, while it succeeds
> in your case.
>
> Looks like there's something else wring. What does your ifconfig look
> like after the link is up?
>
> > I'm t
As i suspected, you have a quite small number of mbuf clusters
in the system. I am unsure on how much memory you have and how
your box is used, but mbufs are used quite a bit in the system.
Each fxp device allocates 64 clusters in the receive queue, and can have
up to 128 in the NIC transmit queu
Ok, I have refrained from jumping into this thread but
the noise is increasing and I think some clarifications are
really necessary now.
First of all: at various levels in the protocol stack, when
a packet cannot be forwarded to the next layer, more often
than not a ENOBUFS error is returned, wh
>> /kernel: fxp0: cluster allocation failed, packet dropped!
>> /kernel: m_clalloc failed, consider increase NMBCLUSTERS value
> can you show the output of "netstat -m" ?
# netstat -m
306/2352/6016 mbufs in use (current/peak/max):
264 mbufs allocated to data
Well it could be mpd, but my good old friend ;-) tested a view things.
First he used DUMMYNET to simulate his ADSL connection in a LAN environment
(100baseT)
So he put in some packet loss and bandwidth limitations on his LAN and
started pinging some hosts. He gets the same result of packets be
On Mon, Feb 18, 2002 at 04:21:14PM -0800, Randy Bush wrote:
> i had a jillion of these the other day while i was out of town.
>
> /kernel: fxp0: cluster allocation failed, packet dropped!
> /kernel: m_clalloc failed, consider increase NMBCLUSTERS value
>
> no net access, of course. it
i had a jillion of these the other day while i was out of town.
/kernel: fxp0: cluster allocation failed, packet dropped!
/kernel: m_clalloc failed, consider increase NMBCLUSTERS value
no net access, of course. it cleared itself up, no reboot. been running
for five days since the pro
Just for the record, this one bit me (with an xl card) last week. It
had never happened with 4.4-Release on the same system (my office
desktop) but happened about a week after installing
4.5-Release. netstat -m showed no problems, but I could not ping, open
an ssh connection to a remote system or
On Mon, 18 Feb 2002, Mike Silbersack wrote:
> be looking at. If by chance a mpd guru does not wander into this thread,
> I suggest that you look through the old mailing list archives, see who
> has had experience with it before, and drop them an e-mail.
contact [EMAIL PROTECTED]
To Unsubscr
On Mon, 18 Feb 2002, Marcel de Vries wrote:
> I really want to make a point, is it third party software mpd-3.7
> Multi-link PPP daemon based on netgraph(4) that is causing this or is it
> something in the TCP/IP stack of BSD that is changed or the driver support.
>
> We had these problems in
Thanks for the quick reply.
But I want to come back first about the identical system a friend of my is
using only with the xl driver for his public interface.
But today he told me when pinging to a host like ping -s 4096 www.bart.nl
and meanwhile enjoying the sound from the digitally imported sh
>> The only real "cisco only" protocol is the PAgP (Port Aggregation
>> Protocol) which is essentially just a FEC auto-negiotation protocol they
>> made up. AFAIK noone other then Cisco actually implements this though.
> Don't forget to add EIGRP and CDP to the list. -sc
actually, the one with
> The only real "cisco only" protocol is the PAgP (Port Aggregation
> Protocol) which is essentially just a FEC auto-negiotation protocol they
> made up. AFAIK noone other then Cisco actually implements this though.
Don't forget to add EIGRP and CDP to the list. -sc
--
Sean Chittenden
To Un
I've been working on adding support for Netgears GA621 Gigabit Fiber card.
I basically have it working. I'm still trying to refine the link
detection code. I have been able to connect it to some other fiber card
via a cross-over cable and send packets back and forth. I have some more
testing to
Yes. I was going to commit this fix to -stable at bsdcon, but the
number of problem laptops that I wanted to look at closely didn't
allow it.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Mon, 18 Feb 2002, Marcel de Vries wrote:
> Hi all,
>
> I'm getting alot of buffer problems with my internet connection.
>
> I'm using a (Dutch) Mxstream ADSL for Broadband internet connection.
> The ISDN Alcatel ADSL modem is loaded with firmware: Active : GSV7AA3.270
>
> Setting NMBClusters
Hi,
Thanks for your reply.
added sysctl,
Set the default value's of 4.3 in the kernel.
net.inet.tcp.sendspace=16384
net.inet.tcp.recvspace=16384
But still no buffer space messages when pinging a host.
Can I try something else?
also tried to lower udp.recvspace, but did not help :(
But I neve
Hi all,
I'm getting alot of buffer problems with my internet connection.
I'm using a (Dutch) Mxstream ADSL for Broadband internet connection.
The ISDN Alcatel ADSL modem is loaded with firmware: Active : GSV7AA3.270
As you can see below I'm using mpd-netgraph for PPTP to connect on the ADSL
mo
> > ng_fec needs a cisco at the other end (or possibly another freebsd
> > machine with ng_fec but I don't know that).
Fast EtherChannel doesn't actually require a Cisco device on the other
side, it is really just a "non-standardized standard" for the hashing
that decides which physical interfa
32 matches
Mail list logo
