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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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,
>
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 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
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 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 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 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,
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 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
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 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 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 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
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 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
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 Sat, May 08, 2004 at 06:40:41AM +, Bjoern A. Zeeb wrote:
>
> > When an active IPv4 TCP connection between
> > localIP:localport and remoteIP1:remoteport1 exists,
> > it is not possible for local non-root user to create outgoing
> > TCP connection from localIP:localport to remoteIP2:remotepo
Hi folks,
Attached below is a patch addressing the issue of the inability to
reuse a local IP:port couple occupied by an established TCP connection
from another user, but by no listeners. Could anybody with fair
understanding of our TCP/IP stack review it please? Thanks.
--
Yar
Index: in_pcb.
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 sockets belonging
to other users.
On Sat, May 15, 2004 at 10:21:57PM +0400, Yar Tikhiy wrote:
>
> At
101 - 134 of 134 matches
Mail list logo
