|
|
 Up |
|
|
  |
Author: Can Erkin AcarCan Erkin Acar
Date: Feb 29, 2008 21:39
On Fri, Feb 29, 2008 at 2:03 PM, Ermal Lugi gmail.com> wrote:> I would like to make the changes stated below on pf(4) and comments
> are very well appriciated.
> With them i would like to know if such changes are feasible for
> getting merged with OpenBSD.
Please go ahead and send diffs it is impossible to tell otherwise.
Hint: incremental changes that change only one thing at a time are
easier to review and get in. Do not send a huge diff and expect any
one to take it seriously.
> Would it be better that NAT/RDR/BINAT be on the same ruleset and
> behaving the same as pf rules, as latest match wins instead of first
> one which is currently.
This would break a lot of existing rules, so I do not think such a
change will be easy to merge.
|
| Show full article (2.95Kb) |
|
| |
no comments
|
|
|
Author: Nigel J. TaylorNigel J. Taylor
Date: Feb 29, 2008 19:31
Find below patches for relayd, these appear to solve the 100%% CPU issue,
further testing is required.
The issue is that the SPLAY tree uses a session key held in se_key, the
tree entries are created with this key set to the incoming dns id. When
a request is being sent out, the se_key is replaced by a random value so
the dns request appears to be coming from a random id.
The splay tree expects the keys to remain unchanged once inserted, in
replacing the se_key with a random value the tree is corrupted and
causes the tree on occasion to loop back on itself.
The fix removes the replacement of se_key from relay_dns_request. se_key
is assigned a random value for and id in relay_udp_server before where
the SPLAY_INSERT is performed, se_outkey is set to the return id rather
than the rl_dskkey. The relay_dns_request which occurs after the
SPLAY_INSERT no longer updates se_outkey, or se_key. The request is sent
using the random value already placed into the se_key when the session
is created.
Regards
Nigel Taylor
|
| Show full article (3.58Kb) |
|
| |
no comments
|
|
|
Author: scottscott
Date: Feb 29, 2008 18:43
RE: "... Is it usable to have the functionality that the overload table
function be used not only for blocking ..."
To help catch port scanning, syn flooding, etc...
Cisco has a "null" interface. I've often thought that an
rdr ...criteria... tag ABC -> null_if
combined w/
pass in ...criteria... tagged ABC synproxy state (...overload stuff...)
where synproxy would handle the tcp handshake and increment
the max-src counters but the flow would terminate safely on the
null_if (go nowhere, do nothing) and the bits just fall to the floor.
Once the overload threshold is hit the usual blocking behavior kicks in.
/S
-----Original Message-----
From: Ermal LuC'i gmail.com>
To: tech@openbsd.org
Subject: About pf(4) NAT/BINAT/RDR and adding reflect.
Date: Fri, 29 Feb 2008 23:03:50 +0100
Delivered-To: 8f27e956@gmail.com
|
| Show full article (2.28Kb) |
|
no comments
|
|
|
Author: Tobias UlmerTobias Ulmer
Date: Feb 29, 2008 15:06
Index: usr.sbin/cron/env.c
===================================================================
RCS file: /cvs/src/usr.sbin/cron/env.c,v
retrieving revision 1.20
diff -u -r1.20 env.c
--- usr.sbin/cron/env.c 10 Sep 2007 14:29:53 -0000 1.20
+++ usr.sbin/cron/env.c 24 Feb 2008 00:54:06 -0000
@@ -123,7 +123,7 @@
VALUEI, /* First char of VALUE, may be quote */
VALUE, /* Subsequent chars of VALUE */
FINI, /* All done, skipping trailing whitespace */
- ERROR, /* Error */
+ ERROR /* Error */
};
/* return ERR = end of file
|
| |
|
no comments
|
|
|
Author: Ermal LuçiErmal Luçi
Date: Feb 29, 2008 14:11
I would like to make the changes stated below on pf(4) and comments
are very well appriciated.
With them i would like to know if such changes are feasible for
getting merged with OpenBSD.
Would it be better that NAT/RDR/BINAT be on the same ruleset and
behaving the same as pf rules, as latest match wins instead of first
one which is currently.
It even should give some performance improvements since now two
ruleset are searched, at worse case, for finding the correct
translation rule before going to search the filter rules.
The rationale behind this is that you can mix rdr, binat, nat and even
allow you to implement reflection easily as an additional action wich
is nothing more than rdr+nat combined. As it is now you have to add a
new rulest for reflection and that is more overhead.
|
| Show full article (1.42Kb) |
|
no comments
|
|
|
Author: Marcus GlockerMarcus Glocker
Date: Feb 29, 2008 05:56
On Thu, Feb 28, 2008 at 03:35:57AM -0500, Brad wrote:
> The following diff as provided by Geoff Steckel in PR 5724 for Adaptec
> Starfire sf(4) adapters needs testing.
>
> The aic6915 driver counts packets in the output queue to check for
> the chip hanging. During error recovery the output queue is cleared
> but the counter is never reset, causing endless spurious device timeout
> messages.
>
> The diff should resolve this issue which can only be resolved at the moment
> by rebooting the system. Please provide a dmesg.
I can't test it since I don't have such a NIC, but it makes sense to me.
OK mglocker@
|
| Show full article (1.17Kb) |
|
no comments
|
|
|
Author: Cédric BergerCédric Berger
Date: Feb 29, 2008 03:34
Nigel J. Taylor wrote:
> Thanks, for that point, I had considered it, but stuck with something
> closer to the original. There maybe byte ordering issues, and alignment,
> which need to be considered, before doing the compare as 32bit/16bit
> integers, you need to convert them first using ntohl, ntohs.
Huh?
Why would you need to convert using ntohl, ntohs to see if two integer
are equal?
if (a == b) then (ntohs(a) == ntohs(b))
> You could
> avoid the conversion to integers provided there are no alignment issues,
Huh?
Which alignement issues?
Cedric
PS: and is the bcopy above really needed too? I doubt it...
> then the results will vary between different architectures. memcmp might
> be more efficient than doing the convert and integer compare.
>
>
> Regards
>
> Nigel Taylor
>
>
> Cidric Berger wrote...
|
| Show full article (3.31Kb) |
|
no comments
|
|
|
Author: Nigel J. TaylorNigel J. Taylor
Date: Feb 29, 2008 03:14
Thanks, for that point, I had considered it, but stuck with something
closer to the original. There maybe byte ordering issues, and alignment,
which need to be considered, before doing the compare as 32bit/16bit
integers, you need to convert them first using ntohl, ntohs. You could
avoid the conversion to integers provided there are no alignment issues,
then the results will vary between different architectures. memcmp might
be more efficient than doing the convert and integer compare.
Regards
Nigel Taylor
Cidric Berger wrote:
> Nigel J. Taylor wrote:
>> A small fix to relayd/relay.c follows below, the compare in relay_cmp_af
>> added the difference between the ip address and ports together, in rare
>> cases...
|
| Show full article (2.96Kb) |
|
no comments
|
|
|
Author: Cédric BergerCédric Berger
Date: Feb 28, 2008 23:25
Nigel J. Taylor wrote:
> A small fix to relayd/relay.c follows below, the compare in relay_cmp_af
> added the difference between the ip address and ports together, in rare
> cases this could return zero when the ip address byte difference is
> exactly negated by the difference between port bytes.
>
> I have progressed slightly further on the 100%% CPU usage. I know where
> the problem is SPLAY tree for the sessions, the SPLAY_INSERT,
> SPLAY_REMOVE's appear to end up with a corrupt tree where the tree loops
> back on itself, then the next call to either will just loop. A
> modification of relay.c to display SPLAY tree show that entries are not
> being correctly removed/inserted. I haven't worked out if the fault is
> within the SPLAY macros, or relayd use of SPLAY macros.
>
> Checking for other uses of SPLAY_xxxx only systrace and kern/subr_pool.c
> appear to be using the SPLAY_xxxx macros, within OpenBSD. If issue turns
> out to be within SPLAY_xxx macros, this gives an idea what else might be
> affected.
>
> I found a splay-test in regress, no errors reported from this. I am ...
|
| Show full article (2.28Kb) |
|
no comments
|
|
|
|
|
|
Author: Jacob MeuserJacob Meuser
Date: Feb 28, 2008 17:13
On Thu, Feb 28, 2008 at 09:14:08PM +0300, Vadim Jukov wrote:
> 28 February 2008 c. 06:36:11 Jacob Meuser wrote:
>> hmm, yeah, it doesn't want to work that easy here either.
>>
>> but, starting artsd like : artsd -a esd -F 4 -S 9600 does work for me,
>> as long as esd isn't already running.
>
> This works for me too (also with different "-F" values), but only when I
> do not have "-r 48000" in esd.conf. Of course, this gives inappropriate
> audio output. And when I add "-r 48000", artsd could not start:
this is pretty OT. discussing interaction between esd and artsd doesn't
belong on tech@. esd should realy use a power of 2 for the blocksize.
doesn't matter for audio(4), but it does matter when artsd is a client
of esd:
> len = 2904, can_write = 4096, errno = 61 (Connection refused)
because the blocksizes in esd and artsd don't align nicely.
|
| Show full article (1.25Kb) |
|
no comments
|
|
|
|
|
|
|
