Re: pf and altq couple: before and after merge

2003-08-14 Thread Henning Brauer
On Mon, Aug 04, 2003 at 11:35:13PM +0300, Alexey E. Suslikov wrote: > so, what is the point of example? we are unable to match in and out packets > to shape them separately (remember, the state is the matching criteria) and > we are unable to shape same packets on the different interfaces (the stat

Re[2]: pf and altq couple: before and after merge

2003-08-14 Thread Alexey E. Suslikov
Tuesday, August 5, 2003, 11:00:14 AM, Daniel Hartmeier wrote: > Well, not an arbitrary number of states per connection, at most two > (unless translation and/or encapsulation is involved, then you could > possibly create more). > You can easily see how this works by loading the simple ruleset >

Re: pf and altq couple: before and after merge

2003-08-07 Thread Daniel Hartmeier
On Tue, Aug 05, 2003 at 11:16:25AM +0300, Alexey E. Suslikov wrote: > there is no any mention about "direction" property in the state entry: > "... If a packet matches a pass ... keep state rule, the filter creates a state > for this connection and automatically lets pass all subsequent packets of

Re[2]: pf and altq couple: before and after merge

2003-08-06 Thread Alexey E. Suslikov
Tuesday, August 5, 2003, 12:36:02 AM, Daniel Hartmeier wrote: > On Mon, Aug 04, 2003 at 11:35:13PM +0300, Alexey E. Suslikov wrote: >> keepstated connection's packets silently pass all interfaces and all directions, >> so we just can't REASSEMBLE the queue to take control over them. the only >> c

Re: pf and altq couple: before and after merge

2003-08-05 Thread Daniel Hartmeier
On Tue, Aug 05, 2003 at 10:26:46AM +0300, Alexey E. Suslikov wrote: > "Both incoming and outgoing TCP connections will pass by those two rules, > create state, and all packets related to the connections will be assigned > to either the q_def or q_pri queues. Packets assigned to the q_pri queue > w

RE: Re[2]: pf and altq couple: before and after merge

2003-08-05 Thread Dom De Vitto
:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexey E. Suslikov Sent: Tuesday, August 05, 2003 8:27 AM To: Daniel Hartmeier Cc: [EMAIL PROTECTED] Subject: Re[2]: pf and altq couple: before and after merge Tuesday, August 5, 2003, 12:36:02 AM,

Re: pf and altq couple: before and after merge

2003-08-04 Thread Trevor Talbot
I wrote: The two major losses from ALTQ are the traffic conditioner, and fine-grained classification on an interface using translation. Whoops. The translation loss was still present before the merge. Scratch that one :)

Re: pf and altq couple: before and after merge

2003-08-04 Thread Trevor Talbot
On Monday, Aug 4, 2003, at 13:35 US/Pacific, Alexey E. Suslikov wrote: BEFORE MERGE: ok, assume what we have some already keepstated tcp connection. everybody knows: once keepstated, such connection has ability to pass any interface and any direction without necessity in the additional pass ru

Re: pf and altq couple: before and after merge

2003-08-04 Thread Daniel Hartmeier
On Mon, Aug 04, 2003 at 11:35:13PM +0300, Alexey E. Suslikov wrote: > keepstated connection's packets silently pass all interfaces and all directions, > so we just can't REASSEMBLE the queue to take control over them. the only > controllable option is the connection's state. but there are TOO MANY

pf and altq couple: before and after merge

2003-08-04 Thread Alexey E. Suslikov
PREFACE: from the first word, i want to note: all the discuss below is doing in context of stateful filtering. ABSTRACT: sometimes, i saw people walking around traffic shaping without any success. lately, in the private discuss, some hard questions comes alive. here, i will try to ask these que