counting dropped packets for pf

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

counting dropped packets for pf

BABUT
hi guys. when the pflow option first appeared, i was surprised by the
stupidity of those who implemented it- pflow could not be specified
for block-rules, i.e. dropped packets were not taken into account. as
a result of this approach, the usefulness of pflow sought to zero for
those cases where traffic really had to be counted. but then i found
the way out- the default blocking rule first duplicated packets on a
special, only for this created localhost, which had only one rule -
receiving all incoming packets and the pflow option set, this allowed
to take into account dropped packets too. now i updated system, and
saw that the low level taken by developers fell even lower- now it is
impossible to specify dub-to for block-rules. i dont know how to get
around this now, im a simple user and tired of fighting hands-from-ass
developers. can anyone share their hacks for this?

ps: sry for my english

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Peter Nicolai Mathias Hansteen
On 03/28/18 15:04, 3 wrote:
> hi guys. when the pflow option first appeared, i was surprised by the
> stupidity of those who implemented it- pflow could not be specified
> for block-rules, i.e. dropped packets were not taken into account. as

hm. you've suffered nine years of this stupidity of others but have not
been able to add labels to your block rules?

Just as an experiment I added labels to the block rules on my
most-easily-reachable-from-here gateway, as in

block log (all) label blockgen
block drop log (all) quick from <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce

block drop log (all) quick from <longterm> label longterm
block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11

and voila, pfctl -sl gives me after a few minutes

[Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
blockgen 3739 452 19856 448 19664 4 192 0
portalbrutes 3739 0 0 0 0 0 0 0
abusives 3739 301 14681 301 14681 0 0 0
webtrash 3438 0 0 0 0 0 0 0
bruteforce 3438 0 0 0 0 0 0 0
longterm 3438 0 0 0 0 0 0 0
remotex11 3438 0 0 0 0 0 0 0

man pf.conf is your friend, please consult there before letting
resentment stew for years next time, huh?

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
> On 03/28/18 15:04, 3 wrote:
>> hi guys. when the pflow option first appeared, i was surprised by the
>> stupidity of those who implemented it- pflow could not be specified
>> for block-rules, i.e. dropped packets were not taken into account. as

> hm. you've suffered nine years of this stupidity of others but have not
> been able to add labels to your block rules?

> Just as an experiment I added labels to the block rules on my
> most-easily-reachable-from-here gateway, as in

> block log (all) label blockgen
> block drop log (all) quick from <portalbrutes> label portalbrutes
> block drop log (all) quick from <abusives> label abusives
> block drop log (all) quick from <webtrash> label webtrash
> block drop log (all) quick from <bruteforce> label bruteforce

> block drop log (all) quick from <longterm> label longterm
> block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11

> and voila, pfctl -sl gives me after a few minutes

> [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> blockgen 3739 452 19856 448 19664 4 192 0
> portalbrutes 3739 0 0 0 0 0 0 0
> abusives 3739 301 14681 301 14681 0 0 0
> webtrash 3438 0 0 0 0 0 0 0
> bruteforce 3438 0 0 0 0 0 0 0
> longterm 3438 0 0 0 0 0 0 0
> remotex11 3438 0 0 0 0 0 0 0

> man pf.conf is your friend, please consult there before letting
> resentment stew for years next time, huh?

maybe im so dumb and blind to see pflow here.. and maybe deal not in
me. where is pflow?

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

sven falempin
https://man.openbsd.org/pflow.4

On Wed, Mar 28, 2018 at 4:03 PM, 3 <[hidden email]> wrote:

> > On 03/28/18 15:04, 3 wrote:
> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> stupidity of those who implemented it- pflow could not be specified
> >> for block-rules, i.e. dropped packets were not taken into account. as
>
> > hm. you've suffered nine years of this stupidity of others but have not
> > been able to add labels to your block rules?
>
> > Just as an experiment I added labels to the block rules on my
> > most-easily-reachable-from-here gateway, as in
>
> > block log (all) label blockgen
> > block drop log (all) quick from <portalbrutes> label portalbrutes
> > block drop log (all) quick from <abusives> label abusives
> > block drop log (all) quick from <webtrash> label webtrash
> > block drop log (all) quick from <bruteforce> label bruteforce
>
> > block drop log (all) quick from <longterm> label longterm
> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
>
> > and voila, pfctl -sl gives me after a few minutes
>
> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> > blockgen 3739 452 19856 448 19664 4 192 0
> > portalbrutes 3739 0 0 0 0 0 0 0
> > abusives 3739 301 14681 301 14681 0 0 0
> > webtrash 3438 0 0 0 0 0 0 0
> > bruteforce 3438 0 0 0 0 0 0 0
> > longterm 3438 0 0 0 0 0 0 0
> > remotex11 3438 0 0 0 0 0 0 0
>
> > man pf.conf is your friend, please consult there before letting
> > resentment stew for years next time, huh?
>
> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> me. where is pflow?
>
>


--
--
---------------------------------------------------------------------------------------------------------------------
Knowing is not enough; we must apply. Willing is not enough; we must do
Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
> https://man.openbsd.org/pflow.4

> On Wed, Mar 28, 2018 at 4:03 PM, 3 <[hidden email]> wrote:

>> On 03/28/18 15:04, 3 wrote:
 >>> hi guys. when the pflow option first appeared, i was surprised by the
 >>> stupidity of those who implemented it- pflow could not be specified
 >>> for block-rules, i.e. dropped packets were not taken into account. as

 >> hm. you've suffered nine years of this stupidity of others but have not
 >> been able to add labels to your block rules?

 >> Just as an experiment I added labels to the block rules on my
 >> most-easily-reachable-from-here gateway, as in

 >> block log (all) label blockgen
 >> block drop log (all) quick from <portalbrutes> label portalbrutes
 >> block drop log (all) quick from <abusives> label abusives
 >> block drop log (all) quick from <webtrash> label webtrash
 >> block drop log (all) quick from <bruteforce> label bruteforce

 >> block drop log (all) quick from <longterm> label longterm
 >> block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11

 >> and voila, pfctl -sl gives me after a few minutes

 >> [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
 >> blockgen 3739 452 19856 448 19664 4 192 0
 >> portalbrutes 3739 0 0 0 0 0 0 0
 >> abusives 3739 301 14681 301 14681 0 0 0
 >> webtrash 3438 0 0 0 0 0 0 0
 >> bruteforce 3438 0 0 0 0 0 0 0
 >> longterm 3438 0 0 0 0 0 0 0
 >> remotex11 3438 0 0 0 0 0 0 0

 >> man pf.conf is your friend, please consult there before letting
 >> resentment stew for years next time, huh?

> maybe im so dumb and blind to see pflow here.. and maybe deal not in
>  me. where is pflow?

continue your thought. we have the output of the pfctl -vsl command,
which in this form is useless, since the output is needed in the
netflow format. there is a man pflow - one piece(its not clear why we
need it if we abandoned the pflow and went to the output of pfctl
-vsl). how do cooking a netflow stream from this?





Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Sebastian Benoit
In reply to this post by BABUT
3([hidden email]) on 2018.03.28 23:03:27 +0300:

> > On 03/28/18 15:04, 3 wrote:
> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> stupidity of those who implemented it- pflow could not be specified
> >> for block-rules, i.e. dropped packets were not taken into account. as
>
> > hm. you've suffered nine years of this stupidity of others but have not
> > been able to add labels to your block rules?
>
> > Just as an experiment I added labels to the block rules on my
> > most-easily-reachable-from-here gateway, as in
>
> > block log (all) label blockgen
> > block drop log (all) quick from <portalbrutes> label portalbrutes
> > block drop log (all) quick from <abusives> label abusives
> > block drop log (all) quick from <webtrash> label webtrash
> > block drop log (all) quick from <bruteforce> label bruteforce
>
> > block drop log (all) quick from <longterm> label longterm
> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
>
> > and voila, pfctl -sl gives me after a few minutes
>
> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> > blockgen 3739 452 19856 448 19664 4 192 0
> > portalbrutes 3739 0 0 0 0 0 0 0
> > abusives 3739 301 14681 301 14681 0 0 0
> > webtrash 3438 0 0 0 0 0 0 0
> > bruteforce 3438 0 0 0 0 0 0 0
> > longterm 3438 0 0 0 0 0 0 0
> > remotex11 3438 0 0 0 0 0 0 0
>
> > man pf.conf is your friend, please consult there before letting
> > resentment stew for years next time, huh?
>
> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> me. where is pflow?

pflow can't export data for blocked packets.
It also does not send statistics.

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
> 3([hidden email]) on 2018.03.28 23:03:27 +0300:
>> > On 03/28/18 15:04, 3 wrote:
>> >> hi guys. when the pflow option first appeared, i was surprised by the
>> >> stupidity of those who implemented it- pflow could not be specified
>> >> for block-rules, i.e. dropped packets were not taken into account. as
>>
>> > hm. you've suffered nine years of this stupidity of others but have not
>> > been able to add labels to your block rules?
>>
>> > Just as an experiment I added labels to the block rules on my
>> > most-easily-reachable-from-here gateway, as in
>>
>> > block log (all) label blockgen
>> > block drop log (all) quick from <portalbrutes> label portalbrutes
>> > block drop log (all) quick from <abusives> label abusives
>> > block drop log (all) quick from <webtrash> label webtrash
>> > block drop log (all) quick from <bruteforce> label bruteforce
>>
>> > block drop log (all) quick from <longterm> label longterm
>> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
>>
>> > and voila, pfctl -sl gives me after a few minutes
>>
>> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
>> > blockgen 3739 452 19856 448 19664 4 192 0
>> > portalbrutes 3739 0 0 0 0 0 0 0
>> > abusives 3739 301 14681 301 14681 0 0 0
>> > webtrash 3438 0 0 0 0 0 0 0
>> > bruteforce 3438 0 0 0 0 0 0 0
>> > longterm 3438 0 0 0 0 0 0 0
>> > remotex11 3438 0 0 0 0 0 0 0
>>
>> > man pf.conf is your friend, please consult there before letting
>> > resentment stew for years next time, huh?
>>
>> maybe im so dumb and blind to see pflow here.. and maybe deal not in
>> me. where is pflow?

> pflow can't export data for blocked packets.
> It also does not send statistics.

i understand- no kosher ways. im asking for illegal ways. many years
ago there was no way either, but i found a way out. i dont think you
are dumber than me

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Sebastian Benoit
3([hidden email]) on 2018.03.29 02:10:29 +0300:

> > 3([hidden email]) on 2018.03.28 23:03:27 +0300:
> >> > On 03/28/18 15:04, 3 wrote:
> >> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> >> stupidity of those who implemented it- pflow could not be specified
> >> >> for block-rules, i.e. dropped packets were not taken into account. as
> >>
> >> > hm. you've suffered nine years of this stupidity of others but have not
> >> > been able to add labels to your block rules?
> >>
> >> > Just as an experiment I added labels to the block rules on my
> >> > most-easily-reachable-from-here gateway, as in
> >>
> >> > block log (all) label blockgen
> >> > block drop log (all) quick from <portalbrutes> label portalbrutes
> >> > block drop log (all) quick from <abusives> label abusives
> >> > block drop log (all) quick from <webtrash> label webtrash
> >> > block drop log (all) quick from <bruteforce> label bruteforce
> >>
> >> > block drop log (all) quick from <longterm> label longterm
> >> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
> >>
> >> > and voila, pfctl -sl gives me after a few minutes
> >>
> >> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> >> > blockgen 3739 452 19856 448 19664 4 192 0
> >> > portalbrutes 3739 0 0 0 0 0 0 0
> >> > abusives 3739 301 14681 301 14681 0 0 0
> >> > webtrash 3438 0 0 0 0 0 0 0
> >> > bruteforce 3438 0 0 0 0 0 0 0
> >> > longterm 3438 0 0 0 0 0 0 0
> >> > remotex11 3438 0 0 0 0 0 0 0
> >>
> >> > man pf.conf is your friend, please consult there before letting
> >> > resentment stew for years next time, huh?
> >>
> >> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> >> me. where is pflow?
>
> > pflow can't export data for blocked packets.
> > It also does not send statistics.
>
> i understand- no kosher ways.

yes is a kosher way: send a diff.

> im asking for illegal ways. many years
> ago there was no way either, but i found a way out. i dont think you
> are dumber than me

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Stuart Henderson
In reply to this post by BABUT
On 2018-03-28, 3 <[hidden email]> wrote:

> hi guys. when the pflow option first appeared, i was surprised by the
> stupidity of those who implemented it- pflow could not be specified
> for block-rules, i.e. dropped packets were not taken into account. as
> a result of this approach, the usefulness of pflow sought to zero for
> those cases where traffic really had to be counted. but then i found
> the way out- the default blocking rule first duplicated packets on a
> special, only for this created localhost, which had only one rule -
> receiving all incoming packets and the pflow option set, this allowed
> to take into account dropped packets too. now i updated system, and
> saw that the low level taken by developers fell even lower- now it is
> impossible to specify dub-to for block-rules. i dont know how to get
> around this now, im a simple user and tired of fighting hands-from-ass
> developers. can anyone share their hacks for this?
>
> ps: sry for my english

The English is mostly readable, the attitude is rather abrasive though.

pflow hooks into pf states. There is no state for a blocked packet.
I think you'll be happier with a BPF-based flow capture tool, there
are two in ports.


Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Peter Nicolai Mathias Hansteen
In reply to this post by BABUT
On 03/28/18 22:03, 3 wrote:

> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> me. where is pflow?

pflow gets the data it exports from the state table.

Blocked connections do not create state table entries.

This means that pflow does not have the information you're looking for.

You can still get detailed information about blocked connection
attempts, in the aggregate via labels as I showed you, or from pflog.

You could even have your block rules logged to a separate pflog interface.

Others have alredy pointed you at other alternatives. Obsessing about
pflow unfortunately isn't going to get you anywhere. Exploring the other
options might.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Eric Furman-3
In reply to this post by BABUT
On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote:
> > 3([hidden email]) on 2018.03.28 23:03:27 +0300:
> >> > On 03/28/18 15:04, 3 wrote:
> >> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> >> stupidity of those who implemented it- pflow could not be specified
> >> >> for block-rules, i.e. dropped packets were not taken into account. as
> i understand- no kosher ways. im asking for illegal ways. many years
> ago there was no way either, but i found a way out. i dont think you
> are dumber than me
>

You are asking, "How do I use a wrench as a screwdriver?"

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Edgar Pettijohn III-2
In reply to this post by BABUT

On Mar 29, 2018 8:35 AM, Eric Furman <[hidden email]> wrote:

>
> On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote:
> > > 3([hidden email]) on 2018.03.28 23:03:27 +0300:
> > >> > On 03/28/18 15:04, 3 wrote:
> > >> >> hi guys. when the pflow option first appeared, i was surprised by the
> > >> >> stupidity of those who implemented it- pflow could not be specified
> > >> >> for block-rules, i.e. dropped packets were not taken into account. as
> > i understand- no kosher ways. im asking for illegal ways. many years
> > ago there was no way either, but i found a way out. i dont think you
> > are dumber than me
> >
>
> You are asking, "How do I use a wrench as a screwdriver?"
>

You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
In reply to this post by Eric Furman-3
Вы писали 29 марта 2018 г., 16:35:45:

> On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote:
>> > 3([hidden email]) on 2018.03.28 23:03:27 +0300:
>> >> > On 03/28/18 15:04, 3 wrote:
>> >> >> hi guys. when the pflow option first appeared, i was surprised by the
>> >> >> stupidity of those who implemented it- pflow could not be specified
>> >> >> for block-rules, i.e. dropped packets were not taken into account. as
>> i understand- no kosher ways. im asking for illegal ways. many years
>> ago there was no way either, but i found a way out. i dont think you
>> are dumber than me
>>

> You are asking, "How do I use a wrench as a screwdriver?"

yep. and comrade [hidden email] understand me.

hello, edgar. you are smart ^_^

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
In reply to this post by Peter Nicolai Mathias Hansteen
> On 03/28/18 22:03, 3 wrote:

>> maybe im so dumb and blind to see pflow here.. and maybe deal not in
>> me. where is pflow?

> pflow gets the data it exports from the state table.
> Blocked connections do not create state table entries.
> This means that pflow does not have the information you're looking for.
> You can still get detailed information about blocked connection
> attempts, in the aggregate via labels as I showed you, or from pflog.
> You could even have your block rules logged to a separate pflog interface.
> Others have alredy pointed you at other alternatives. Obsessing about
> pflow unfortunately isn't going to get you anywhere. Exploring the other
> options might.

i accept your challenge! ^^
but first i will describe my scheme of pf.conf(this is important):

block all # default block
match from (self) tag PASS # default output

match bla-bla1 to (self) tag PASS
match bla-bla2 to (self) tag PASS
..
match bla-blaN to (self) tag PASS

match from lan:network tag PASS # its actually an anchor here, loadable from
match to lan:network tag PASS   # another file, but it does not matter

match out on egress inet from !(self) tagged PASS nat-to (egress) # nat
pass quick tagged PASS # one(no other) final pass

-- in this place we have all the packets that were not accepted and
that will be later blocked by the default block.
-- we need only those who entered on egress(pppoe0 for me):
pass in quick on pppoe0 all route-to(vether0 10.0.0.1) keep state (pflow) # any fake inteface is here
-- now all these packets selected by us get back to the entrance of the rules(before default block).
-- we can leave them as they are, but its better to delete them:
block quick on vether0     # need to place as the first rule
-- lets see what we have got if enable logging:

Mar 29 20:42:46.984161 rule 92/(match) [uid 0, pid 54243] pass in on pppoe0: 24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 53, id 5542, len 48)
Mar 29 20:42:46.984176 rule 0/(match) [uid 0, pid 54243] block out on vether0: 24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 53, id 5542, len 48)
.. and more(i found four matching packets in this interval, but it is difficult to synchronize pf's log and log of the flowd)

process_flow: ACCEPT flow FLOW recv_time 2018-03-29T20:43:42.634715 proto 17 tcpflags 00 tos 00 agent [127.0.0.1] src [24.201.182.114]:46574 dst [188.235.31.7]:36824 gateway [0.0.0.0] packets 3 octets 144 in_if 7 out_if 0 sys_uptime_ms 2h20m51s.000 time_sec 2018-03-29T20:43:42 time_nanosec 634520582 netflow ver 5 flow_start 2h19m55s.000 flow_finish 2h20m5s.000 src_AS 0 src_masklen 0 dst_AS 0 dst_masklen 0 engine_type 10752 engine_id 10752 seq 11273 source 0 crc32 00000000
output_flow_enqueue: offset 1624 alloc 16384

-- what you say? ;)

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
In reply to this post by Peter Nicolai Mathias Hansteen
> man pf.conf is your friend, please consult there before letting
> resentment stew for years next time, huh?

why are you silent? do you have the courage to admit that the famous
russian comedian zadornov was right when said "ну тупые!"? ;)

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Mihai Popescu-3
In reply to this post by BABUT
> You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.

