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 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 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 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
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
>
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, 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
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 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 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 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 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 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 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 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
Greetings,
On Wed, Mar 28, 2007 at 11:38:44AM +0200, Ulrich Spoerlein wrote:
>
> I observe a strange effect, when using the following setup: Three
> FreeBSD 6.2[1] machines on Gigabit Ethernet using em(4) interfaces.
>
> HostC is the NFS server, HostB has /net/share mounted from HostC. I
> will
On Wed, Mar 21, 2007 at 03:32:43PM -0700, Julian Elischer wrote:
> Luigi Rizzo wrote:
> >On Wed, Mar 21, 2007 at 11:19:36PM +0300, Yar Tikhiy wrote:
> >>Hi folks,
> >>
> >>We have disc(4) for testing and benchmarking. However, it's a
> >>loopba
Hi folks,
We have disc(4) for testing and benchmarking. However, it's a
loopback driver, so such things as vlan or bridge cannot attach to
it. I needed a similar dummy interface mimicing Ethernet and failed
to find a ready solution. I tried ng_eiface+ng_hole, but it just
couldn't keep up with g
On Mon, Mar 19, 2007 at 10:28:37PM +0700, Eugene Grosbein wrote:
> On Mon, Mar 19, 2007 at 02:28:52PM +, Bruce M Simpson wrote:
>
> > I plan to get rid of the ugly little ip_multicast_if() hack in the IP
> > stack.=
> > Before I do, is anyone actually using this?
> >
> > RFC 3678 specifies a
On Wed, Mar 14, 2007 at 10:01:38AM -0500, Brooks Davis wrote:
> On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote:
> > Hi folks,
> >
> > Quite a while ago I noticed that our ioctl handlers get the ioctl
> > command via u_long, but ether_ioctl()'s c
On Wed, Mar 14, 2007 at 12:50:12PM +, Bruce M. Simpson wrote:
> Yar Tikhiy wrote:
> >Hi folks,
> >
> >Quite a while ago I noticed that our ioctl handlers get the ioctl
> >command via u_long, but ether_ioctl()'s command argument is int.
> >This disarray da
On Wed, Mar 14, 2007 at 04:35:06AM -0700, Luigi Rizzo wrote:
> On Wed, Mar 14, 2007 at 12:57:26PM +0300, Yar Tikhiy wrote:
> > On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote:
> ...
> > > Making the load on demand would require a bit of additional code because
&g
On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote:
> On Sat, Mar 10, 2007 at 06:35:34PM +0300, Yar Tikhiy wrote:
> > Hi folks,
> >
> > Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load
> > dummynet.ko. It can result in a broken setup when one
Hi folks,
Quite a while ago I noticed that our ioctl handlers get the ioctl
command via u_long, but ether_ioctl()'s command argument is int.
This disarray dates back to 1998, when ioctl functions started to
take u_long as the command, but ether_ioctl() was never fixed.
Fortunately, our ioctl comma
On Mon, Mar 12, 2007 at 11:51:02PM +0300, Roman Kurakin wrote:
> Yar Tikhiy wrote:
> >On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote:
> >
> >>Yar,
> >>
> >>
> >>>>2. In the case where 802.3ad trunking is implemented,
On Sun, Feb 25, 2007 at 04:15:37PM +, Bruce M Simpson wrote:
>
> Please try the attached patch which should hopefully fix this issue
> (untested).
I'm sorry to come up with bad news, but the patch resulted in a
different panic:
--
Yar
Kernel page fault with the following non-sleepable loc
On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote:
> Yar,
>
> > > 2. In the case where 802.3ad trunking is implemented, the same Ethernet
> > > address may be used by multiple physical interfaces.
> > >
> > > 3. As Eygene explained well: there are a number of consumers of
> > >
On Mon, Mar 12, 2007 at 01:26:13PM +, Bruce M. Simpson wrote:
> Yar Tikhiy wrote:
> >Guys, excuse me, but I still fail to see how the case of VLANs'
> >sharing a single MAC differs from the case of several physical
> >interfaces with the same MAC from the POV of a bri
On Mon, Mar 12, 2007 at 09:36:43AM +, Bruce M. Simpson wrote:
> Hi,
>
> Eygene Ryabinkin wrote:
> >
> >Speaking about vlan problems: the original problem is to do something
> >with VLAN interfaces only because they are sharing the MAC of their
> >physical parent. The problem itself is not VLAN
Hi folks,
Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load
dummynet.ko. It can result in a broken setup when one migrates
from a custom monolithic kernel to GENERIC with modules, which is
a nice way to reduce support headache today.
There are at least two possible ways to deal
On Mon, Mar 05, 2007 at 02:41:59PM +, Bruce M Simpson wrote:
> Hi,
>
> Thanks for your reply.
>
> Yar Tikhiy wrote:
> >My concern is that, with possible callers of ether_input() being
> >not really *from* but *on behalf* of the interface, e.g., in Netgraph,
>
On Mon, Mar 05, 2007 at 03:35:20PM +0100, Andre Oppermann wrote:
> Yar Tikhiy wrote:
> >On Mon, Mar 05, 2007 at 01:40:26AM +, Bruce M Simpson wrote:
> >>Yar Tikhiy wrote:
> >>>Now I see your point, thanks! Well, at least in theory, the driver
> >>>sho
On Mon, Mar 05, 2007 at 01:40:26AM +, Bruce M Simpson wrote:
> Yar Tikhiy wrote:
> >
> >Now I see your point, thanks! Well, at least in theory, the driver
> >shouldn't call ether_input() if the interface isn't running. OTOH,
> >the interface shouldn'
On Sat, Mar 03, 2007 at 11:40:06PM +, Bruce M Simpson wrote:
> Yar Tikhiy wrote:
> >
> >In fact, there two independent flags indicating interface's readiness:
> >IFF_UP and IFF_DRV_RUNNING. The former is controlled by the admin
> >and the latter, by the drive
On Sat, Mar 03, 2007 at 11:44:12PM +0100, Andre Oppermann wrote:
> Yar Tikhiy wrote:
> >On Sat, Mar 03, 2007 at 12:03:05AM +, Bruce M Simpson wrote:
> >>During testing of M_PROMISC I noticed a couple of issues with our CARP.
> >>
> >>1. carp doesn't se
On Fri, Mar 02, 2007 at 11:55:16PM +, Bruce M Simpson wrote:
> Hello all,
>
> I would like to announce an updated version of the 802.1p input patch,
> available at:
>http://people.freebsd.org/~bms/dump/latest-8021p.diff
>
> I have cut down the original scope of the patch. I previously ra
On Sat, Mar 03, 2007 at 12:03:05AM +, Bruce M Simpson wrote:
> During testing of M_PROMISC I noticed a couple of issues with our CARP.
>
> 1. carp doesn't seem to maintain input/output statistics on its ifnet.
This should be OK. A carp(4) interface is just a place for CARP
settings to live.
On Wed, Feb 14, 2007 at 06:05:15PM -0500, Jung-uk Kim wrote:
> I was playing with some BPF ideas for few days and I added two new
> features. SEESENT flag is extended to see only outgoing packets,
> which is analogous to libpcap's PCAP_D_OUT direction. Thus SEESENT
> is now called DIRECTION.
On Wed, Feb 14, 2007 at 10:18:49PM +, Bruce M Simpson wrote:
>
> What has not been tested or considered is the situation where we have
> nested VLANs. At least one individual has asked about this feature. At
> the moment, I'd suggest that only Netgraph potentially deals with this
> rather than
On Wed, Feb 07, 2007 at 02:53:10PM -0600, Brooks Davis wrote:
> On Wed, Feb 07, 2007 at 09:46:36PM +0100, Rink Springer wrote:
> > On Wed, Feb 07, 2007 at 09:39:38PM +0100, Ed Schouten wrote:
> > > I just compiled and installed a kernel with the new nfe(4) driver and
> > > DEVICE_POLLING enabled. B
On Wed, Feb 07, 2007 at 12:46:09PM +0100, Andrea Venturoli wrote:
> Hello.
> I've got a firewall which has public IP xxx.xxx.xxx.2 on its first NIC.
> This is bridged with a second NIC which holds xxx.xxx.xxx.0/24.
> (I also have a third and fourth NIC which runs two private IP networks,
> which a
On Fri, Dec 29, 2006 at 10:59:53AM -0800, Julian Elischer wrote:
> Yar Tikhiy wrote:
> >On Tue, Dec 26, 2006 at 11:27:44AM -0800, Julian Elischer wrote:
> >>Yar Tikhiy wrote:
> >>
> >>>>If what you are suggesting is that we pass into ipfw an 'offs
On Tue, Dec 26, 2006 at 02:31:47PM -0800, Julian Elischer wrote:
> Ok, so, here is a patch for general review by ipfw types.
> This is the first of two related changes.
>
> It is MOSTLY a cleanup of ip_fw2.c, removing a bunch of mtod()
> operations and replacing them with a cached value of the add
On Tue, Dec 26, 2006 at 11:27:44AM -0800, Julian Elischer wrote:
> Yar Tikhiy wrote:
>
> >>
> >>If what you are suggesting is that we pass into ipfw an 'offset'
> >>into the packet as well as the packet, then yes I like that idea,
> >>but I didn
On Mon, Dec 25, 2006 at 12:22:02PM -0800, Julian Elischer wrote:
> Yar Tikhiy wrote:
> >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.
> >&
On Mon, Dec 25, 2006 at 10:39:51PM +0100, Max Laier wrote:
> On Monday 25 December 2006 21:22, Julian Elischer wrote:
> > Yar Tikhiy wrote:
> > > On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote:
> > >> Taking to heart comments by Andre and Max (Lai
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
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 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, 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 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
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, 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 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 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
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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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:
> > >
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 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
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 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
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 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 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 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 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 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 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 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
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 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
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 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 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 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 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
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 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.
>
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 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.
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 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
&
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 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
1 - 100 of 134 matches
Mail list logo
