Hi,
Here is a proof-of-concept patch that adds sockets related statistics to
netstat(1)'s -m option, which could make SA's life easier. Inspired by
a local user's suggestion.
Comments?
Cheers,
--
Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/
FreeBSD - The Power to Serve!
Index: mbuf.
Hi,
Please try the attached patch, which mimics exactly what the Kame code
used to do. I have not fully tested it, but it builds and runs.
I will need some time to reproduce the panic you saw on one of my
boxes. If you can tell me the steps you took to get that to happen
that would be great.
B
At Wed, 29 Aug 2007 00:28:47 +0900,
jinmei wrote:
>
> At Tue, 28 Aug 2007 19:49:11 +0800,
> blue <[EMAIL PROTECTED]> wrote:
>
> > According to the GDB backtrace, I think this is what I am talking about.
> >
> > Besides, this would result in infinite loop just by looking at the
> > codes. Howeve
Jeffrey Williams wrote:
> I have a server with two interfaces, I want to run the host and a couple of
> jails using one interface on one subnet (internal interface, private IP,
> behind
> NAT/firewall) and some other jails using the other interface on another
> subnet
> (external interface, pu
I have a server with two interfaces, I want to run the host and a couple
of jails using one interface on one subnet (internal interface, private
IP, behind NAT/firewall) and some other jails using the other interface
on another subnet (external interface, public IP, DMZ).
Now my understanding
On Tue, Aug 28, 2007 at 03:51:25PM -0500, Sean C. Farley wrote:
> I currently have a setup on a laptop where I have two aliases that I
> always want present. I would like to setup two aliases in
> /etc/dhclient.conf to handle having the Ethernet cable plugged in after
> boot, but dhclient has
I currently have a setup on a laptop where I have two aliases that I
always want present. I would like to setup two aliases in
/etc/dhclient.conf to handle having the Ethernet cable plugged in after
boot, but dhclient has a limit of handling only one alias.
/etc/rc.conf
ifconfig_xl0="DHCP"
ifcon
Weiguang Shi wrote:
nc might be waiting on all the interfaces; enumerating MTUs and choosing the
largest
sounds complicated, especially when some interfaces can be configured to receive
jumbo frames. Why not just use something like 64KB as the other user
suggested or something even larger?
Christian S.J. Peron wrote:
I am not sure who has their hands in the routing code these days so
I figured I would just forward this message off here. Does the
following look reasonable?
I'm looking, but mostly with long range goggles on.
Yes, this looks like the right change. rtalloc1() alw
(1) We have released some traces from LBNL at:
http://www.icir.org/enterprise-tracing/
(2) See datcat.org for an index.
(3) The CRAWDAD traces from:
http://crawdad.cs.dartmouth.edu/
allman
pgpk1PAPx7ern.pgp
Description: PGP signature
I am not sure who has their hands in the routing code these days so
I figured I would just forward this message off here. Does the
following look reasonable?
- Forwarded message from "Christian S.J. Peron" <[EMAIL PROTECTED]> -
From: "Christian S.J. Peron" <[EMAIL PROTECTED]>
To: Yuri
nc might be waiting on all the interfaces; enumerating MTUs and choosing the
largest
sounds complicated, especially when some interfaces can be configured to
receive
jumbo frames. Why not just use something like 64KB as the other user
suggested or something even larger?
- Original Message -
At Tue, 28 Aug 2007 19:49:11 +0800,
blue <[EMAIL PROTECTED]> wrote:
> According to the GDB backtrace, I think this is what I am talking about.
>
> Besides, this would result in infinite loop just by looking at the
> codes. However, the author seems knowing the problem, too. The comments
> in es
Hi,
According to the GDB backtrace, I think this is what I am talking about.
Besides, this would result in infinite loop just by looking at the
codes. However, the author seems knowing the problem, too. The comments
in esp6_ctlinput() point out:
/*
* Although pfctlinput2 will
Thanks for the answers. I must have missed that part of carp(4).
On Tue, Aug 28, 2007 at 11:44:29AM +0200, Daniel Hartmeier wrote:
> On Tue, Aug 28, 2007 at 11:29:31AM +0200, Gergely CZUCZY wrote:
>
> > On a dual-carp scenario on two gateways when both the internal and
> > the external IFs are ca
On Tue, Aug 28, 2007 at 11:29:31AM +0200, Gergely CZUCZY wrote:
> On a dual-carp scenario on two gateways when both the internal and
> the external IFs are carp(4)'d in a master-slave way and a link
> disconnects only on one side, would this trigger a carp failover
> of the other interface also?
Hello
This question just popped out of my head today when playing
around with linux's LVS and keepalived.
On a dual-carp scenario on two gateways when both the internal and
the external IFs are carp(4)'d in a master-slave way and a link
disconnects only on one side, would this trigger a carp fail
On Tue, 28 Aug 2007, blue wrote:
Hi,
Since our device adopts the IPsec codes from BSD, our device will have
infinite loop after receiving ICMP packet too big message.
I am not sure whether BSD itself will have the problem or not (maybe needs
further testing). In IPSEC, esp6_ctlinput() still c
Looks like a netcat bug, if it doesn't tune buffers to the interface MTU.
I'm not sure if nc has a 'de facto' maintainer however I believe it is
something which was recently imported into the freebsd base system.
Still, it is better to try to field patches with the upstream maintainer
before
19 matches
Mail list logo