I want to see you using your method for a deep sunken screw inside a
cylindrical channel of a case.
You can give a chance to the other guy, too.
People like you do not understand concepts like evolution, smart
tools, unix simplicity, KISS, etc.

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Edgar Pettijohn III-2
In reply to this post by BABUT

On Mar 30, 2018 4:08 AM, Mihai Popescu <[hidden email]> wrote:
>
> > You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.
>
> I want to see you using your method for a deep sunken screw inside a
> cylindrical channel of a case.
> You can give a chance to the other guy, too.
> People like you do not understand concepts like evolution, smart
> tools, unix simplicity, KISS, etc.
>

First let me say I believe '3' to be a bit of an arsehole and was surprised he received any helpful responses. However the above is a perfect example of Unix. Perhaps you haven't used '|' to combine utility programs.  

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
In reply to this post by Mihai Popescu-3
>> You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.

> I want to see you using your method for a deep sunken screw inside a
> cylindrical channel of a case.
> You can give a chance to the other guy, too.
> People like you do not understand concepts like evolution, smart
> tools, unix simplicity, KISS, etc.

people like you do not understand what better badly does work than
well not works. and it is not our(not ordinary users) fault that the
progress of obsd is only to cut poorly functioning parts without
giving anything instead. teo and your ideal fucking unix system is
"hello, world!" with two remote holes in the default install. but you
are too d^Hstubborn to understand that such a system is not necessary
for ordinary users. i like pf and i hate dirty monkey's style of
linux, but there will come a time when this will not be enough to
choose obsd

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

