Hi all,
Not a complete stranger to the project, I hope the following
'advertisement' will be appropriate here.
When sometime around 2007 I finally had to make real sense of IPv6, I
found a magic garden where brilliant ideas bloomed, and I felt it
would be a shame to have all that beauty only to m
The following reply was made to PR kern/146792; it has been noted by GNATS.
From: Yar Tikhiy
To: bug-follo...@freebsd.org
Cc: km...@freebsd.org
Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load
Date: Wed, 22 Sep 2010 07:00:47 +1000
FWIW, this flowtable problem still c
On Tue, Apr 10, 2007 at 06:35:39AM +0100, Bruce M Simpson wrote:
> Yar Tikhiy wrote:
> >Quagga still uses it, too, if its configure script detects FreeBSD
> >or NetBSD. I'm afraid it was me who submitted the patch to the
> >Quagga folks when I'd found that
On Wed, Apr 18, 2007 at 11:50:09AM +1000, Alan Garfield wrote:
> Hi all!
>
> One word HOW! :)
>
> I've no clue what this FreeBSD ARP stuff is all about, there is little
> or no documentation, there are 14 different sock_addr's which seem to
> have a bazillion different fields, and I cannot ou
On Thu, Apr 19, 2007 at 11:56:54AM +1000, Alan Garfield wrote:
> On Wed, 2007-04-18 at 16:06 +0400, Yar Tikhiy wrote:
> >
> > > I just want an idea of the structures involved, and what I need to
> > > implement to intercept and injecting a fake MAC so my buffer driver
On Thu, Apr 19, 2007 at 06:54:23PM +1000, Alan Garfield wrote:
> On Thu, 2007-04-19 at 11:35 +0400, Yar Tikhiy wrote:
>
> > > ... and I get these ARP errors.
> > >
> > >
> > > jnet0: port 0xa8,0xae-0xaf irq 19 on
> > > acpi0
> >
On Thu, Apr 19, 2007 at 07:51:13PM +1000, Alan Garfield wrote:
[...]
>
> > > I beginning to think the ARP issue is a symptom not the cause. The cause
> > > may well be something is wrong with my initialisation of the output
> > > queue and my handling of the de-queueing packets. I've looked at man
On Thu, Apr 19, 2007 at 11:50:00PM +1000, Alan Garfield wrote:
[...]
>
> BUT! Now I have a weird bug.
>
> SSH on the SP whinges about :-
>
>
> localhost $ ssh -v 169.254.101.3
> OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
> debug1: Reading configuration data /etc/ssh/ssh_config
On Sat, Apr 21, 2007 at 12:03:25AM +1000, Alan Garfield wrote:
> On Thu, 2007-04-19 at 21:53 +0400, Yar Tikhiy wrote:
>
> > 1. Ping the Linux side with packets close to the MTU in size (ping
> > -s), use different data patterns (ping -p), see with tcpdump -X if
> &g
On Mon, Apr 23, 2007 at 10:24:46AM +1000, Alan Garfield wrote:
> On Sat, 2007-04-21 at 03:36 +0400, Yar Tikhiy wrote:
>
> > >
> > > Disconnecting: Corrupted MAC on input.
> > >
> >
> > That looks like data corruption happening when TCP seg
On Wed, Apr 25, 2007 at 07:37:06AM +1000, Peter Jeremy wrote:
> On 2007-Apr-23 18:54:30 +0400, Yar Tikhiy <[EMAIL PROTECTED]> wrote:
> >Perhaps the bug is triggered when the outgoing packet consists of
> >multiple mbufs.
>
> Given that we are effectivly dealing with
Hi folks,
There two network interface drivers that have uncertain VLAN_MTU
support status, namely nve(4) and tl(4). The nve(4) driver has a
sign of unfinished VLAN_MTU support in it as it forgets to set the
respective bit in if_capenable; and tl(4) was told to support long
frames, but its driver
On Wed, May 02, 2007 at 03:51:18PM +0400, Yar Tikhiy wrote:
> Hi folks,
>
> There two network interface drivers that have uncertain VLAN_MTU
> support status, namely nve(4) and tl(4). The nve(4) driver has a
> sign of unfinished VLAN_MTU support in it as it forgets to set the
>
On Fri, Jun 08, 2007 at 06:26:41PM +0400, Yar Tikhiy wrote:
> There is the following code in tcp_input.c (I "underlined" two
> questionable lines):
>
> /*
> * Process options only when we get SYN/ACK back. The SYN case
> * for incomi
There is the following code in tcp_input.c (I "underlined" two
questionable lines):
/*
* Process options only when we get SYN/ACK back. The SYN case
* for incoming connections is handled in tcp_syncache.
* XXX this is traditional behavior, may need to be cleaned
Hi there,
Our ipfw currently doesn't seem to match this host's traffic by
uid/gid if the traffic goes to a listening TCP socket. E.g., if
one tries to allow passive data connections to a local anonymous
FTP server as follows, it won't work:
ipfw add 1 allow tcp from any to me dst-por
On Tue, Apr 8, 2008 at 3:19 PM, Robert Watson <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 7 Apr 2008, Yar Tikhiy wrote:
>
>
> > Our ipfw currently doesn't seem to match this host's traffic by uid/gid if
> the traffic goes to a listening TCP socket. E.
Hi folks,
While sweeping network interface drivers for incorrect usage of the
capabilities framework, I noticed some bugs in bge(4). Unfortunately,
I have no such card and I don't know its internals. Therefore I
made a patch fixing hw-independent bugs and marking some questionable
spots. It wou
On Fri, May 21, 2004 at 11:11:41PM +0900, George V.Neville-Neil wrote:
> >
> > While sweeping network interface drivers for incorrect usage of the
> > capabilities framework, I noticed some bugs in bge(4). Unfortunately,
> > I have no such card and I don't know its internals. Therefore I
> > mad
[moving the discussion from the cvs lists to -net]
On Wed, May 26, 2004 at 10:41:52AM +0400, Gleb Smirnoff wrote:
>
> Y> ng_vlan(4) could send a control command to ng_ether(4) instructing
> Y> the latter to increment the VLAN counter on the Ethernet interface
> Y> and toggle VLAN_MTU on if the co
On Thu, May 27, 2004 at 08:02:28AM -0700, Brooks Davis wrote:
>
> > > Y> Another way I see is to drop automatic fiddling with VLAN_MTU in
> > > Y> the first place and implement an option for ifconfig(8) so that a
> > > Y> user/admin can control the capability WRT a particular case, e.g.,
> > > Y> d
On Sun, May 16, 2004 at 06:16:58PM +0400, Yar Tikhiy wrote
in <[EMAIL PROTECTED]>:
> Note for the impatient: This message does not discuss the well-known
> issue of reusing local addresses through setting SO_REUSEADDR. This
> message is on reusing local addresses occupied by so
Hi there,
I can't but remind you that there's polling(4) in FreeBSD :-)
Until today, I was convinced for some obscure reason that polling(4)
was an experimental feature that might or might not work. Today I
tried it on our central router box and got astounding results.
The router box is a 1.4GH
On Thu, Nov 18, 2004 at 01:52:49AM +0700, Eugene Grosbein wrote:
> On Wed, Nov 17, 2004 at 09:13:51PM +0300, Yar Tikhiy wrote:
>
> > The router box is a 1.4GHz Celeron PC with an fxp(4) interface split
> > across a dozen of vlans. There is nothing special about its setup
&
Synopsis: overfull traffic on third and fourth adaptors at a promiscuous mode
on FreeBSD 4.6-STABLE
State-Changed-From-To: open->feedback
State-Changed-By: yar
State-Changed-When: Mon Jan 31 10:24:07 GMT 2005
State-Changed-Why:
This problem really looks like a local setup issue.
Sergey, are you
On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote:
> One last comment,
>
> I managed to fix it so that carp runs on the plip interface by adding:
> ifp->if_flags = LINK_STATE_UP;
>
> Here is the diff:
>
> diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c
> /usr/src/sys/dev/ppbus/if_plip.
On Mon, Jun 13, 2005 at 12:00:36PM -0400, Josh Kayse wrote:
> Definitely a typo on my part. It should be
> ifp->if_link_state = LINK_STATE_UP
>
> The reason we are using CARP on a PLIP interface is to allow us to
> have redundant connections between 2 transparent bridging firewalls.
> Instead of
On Wed, Jun 15, 2005 at 02:32:19PM -0400, Josh Kayse wrote:
> On 6/15/05, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
>
> > AFAIU, you use PLIP line as some flag that triggers suppression. If
> > slave "sees" master via PLIP, it keeps itself in slave mode. May be
> > I don't understand you right.
>
Hi folks,
As our ifconfig(8) is growing more options for special interface
types, inconsistencies sneak into their syntax. In particular,
-vlandev takes a useless argument (vlan(4) cannot attach to more
than one parent anyway) while, e.g., -carpdev doesn't need one.
Personally, I like the latter
On Thu, Sep 22, 2005 at 01:54:21PM +0300, Justas Jakubauskas wrote:
>
> > -vlandev takes a useless argument (vlan(4) cannot attach to more
> > than one parent anyway) while, e.g., -carpdev doesn't need one.
>
> And how system should know, to which device attach your vlan ?
"-vlandev" is for _det
On Mon, Sep 26, 2005 at 12:54:33AM +0200, Bernd Walter wrote:
> On Sun, Sep 25, 2005 at 11:08:25PM +0100, Gavin Atkinson wrote:
> >
> > Also, you can't set both the vlan and IP address information:
> > leeloo# ifconfig vlan14 vlan 14 vlandev fxp0 inet W.X.Y.Z netmask
> > 255.255.255.0
> > ifconfi
On Sun, Sep 25, 2005 at 11:08:25PM +0100, Gavin Atkinson wrote:
>
> There's also the issue that the "vlan" and "vlandev" options have to be
> specified in that order, which is counter-intuitive and undocumented.
>
> leeloo# ifconfig vlan14 vlandev fxp0 vlan 14
> ifconfig: must specify both vlan t
On Sun, Sep 25, 2005 at 02:37:41PM -0700, Brooks Davis wrote:
> On Thu, Sep 22, 2005 at 02:41:05PM +0400, Yar Tikhiy wrote:
> >
> > As our ifconfig(8) is growing more options for special interface
> > types, inconsistencies sneak into their syntax. In particular,
> &g
On Wed, Sep 28, 2005 at 12:57:42PM +0200, Bernd Walter wrote:
> On Wed, Sep 28, 2005 at 02:32:41PM +0400, Yar Tikhiy wrote:
> > On Mon, Sep 26, 2005 at 12:54:33AM +0200, Bernd Walter wrote:
> > > On Sun, Sep 25, 2005 at 11:08:25PM +0100, Gavin Atkinson wrote:
> > > >
On Thu, Sep 29, 2005 at 10:28:36AM +0200, Ragnar Lonn wrote:
> Yar Tikhiy wrote:
> >On Sun, Sep 25, 2005 at 02:37:41PM -0700, Brooks Davis wrote:
> >>On Thu, Sep 22, 2005 at 02:41:05PM +0400, Yar Tikhiy wrote:
> >>
> >>>As our ifconfig(8) is growing more o
Folks,
Has anybody looked at kern/86618? It looks like a piece of cake.
Yuriy, the originator, tells that nge(4) panics his RELENG_6 and
HEAD systems, but adding M_ZERO to contigmalloc() flags at one spot
in if_nge.c is enough to get rid of the trouble (patch included.)
Yuriy and yours truly were
On Sat, Oct 01, 2005 at 08:48:42PM +0100, Gavin Atkinson wrote:
>
> It seems to me that assigning an IP address to a vlan device (parent
> device bge0) isn't enough to get the interface working - I need to
> manually bring the parent interface up.
Yes you need. The UP flag on an interface is adm
On Sun, Sep 25, 2005 at 11:08:25PM +0100, Gavin Atkinson wrote:
>
> There's also the issue that the "vlan" and "vlandev" options have to be
> specified in that order, which is counter-intuitive and undocumented.
I've committed a change to ifconfig(8) that makes the order
arbitrary. Please test i
On Mon, Oct 17, 2005 at 02:11:17PM +0100, Peter Wood wrote:
> Good Afternoon,
>
> I'm now working at a large UK university in their network support
> department, as such one of my duties is to monitor the residences
> network. To this end I have a cloned nic for every vlan that we have on
> res
On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote:
>
> On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote:
> A> It has always bugged me how the vlan code traverses the linked-list for
> A> each incoming packet to find the right ifvlan, I have this patch which
> A> attempts
On Thu, Oct 20, 2005 at 10:19:34PM +1300, Andrew Thompson wrote:
> On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote:
> > Andrew,
> >
> > On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote:
> > A> It has always bugged me how the vlan code traverses the linked-list for
>
On Thu, Oct 20, 2005 at 10:51:00AM +0200, Ragnar Lonn wrote:
> Gleb Smirnoff wrote:
>
> >Although the memory overhead is not noticable on modern i386 and amd64
> >PCs I don't think that we should waste so much memory. We should keep
> >in mind the existence of embedded architectures with little me
On Fri, Oct 21, 2005 at 09:30:33AM +0400, Gleb Smirnoff wrote:
> On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote:
> Y> The hash code consists of literally a couple of #define's. And the
> Y> difference between ng_vlan(4) and vlan(4) is that each ng_vlan node
> Y
On Fri, Oct 21, 2005 at 10:40:28AM +0400, Gleb Smirnoff wrote:
> On Fri, Oct 21, 2005 at 10:06:55AM +0400, Yar Tikhiy wrote:
> Y> On Fri, Oct 21, 2005 at 09:30:33AM +0400, Gleb Smirnoff wrote:
> Y> > On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote:
> Y> > Y
On Sun, Oct 30, 2005 at 07:01:25AM +1300, Andrew Thompson wrote:
> On Sat, Oct 29, 2005 at 06:32:31PM +0200, Jon Otterholm wrote:
> >
> > Does anyone know if if_bridge supports vlan-interfaces?
>
> Yes it does.
Last time I tried if_bridge wouldn't run STP over vlan interfaces.
It was due some te
Hi there,
Once upon a time I ran into several bugs in the FreeBSD networking
code. Being a humble FreeBSD user, I started send-pr and wrote bug
reports including detailed descriptions and fixes on all of them,
but they still seem to remain unnoticed by the responsible.
We are heading to a new re
On Mon, Mar 19, 2001 at 06:32:44PM +0100, Luigi Rizzo wrote:
>
> > We are heading to a new release, but the bugs are still there.
> >
> > Could a commiter do me a favor and take a look at the following reports:
>
> which are about ??? you know we are better at parsing text strings than
> number
Hello Garrett,
On Mon, Mar 19, 2001 at 01:08:32PM -0500, Garrett Wollman wrote:
>
> I have taken a look at all of these and your suggested fixes appear to
> be correct in concept. I have not tested any of them, however.
As for me, I can see a fixed system work perfectly for months. It
was an un
On Tue, Mar 20, 2001 at 07:05:58AM -0500, Mike Tancsa wrote:
>
> Do any of the VLAN patches fix the arp -d bug with VLAN interfaces ?
>
> i.e. arp -d does not work
>
> cbackup2# ifconfig vlan0
> vlan0: flags=8843 mtu 1500
> inet 192.168.112.1 netmask 0xff00 broadcast 192.168.112.255
On Tue, Mar 20, 2001 at 03:09:59PM -0500, Garrett Wollman wrote:
> < said:
>
> > Isn't it better to assign the IFT_ETHER type to the vlan interface?
> > There might be other places in the code where vlans would behave
> > unexpectedly because of their type...
>
> No, because SNMP and potentially
Hi,
On Tue, Mar 27, 2001 at 07:35:24PM -0500, Mike Tancsa wrote:
>
> Any chances for
>
> kern/22176
> kern/22177
> kern/22178
> kern/22179
> kern/22181
>
> These were raised on freebsd-net as well in the thread "A few nasty bugs in
> the networking code"
Thanks to Jordan Hubbard, I've got c
Hi,
On Tue, Mar 27, 2001 at 12:40:11PM -0800, Archie Cobbs wrote:
> Mike Tancsa writes:
> > >Not sure why this hasn't been detected before though. Below is
> > >a possible patch.
> >
> > It has been at http://www.freebsd.org/cgi/query-pr.cgi?pr=25478 and
> > discussed a few times in freebsd-net
On Wed, Mar 28, 2001 at 11:30:49AM +0400, Yar Tikhiy wrote:
>
> Please take a careful look at the frames 6 through 9 of the stack
> trace in PR#25478, so you may notice that your patch happens to do
> nothing about the broblem. You are going to add a check for IFF_UP
> to eth
Hi there,
As a recent discussion has shown, we need a new interface type for
802.1q interfaces. Fortunately, IANA have suggested the type along
with a bunch of other types three years ago, and the NetBSD folks
updated their if_types.h accordingly. Isn't it a good idea to sync
our if_types.h with
On Mon, Apr 30, 2001 at 10:48:01PM -0400, Matthew Emmerton wrote:
>
> > i don't see a security issue in this, just want to ask if this is ok (or
> > maybe unwanted?):
> >
> > in src/usr.sbin/arp/arp.c in function search() (starts line ~429) i see
> > this (line ~447):
> >
> > if ((buf = m
Hi there,
Is there any serious reason to load ipfw rules after configuring network
interfaces? IMHO the right way is doing that in the reverse order.
Incidentally, IPFilter rules are loaded before starting the interfaces,
which leads to inconsistency as well.
--
Yar
To Unsubscribe: send mail t
Hi Jonathan,
On Mon, May 28, 2001 at 07:24:05PM -0700, Jonathan Graehl wrote:
> I've set up an old Pentium to NAT my little brother's cablemodem using
> ipfw/natd. Would I see much better performance from ipfilter? (I
> assume that in-kernel NAT would be faster and have more consistent
> latenc
Hi there,
While more and more Ethernet NIC drivers start supporting long
frames (>1518 bytes), the user/admin still cannot raise MTU on an
Ethernet interface above the 1500 byte limit due to outdated code
in net/if_ethersubr.c
Please review the following patch that removes the limitation, and
al
On Mon, Jun 25, 2001 at 05:23:18PM -0500, Jonathan Lemon wrote:
> On Tue, Jun 26, 2001 at 07:56:24AM +1000, Peter Jeremy wrote:
> > On 2001-Jun-25 14:25:42 -0500, Jonathan Lemon <[EMAIL PROTECTED]> wrote:
> > >On Mon, Jun 25, 2001 at 11:02:55PM +0400, Yar Tikhiy wrote:
&
Hi there,
Current ipfw implementation doesn't allow for matching IP packets
by their precedence field while there exist real-life cases when
it would be a rather useful feature.
Please review the following patches against -current that add the
feature: ipfw.diff for the utility, ip_fw.diff for k
[adding -net to the Cc: list]
On Wed, Aug 29, 2001 at 03:47:06PM -0700, Archie Cobbs wrote:
> Yar Tikhiy writes:
> > Why does gdb report the values of "ifp" and "mp" inconsistently?
> > The kernel crashed at the first line of ng_ether_output(), so
> >
Hi there,
I'd like to discuss the following issues prior to
modifying the kernel.
First, the current implementation of the utility function
ether_ioctl(), which can do good job common to ethernet drivers,
won't indicate the situation when an ioctl command is unsupported
by it. It will return 0 i
On Mon, Oct 08, 2001 at 02:53:32PM -0400, Garrett Wollman wrote:
> < said:
>
> > Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
> > There is code obviously taken from if_loop.c and used in some
> > drivers, which tries to do something with the third argument "data"
> > of the if
Hello everybody,
A kernel panic has been observed in both branches under the following
conditions:
o ipfw is configured with a "fwd" rule for outgoing packets that will
match some RIP datagrams
o GateD is started with RIP enabled and consequently sends a broadcast
UDP datagram that matches th
Hi there,
I ran into an absolutely clear, but year-old PR pointing out that
a router in the IPSTEALTH mode will reveal itself when processing
IP options: kern/23123.
The fix proposed seems clean and right to me: don't do IP options
at all when in the IPSTEALTH mode. Does anyone have objections?
On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote:
>
> > I ran into an absolutely clear, but year-old PR pointing out that
> > a router in the IPSTEALTH mode will reveal itself when processing
> > IP options: kern/23123.
> >
> > The fix proposed seems clean and right to me: don't do
On Wed, Dec 19, 2001 at 05:33:13PM +0200, Ruslan Ermilov wrote:
> On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote:
> >
> > I ran into an absolutely clear, but year-old PR pointing out that
> > a router in the IPSTEALTH mode will reveal itself when processing
>
On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote:
>
> By the way, is it correct to forward the packet with incorrect ip
> options? Now we do not.
No RFC seems to specify that particularly. However, RFC 1812 reads
in general:
(1) A router MUST verify the IP header, as describe
On Wed, Dec 19, 2001 at 10:32:42PM +0100, Wilko Bulte wrote:
> >
> > First of all we should decide what IPSTEALTH is for. Is it just a
> > Ruslan's net.inet.ip.decttl or it should really stealth the fact of
> > the routing? If the latter how do we behave in source routing case?
>
> I would assum
On Thu, Dec 20, 2001 at 01:24:48AM +0300, Maxim Konovalov wrote:
>
> > Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following:
> > if a source-routed IP packet reachs the end of its route, but its
> > destination address doesn't match a current host/router, whether
> > the packet should
On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote:
> On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote:
>
> > As for source routing, I believe a stealthy router should just drop
> > such packets as though it were a host. Of course, source-routed
> > packets
On Sun, Dec 23, 2001 at 02:29:14AM +0300, Maxim Konovalov wrote:
>
> On 18:51+0300, Dec 21, 2001, Yar Tikhiy wrote:
>
> > I made a patch that adds the "stealthy IP options feature".
> > Honestly, now I'm afraid it's "much ado about nothing",
On Wed, Jan 18, 2006 at 12:28:06PM -0800, Doug Ambrisko wrote:
> Sten Spans writes:
> | On Wed, 18 Jan 2006, Doug Ambrisko wrote:
> | > Dave Raven writes:
> | > | FreeBSD 4.9 - char em_driver_version[] = "1.7.16";
> | > |
> | > | I've tried multiple bridge configurations - from bridging just em0,em
On Sat, Jan 28, 2006 at 06:25:34PM +0200, Iassen Anadoliev wrote:
> Chuck Swiger writes:
>
> >Iassen Anadoliev wrote:
> >>Hello guys i hope this is the appropriate list so...
> >>
> >>I am running a ftp server and have some problems with large files. While
> >>syncing files over 4GB with rsync th
Hi folks,
Presently our vlan(4) driver sets interface's flags to 0 initially
and copies a subset of them from the parent interface when the vlan
interface is attached to its parent. In particular, copied are flags
IFF_BROADCAST and IFF_MULTICAST. This approach has an unpleasant
consequence: if y
On Mon, Jan 30, 2006 at 02:15:38PM +0100, Andre Oppermann wrote:
> Yar Tikhiy wrote:
> >
> > On Sat, Jan 28, 2006 at 06:25:34PM +0200, Iassen Anadoliev wrote:
> > > Chuck Swiger writes:
> > >
> > > >Iassen Anadoliev wrote:
> > >
On Mon, Jan 30, 2006 at 03:57:46PM +0300, Yar Tikhiy wrote:
> On Sat, Jan 28, 2006 at 06:25:34PM +0200, Iassen Anadoliev wrote:
> > Chuck Swiger writes:
> >
> > >Iassen Anadoliev wrote:
> > >>Hello guys i hope this is the appropriate list so...
> > &
On Wed, Feb 01, 2006 at 12:37:46PM +0200, Ruslan Ermilov wrote:
> On Wed, Feb 01, 2006 at 06:41:10PM +0900, Hajimu UMEMOTO wrote:
> > > On Wed, 1 Feb 2006 12:04:21 +0300
> > > Gleb Smirnoff <[EMAIL PROTECTED]> said:
> >
> > glebius> If you have compiled the modules as part of buildkernel
>
On Thu, Feb 02, 2006 at 09:01:49AM +0200, Ruslan Ermilov wrote:
> On Thu, Feb 02, 2006 at 01:49:40AM +0300, Yar Tikhiy wrote:
> > On Wed, Feb 01, 2006 at 12:37:46PM +0200, Ruslan Ermilov wrote:
> > > On Wed, Feb 01, 2006 at 06:41:10PM +0900, Hajimu UMEMOTO wrote:
> > >
On Thu, Feb 02, 2006 at 02:37:28PM +0100, Max Laier wrote:
> On Thursday 02 February 2006 13:43, Yar Tikhiy wrote:
> > > This needs to be fixed in pf then.
> >
> > Max Laier and I discussed this issue once, and Max had concern
> > over possible performance degr
On Thu, Feb 02, 2006 at 05:47:43AM -0800, Luigi Rizzo wrote:
> On Thu, Feb 02, 2006 at 02:37:28PM +0100, Max Laier wrote:
>
> > will try to commit a sollution to HEAD over the weekend. If you are
> > MFC'ing
> > the changes *now*, I'd appreciate if you could spare out pf, but I am
> > willing
On Thu, Feb 02, 2006 at 04:56:26PM +0200, Iassen Anadoliev wrote:
> Yar Tikhiy writes:
> >>
> >>We seem to have got a bug in sendfile(2). Besides bin/89100, there
> >>is kern/92243 on it. The problem is rather unpleasant and it's in
> >>the kernel,
On Fri, Feb 03, 2006 at 03:07:03PM +0300, Gleb Smirnoff wrote:
> On Fri, Feb 03, 2006 at 02:30:54AM -0800, kamal kc wrote:
> k> so what do i need to do if i don't want to calculate
> k> the ip checksum myself ?
> k>
> k> right now i am taking off packet from the kernel
> k> and modifying some of
On Sat, Feb 04, 2006 at 04:16:49PM +0100, Max Laier wrote:
> On Thursday 02 February 2006 14:37, Max Laier wrote:
> > On Thursday 02 February 2006 13:43, Yar Tikhiy wrote:
> > > > This needs to be fixed in pf then.
> > >
> > > Max Laier and I discuss
On Sun, Feb 05, 2006 at 06:24:20PM +0100, Max Laier wrote:
> On Saturday 04 February 2006 16:16, Max Laier wrote:
> > On Thursday 02 February 2006 14:37, Max Laier wrote:
> > > On Thursday 02 February 2006 13:43, Yar Tikhiy wrote:
> > > > > This needs to be fixe
Hi there,
Just want to remind about a problem I've finally run into myself.
There has been a lot of gossip on it, but next to no tech details.
Namely, BIND8 will go nuts and spit out tons of error messages per
second if its forwarder happens to be BIND9 and "forwarders only"
is not in effect. The
On Fri, Mar 03, 2006 at 10:10:40AM +0200, S.I wrote:
> Thanks for your reply i know this info from google.
> The situation is I have a router with many vlans and i want to change
> the ipprecedence for some networks as I don't want to check hosts in static
> table because
> this check is too slowl
On Fri, Mar 03, 2006 at 12:03:45PM -0500, Christopher McGee wrote:
> Carp, vlans, and em is still not supported in 5.4 release, but I have
> read about a patch that works. Can anyone point me in the right direction.
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=25292+0+/usr/local/www/db/text/2005
On Sun, Mar 05, 2006 at 12:10:51AM -0800, Doug Barton wrote:
> Yar Tikhiy wrote:
> > Hi there,
> >
> > Just want to remind about a problem I've finally run into myself.
> > There has been a lot of gossip on it, but next to no tech details.
> > Namely, BIND8 w
On Mon, Mar 06, 2006 at 11:59:08AM -0500, Christopher McGee wrote:
> Yar Tikhiy wrote:
>
> >On Fri, Mar 03, 2006 at 12:03:45PM -0500, Christopher McGee wrote:
> >
> >
> >>Carp, vlans, and em is still not supported in 5.4 release, but I have
> >>read a
On Mon, Mar 06, 2006 at 02:37:32PM -0500, Christopher McGee wrote:
> Yar Tikhiy wrote:
>
> >On Mon, Mar 06, 2006 at 11:59:08AM -0500, Christopher McGee wrote:
> >
> >
> >>Yar Tikhiy wrote:
> >>
> >>
> >>
> >&
On Fri, Sep 08, 2006 at 10:49:46AM +0200, Andre Oppermann wrote:
> Andrew Thompson wrote:
> >On Thu, Sep 07, 2006 at 05:07:25PM +0200, Andre Oppermann wrote:
> >>With the recent addition of a 16bit field for TSO into the mbuf packet
> >>header we've got 16bits left over. I've reserved these bits f
Hi all,
Is there a well-known way for a UDP application to tell to the
system that it doesn't want to receive broadcast datagrams? E.g.,
it would be very good for TFTP as required by RFC 1123. In general,
accepting broadcast UDP is a security flaw unless the higher proto
was specifically designe
On Wed, Oct 11, 2006 at 11:07:36PM +1000, Ian Smith wrote:
> On Wed, 11 Oct 2006, Yar Tikhiy wrote:
>
> > Is there a well-known way for a UDP application to tell to the
> > system that it doesn't want to receive broadcast datagrams? E.g.,
> > it would be very goo
Hi folks,
A friend user reported to me that rwhod wouldn't work in CURRENT
due to broken outgoing packets. Here's an example:
16:15:28.212810 IP truncated-ip - 6865 bytes missing! (tos 0x0, ttl 64, id
28554, offset 0, flags [none], proto: UDP (17), length: 7169, bad cksum 11c
(->c64b)!) 10.10
On Wed, Nov 22, 2006 at 04:13:46PM +0200, Miroslav Slavkov wrote:
> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
> Load Average |||
>
> Interface Traffic PeakTotal
>
>
> vlan0 in 4.597 MB/s 4.612 MB/s
> 1
On Thu, Nov 23, 2006 at 03:05:09PM +0300, Anton Yuzhaninov wrote:
> Hello All,
>
> Why on AMD64 kern.ipc.nsfbufs always zero:
>
> # sysctl kern.ipc | fgrep nsfbufs
> kern.ipc.nsfbufsused: 0
> kern.ipc.nsfbufspeak: 0
> kern.ipc.nsfbufs: 0
> # netstat -m | fgrep sfbufs
> 0/0/0 sfbufs in use (curren
On Sun, Nov 26, 2006 at 10:47:52AM -0800, Sam Leffler wrote:
> Yar Tikhiy wrote:
> > Hi folks,
> >
> > A friend user reported to me that rwhod wouldn't work in CURRENT
> > due to broken outgoing packets. Here's an example:
> >
> > 16:15:28.2128
On Thu, Dec 21, 2006 at 05:00:09PM -0800, Julian Elischer wrote:
> If I bridge two ethernets, one with HW_vlan tagging and the other
> without, and there are vlans active on that network, am I right in
> assuming that it requires that the two ethernets need to both have their
> HW_vlan capabiliti
On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote:
>
> Taking to heart comments by Andre and Max (Laier),
> I have redone this patch in a different manner.
>
> The aim is to be able to see inside vlans when bridging.
> Now, this is a 6.x patch to bridge.c because that is what we
> a
1 - 100 of 134 matches
Mail list logo
