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
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",
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.
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
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 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
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
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
1 - 100 of 134 matches
Mail list logo