Peter Nicolai Mathias Hansteen
On 03/30/18 13:32, 3 wrote:

> people like you do not understand what better badly does work than
> well not works. and it is not our(not ordinary users) fault that the

Seriously, cipher, you're just spewing word salad again.

And it sounds vaguely like abuse, aimed at people who were in fact
offering useful suggestions.

Some of us were able to decipher what we thought was your problem
(wanting to record dropped packets) and offered suggestions on how to do
that along with the explanation why your original approach was never
going to work.

If you really want to record your dropped packets in a netflow format,
there's nothing stopping you from implementing just that.

Whether your implementation will be accepted back the OpenBSD source
tree is of course a different and separate question.

One thing is certain, though: Spewing abuse-ish word salad at mailing
lists is not going to get you anywhere.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: counting dropped packets for pf

BABUT
> On 03/30/18 13:32, 3 wrote:

>> people like you do not understand what better badly does work than
>> well not works. and it is not our(not ordinary users) fault that the

> Seriously, cipher, you're just spewing word salad again.

> And it sounds vaguely like abuse, aimed at people who were in fact
> offering useful suggestions.
to give useful suggestions first need to understand the question.
perhaps my poor english prevented you from understanding the question

> Some of us were able to decipher what we thought was your problem
> (wanting to record dropped packets) and offered suggestions on how to do
> that along with the explanation why your original approach was never
> going to work.
my initial approach does work. u are have comments about route-to?

> If you really want to record your dropped packets in a netflow format,
> there's nothing stopping you from implementing just that.
in next time remind yourself that you can surgery on your own, instead
of going to a surgeon

> Whether your implementation will be accepted back the OpenBSD source
> tree is of course a different and separate question.
i am a ordinary user(not a surgeon) and have already talked about it,
but my poor english..

> One thing is certain, though: Spewing abuse-ish word salad at mailing
> lists is not going to get you anywhere.
sorry about that -_- i should have left as soon as i understand we
were living in different worlds

12