Re: ospfd: check dst addr for hello packets
reads ok
Remi Locherer(remi.loche...@relo.ch) on 2019.08.11 11:21:36 +0200:
> When ospfd receives a hello packet it takes the src IP address and updates
> the address in its neighbor struct for the given router id unconditionally.
>
> In the case of broadcast interfaces this is not a problem:
> find_iface() checks that the src address is from the same subnet as
> the receiving interface is. It is best practice to only enable ospf in a
> subnet where you control all routers.
>
> But in the case of point-to-point interfaces no sanity checks happen on the
> src or dst IP address.
>
> RFC 2328 says in "9.5. Sending Hello packets":
> On broadcast networks and physical point-to-point networks,
> Hello packets are sent every HelloInterval seconds to the IP
> multicast address AllSPFRouters.
>
>
> I verified that ospfd does it like that. Also FastIron and Junos follow
> this.
>
> I propose that we add a check and only accept hellos on point-to-point and
> broadcast interfaces when the destination is 224.0.0.5 (AllSPFRouters).
>
> The check for AllDRouters is not needed in addition to the proposed check.
>
> OK?
>
> Remi
>
>
> Index: packet.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/packet.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 packet.c
> --- packet.c 15 Jul 2019 18:26:39 - 1.32
> +++ packet.c 11 Aug 2019 09:17:51 -
> @@ -219,12 +219,16 @@ recv_packet(int fd, short event, void *b
> /* switch OSPF packet type */
> switch (ospf_hdr->type) {
> case PACKET_TYPE_HELLO:
> - inet_aton(AllDRouters, &addr);
> - if (ip_hdr.ip_dst.s_addr == addr.s_addr) {
> - log_debug("recv_packet: invalid destination IP "
> - "address");
> - break;
> - }
> + inet_aton(AllSPFRouters, &addr);
> + if (iface->type == IF_TYPE_BROADCAST ||
> + iface->type == IF_TYPE_POINTOPOINT)
> + if (ip_hdr.ip_dst.s_addr != addr.s_addr) {
> + log_warnx("%s: hello ignored on interface %s, "
> + "invalid destination IP address %s",
> + __func__, iface->name,
> + inet_ntoa(ip_hdr.ip_dst));
> + break;
> + }
>
> recv_hello(iface, ip_hdr.ip_src, ospf_hdr->rtr_id, buf, len);
> break;
>
ospfd: check dst addr for hello packets
When ospfd receives a hello packet it takes the src IP address and updates
the address in its neighbor struct for the given router id unconditionally.
In the case of broadcast interfaces this is not a problem:
find_iface() checks that the src address is from the same subnet as
the receiving interface is. It is best practice to only enable ospf in a
subnet where you control all routers.
But in the case of point-to-point interfaces no sanity checks happen on the
src or dst IP address.
RFC 2328 says in "9.5. Sending Hello packets":
On broadcast networks and physical point-to-point networks,
Hello packets are sent every HelloInterval seconds to the IP
multicast address AllSPFRouters.
I verified that ospfd does it like that. Also FastIron and Junos follow
this.
I propose that we add a check and only accept hellos on point-to-point and
broadcast interfaces when the destination is 224.0.0.5 (AllSPFRouters).
The check for AllDRouters is not needed in addition to the proposed check.
OK?
Remi
Index: packet.c
===
RCS file: /cvs/src/usr.sbin/ospfd/packet.c,v
retrieving revision 1.32
diff -u -p -r1.32 packet.c
--- packet.c15 Jul 2019 18:26:39 - 1.32
+++ packet.c11 Aug 2019 09:17:51 -
@@ -219,12 +219,16 @@ recv_packet(int fd, short event, void *b
/* switch OSPF packet type */
switch (ospf_hdr->type) {
case PACKET_TYPE_HELLO:
- inet_aton(AllDRouters, &addr);
- if (ip_hdr.ip_dst.s_addr == addr.s_addr) {
- log_debug("recv_packet: invalid destination IP "
-"address");
- break;
- }
+ inet_aton(AllSPFRouters, &addr);
+ if (iface->type == IF_TYPE_BROADCAST ||
+ iface->type == IF_TYPE_POINTOPOINT)
+ if (ip_hdr.ip_dst.s_addr != addr.s_addr) {
+ log_warnx("%s: hello ignored on interface %s, "
+ "invalid destination IP address %s",
+ __func__, iface->name,
+ inet_ntoa(ip_hdr.ip_dst));
+ break;
+ }
recv_hello(iface, ip_hdr.ip_src, ospf_hdr->rtr_id, buf, len);
break;
Re: switchd(8): negotiate versions with hello
> On 22.11.2016, at 16:12, Rafael Zalamena wrote:
>
> Teach switchd(8) how to negotiate protocol version using the hello bitmap
> header. This way switchd(8) is able to fallback or use higher version using
> the bitmap.
>
> This diff also prevents connections from switching version in the middle of
> the operation.
>
> This is the first step before adding a state machine to switchd(8): move the
> hello to a common function and make it step into the first state: HELLO_WAIT.
> (next diff)
>
> ok?
Two comments below, otherwise OK.
Reyk
>
> Index: ofp.c
> ===
> RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 ofp.c
> --- ofp.c 4 Nov 2016 22:27:08 - 1.15
> +++ ofp.c 22 Nov 2016 14:55:12 -
> @@ -132,6 +132,13 @@ ofp_input(struct switch_connection *con,
> return (-1);
> }
>
> + if (con->con_version != OFP_V_0 &&
This should be handled by the state machine later, but OK for now.
(<= HELLO_WAIT accepts hello and any version, > HELLO_WAIT doesn't)
> + oh->oh_version != con->con_version) {
> + log_debug("wrong version %d, expected %d",
> + oh->oh_version, con->con_version);
> + return (-1);
> + }
> +
> switch (oh->oh_version) {
> case OFP_V_1_0:
> if (ofp10_input(sc, con, oh, ibuf) != 0)
> @@ -165,6 +172,10 @@ ofp_open(struct privsep *ps, struct swit
> log_info("%s: new connection %u.%u from switch %u",
> __func__, con->con_id, con->con_instance,
> sw == NULL ? 0 : sw->sw_id);
> +
> + /* Send the hello with the latest version we support. */
> + if (ofp_send_hello(ps->ps_env, con, OFP_V_1_3) == -1)
> + return (-1);
>
> return (0);
> }
> Index: ofp10.c
> ===
> RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp10.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 ofp10.c
> --- ofp10.c 21 Nov 2016 18:19:51 - 1.16
> +++ ofp10.c 22 Nov 2016 15:08:02 -
> @@ -60,7 +60,7 @@ int ofp10_validate_packet_out(struct sw
> struct ofp_header *, struct ibuf *);
>
> struct ofp_callback ofp10_callbacks[] = {
> - { OFP10_T_HELLO,ofp10_hello, NULL },
> + { OFP10_T_HELLO,ofp10_hello, ofp_validate_hello },
> { OFP10_T_ERROR,NULL, ofp10_validate_error },
> { OFP10_T_ECHO_REQUEST, ofp10_echo_request, NULL },
> { OFP10_T_ECHO_REPLY, NULL, NULL },
> @@ -262,13 +262,8 @@ ofp10_hello(struct switchd *sc, struct s
> return (-1);
> }
>
> - /* Echo back the received Hello packet */
> - oh->oh_version = OFP_V_1_0;
> - oh->oh_length = htons(sizeof(*oh));
> - oh->oh_xid = htonl(con->con_xidnxt++);
> - if (ofp10_validate(sc, &con->con_local, &con->con_peer, oh, NULL) != 0)
> + if (ofp_recv_hello(sc, con, oh, ibuf) == -1)
> return (-1);
> - ofp_output(con, oh, NULL);
>
> #if 0
> (void)write(fd, &oh, sizeof(oh));
> Index: ofp13.c
> ===
> RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp13.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 ofp13.c
> --- ofp13.c 21 Nov 2016 19:33:12 - 1.39
> +++ ofp13.c 22 Nov 2016 14:49:27 -
> @@ -109,7 +109,7 @@ intofp13_tablemiss_sendctrl(struct swi
> uint8_t);
>
> struct ofp_callback ofp13_callbacks[] = {
> - { OFP_T_HELLO, ofp13_hello, NULL },
> + { OFP_T_HELLO, ofp13_hello, ofp_validate_hello },
> { OFP_T_ERROR, NULL, ofp13_validate_error },
> { OFP_T_ECHO_REQUEST, ofp13_echo_request, NULL },
> { OFP_T_ECHO_REPLY, NULL, NULL },
> @@ -639,13 +639,8 @@ ofp13_hello(struct switchd *sc, struct s
> return (-1);
> }
>
> - /* Echo back the received Hello packet */
> - oh->oh_version = OFP_V_1_3;
> - oh->oh_length = htons(sizeof(*oh));
> - oh->oh_xid = htonl(con->con_xidnxt++);
> - if (ofp13_validate(sc, &con->con_local, &con->con_peer, oh, NULL) != 0)
> + if (ofp_recv_hello(sc, con, oh, ibuf) == -1)
> return (-1);
> - ofp_output(con, oh, NULL);
>
> /* Ask for switch features so we can get more information. */
> if (ofp13_featuresrequest(sc, con) == -1)
> Index: of
switchd(8): negotiate versions with hello
Teach switchd(8) how to negotiate protocol version using the hello bitmap
header. This way switchd(8) is able to fallback or use higher version using
the bitmap.
This diff also prevents connections from switching version in the middle of
the operation.
This is the first step before adding a state machine to switchd(8): move the
hello to a common function and make it step into the first state: HELLO_WAIT.
(next diff)
ok?
Index: ofp.c
===
RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp.c,v
retrieving revision 1.15
diff -u -p -r1.15 ofp.c
--- ofp.c 4 Nov 2016 22:27:08 - 1.15
+++ ofp.c 22 Nov 2016 14:55:12 -
@@ -132,6 +132,13 @@ ofp_input(struct switch_connection *con,
return (-1);
}
+ if (con->con_version != OFP_V_0 &&
+ oh->oh_version != con->con_version) {
+ log_debug("wrong version %d, expected %d",
+ oh->oh_version, con->con_version);
+ return (-1);
+ }
+
switch (oh->oh_version) {
case OFP_V_1_0:
if (ofp10_input(sc, con, oh, ibuf) != 0)
@@ -165,6 +172,10 @@ ofp_open(struct privsep *ps, struct swit
log_info("%s: new connection %u.%u from switch %u",
__func__, con->con_id, con->con_instance,
sw == NULL ? 0 : sw->sw_id);
+
+ /* Send the hello with the latest version we support. */
+ if (ofp_send_hello(ps->ps_env, con, OFP_V_1_3) == -1)
+ return (-1);
return (0);
}
Index: ofp10.c
===
RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp10.c,v
retrieving revision 1.16
diff -u -p -r1.16 ofp10.c
--- ofp10.c 21 Nov 2016 18:19:51 - 1.16
+++ ofp10.c 22 Nov 2016 15:08:02 -
@@ -60,7 +60,7 @@ intofp10_validate_packet_out(struct sw
struct ofp_header *, struct ibuf *);
struct ofp_callback ofp10_callbacks[] = {
- { OFP10_T_HELLO,ofp10_hello, NULL },
+ { OFP10_T_HELLO,ofp10_hello, ofp_validate_hello },
{ OFP10_T_ERROR,NULL, ofp10_validate_error },
{ OFP10_T_ECHO_REQUEST, ofp10_echo_request, NULL },
{ OFP10_T_ECHO_REPLY, NULL, NULL },
@@ -262,13 +262,8 @@ ofp10_hello(struct switchd *sc, struct s
return (-1);
}
- /* Echo back the received Hello packet */
- oh->oh_version = OFP_V_1_0;
- oh->oh_length = htons(sizeof(*oh));
- oh->oh_xid = htonl(con->con_xidnxt++);
- if (ofp10_validate(sc, &con->con_local, &con->con_peer, oh, NULL) != 0)
+ if (ofp_recv_hello(sc, con, oh, ibuf) == -1)
return (-1);
- ofp_output(con, oh, NULL);
#if 0
(void)write(fd, &oh, sizeof(oh));
Index: ofp13.c
===
RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp13.c,v
retrieving revision 1.39
diff -u -p -r1.39 ofp13.c
--- ofp13.c 21 Nov 2016 19:33:12 - 1.39
+++ ofp13.c 22 Nov 2016 14:49:27 -
@@ -109,7 +109,7 @@ int ofp13_tablemiss_sendctrl(struct swi
uint8_t);
struct ofp_callback ofp13_callbacks[] = {
- { OFP_T_HELLO, ofp13_hello, NULL },
+ { OFP_T_HELLO, ofp13_hello, ofp_validate_hello },
{ OFP_T_ERROR, NULL, ofp13_validate_error },
{ OFP_T_ECHO_REQUEST, ofp13_echo_request, NULL },
{ OFP_T_ECHO_REPLY, NULL, NULL },
@@ -639,13 +639,8 @@ ofp13_hello(struct switchd *sc, struct s
return (-1);
}
- /* Echo back the received Hello packet */
- oh->oh_version = OFP_V_1_3;
- oh->oh_length = htons(sizeof(*oh));
- oh->oh_xid = htonl(con->con_xidnxt++);
- if (ofp13_validate(sc, &con->con_local, &con->con_peer, oh, NULL) != 0)
+ if (ofp_recv_hello(sc, con, oh, ibuf) == -1)
return (-1);
- ofp_output(con, oh, NULL);
/* Ask for switch features so we can get more information. */
if (ofp13_featuresrequest(sc, con) == -1)
Index: ofp_common.c
===
RCS file: /home/obsdcvs/src/usr.sbin/switchd/ofp_common.c,v
retrieving revision 1.7
diff -u -p -r1.7 ofp_common.c
--- ofp_common.c17 Nov 2016 13:10:26 - 1.7
+++ ofp_common.c22 Nov 2016 14:53:45 -
@@ -43,6 +43,8 @@
#include "switchd.h"
#include "ofp_map.h"
+intofp_setversion(struct switch_connection *, int);
+
int
ofp_validate_header(struct switchd *sc,
struct sockaddr_storage *src, struct sockaddr_storage *dst,
@@ -114,6 +116,177 @@ ofp_output(struct switch_connection *con
}
o
Hello! My name is Keila.
Hey! I found ur profile in the internet a couple days ago and I gotta say that I was astonished. I dunnaw what this is but You got something that attracts everyone to you. I didn't even notice how I started to write to you... I almost forgot, my name is Keila. I travel a lot and I love it so much! I always wanna go to some new places and I think that I'll go on until I found someone whom I'd like for real... Anyway I like to get to know new interesting people no matter where they are from. Can u tell me something about yourself?))) What kind of man are u? What you like? Why would u like to write me back tomorrow???))) Can't wait for your answer... Please write me back when you got some time. Later!
Re: Hello
* Ali Gouta [2011-04-13 11:39]:
> Hello,
>
> So here I want to show share with you some information.
> In fact, to be able te cout traffic of one session its already counted in :
> pf.c in s->bytes[dirndx] += pd.tot_len;
> there is no way to make this done only to modify some kernel code because
> once a state is created on a session there is no way to change queue only by
> acting on the qid and pqid used in a state ...
>
> So I found in pf.c (always) :
> if (s) {
> pf_scrub_ip(&m, s->state_flags, s->min_ttl, s->set_tos);
> pf_tag_packet(m, s->tag, s->rtableid);
> if (pqid || (pd.tos & IPTOS_LOWDELAY))
> qid = s->pqid;
> else
> qid = s->qid;
> } else {
> pf_scrub_ip(&m, r->scrub_flags, r->min_ttl, r->set_tos);
> pf_tag_packet(m, r->tag, r->rtableid);
> if (pqid || (pd.tos & IPTOS_LOWDELAY))
> qid = r->pqid;
> else
> qid = r->qid;
> }
>
> Here I want to propose to you a primary solution that I want to know your
> opinion about :
>
> Change: *if (pqid || (pd.tos & IPTOS_LOWDELAY))*
> qid = s->pqid;
>
> to:
> *
> dirndx = (dir == s->direction) ? 0 : 1;*
> if (pqid || (pd.tos & IPTOS_LOWDELAY) || *(**betoh64(**s->bytes[dirndx]) <
> 15000)*)
> qid = s->pqid;
>
> What do you think about that ? Does it respond to the issue or should I look
> in other functions ??
holy crap. this is wrong in at least 5 ways. please do yourself and
everybody else a favor and don't touch kernel code.
for fun, run that on a 32 bit machine. or a big endian one.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
Re: Hello
Hello,
So here I want to show share with you some information.
In fact, to be able te cout traffic of one session its already counted in :
pf.c in s->bytes[dirndx] += pd.tot_len;
there is no way to make this done only to modify some kernel code because
once a state is created on a session there is no way to change queue only by
acting on the qid and pqid used in a state ...
So I found in pf.c (always) :
if (s) {
pf_scrub_ip(&m, s->state_flags, s->min_ttl, s->set_tos);
pf_tag_packet(m, s->tag, s->rtableid);
if (pqid || (pd.tos & IPTOS_LOWDELAY))
qid = s->pqid;
else
qid = s->qid;
} else {
pf_scrub_ip(&m, r->scrub_flags, r->min_ttl, r->set_tos);
pf_tag_packet(m, r->tag, r->rtableid);
if (pqid || (pd.tos & IPTOS_LOWDELAY))
qid = r->pqid;
else
qid = r->qid;
}
Here I want to propose to you a primary solution that I want to know your
opinion about :
Change: *if (pqid || (pd.tos & IPTOS_LOWDELAY))*
qid = s->pqid;
to:
*
dirndx = (dir == s->direction) ? 0 : 1;*
if (pqid || (pd.tos & IPTOS_LOWDELAY) || *(**betoh64(**s->bytes[dirndx]) <
15000)*)
qid = s->pqid;
What do you think about that ? Does it respond to the issue or should I look
in other functions ??
Thanks.
On Mon, Apr 11, 2011 at 5:02 PM, Todd T. Fries wrote:
> I think most of your difficulties will be solved once the ability to move
> a state to a different queue are solved.
>
> Thanks,
>
> Penned by Ali Gouta on 20110411 4:56.26, we have:
> | Thanks for giving me some idea.
> |
> | @ Peter:
> |
> | > We record those per state anyway, so as a gedankenexperiment, say
> | > we could implement max-src-bytes B/s and max-src-packets P/s modeled on
> | > max-src-conn-rate and have rules like
> | >
> | > pass proto tcp to $somewhere port $wanted keep state (max-src-bytes
> | > 15G/86400, overload flush global)"
> |
> | When the threshold is triggered, the IP gets added to the table,
> | but that will have no effect on the existing connection... Only new
> | connections will cause rule evaluation , Then I think the table would
> have
> | any effect And by adding 'flush', I will kill the existing session
> when
> | the threshold is triggered, which will likely mean the client will notice
> a
> | broken connection and have to re-establish the connection.
> |
> | > And there's a number of ways to
> | > achieve roughly what Ali is asking for in near-realtime with some
> | > scriptery and pfctl output parsing
> |
> | I understand from this that when a threshold would be triggered => then I
> | add a rule on the fly in pf.conf
> | But:
> |
> | Adding a rule when the threshold is triggered will have no effect on the
> | existing connection. Rules are only evaluated for the first packet of a
> | connection. Then, a state (session) entry is created. Subsequent packets
> | of the same connection will pass (and be queued) based on the state
> | entry (and the rule that created the state).
> |
> | I reached these conclusions with some support of "Daniel Hartmeier" who
> gave
> | me some reflexions... I think the only solution is to modify the pf.c and
> | surely other related files.
> | The main function I would have interest in *sys/net/pf.c*
> | would be : *pf_test(int dir, struct ifnet *ifp, struct mbuf **m0,
> | struct ether_header *eh)*
> | So I think things would be more comlicated in that case !!! Any
> suggestion ?
> |
> | On Sat, Apr 9, 2011 at 2:54 PM, Peter N. M. Hansteen >wrote:
> |
> | > Stuart Henderson writes:
> | >
> | > > There's a big problem which makes it not generally useful: if your
> | > > users have multithreaded downloads/uploads or P2P traffic with many
> | > > peers, bandwidth will just split across a larger number of sessions.
> | > > In that case queueing per source address (probably with hfsc
> | > > linkshare which can reduce the speed of traffic after a certain
> | > > time) would be a much better idea.
> | >
> | > hfsc has a lot going for it, true. And there's a number of ways to
> | > achieve roughly what Ali is asking for in near-realtime with some
> | > scriptery and pfctl output parsing (plus a few other approaches), but
> | > for the use case he describes it *might* make sense to have max-src-*
> | > state tracking options that trigger on number of bytes or packets
> | > passed.
> | >
> | > We record those per state anyway, so as a gedankenexperiment, say
> | > we could implement max-src-bytes B/s and max-src-packets P/s modeled on
> | > max-src-conn-rate and
Re: Hello
Thanks for giving me some idea. @ Peter: > We record those per state anyway, so as a gedankenexperiment, say > we could implement max-src-bytes B/s and max-src-packets P/s modeled on > max-src-conn-rate and have rules like > > pass proto tcp to $somewhere port $wanted keep state (max-src-bytes > 15G/86400, overload flush global)" When the threshold is triggered, the IP gets added to the table, but that will have no effect on the existing connection... Only new connections will cause rule evaluation , Then I think the table would have any effect And by adding 'flush', I will kill the existing session when the threshold is triggered, which will likely mean the client will notice a broken connection and have to re-establish the connection. > And there's a number of ways to > achieve roughly what Ali is asking for in near-realtime with some > scriptery and pfctl output parsing I understand from this that when a threshold would be triggered => then I add a rule on the fly in pf.conf But: Adding a rule when the threshold is triggered will have no effect on the existing connection. Rules are only evaluated for the first packet of a connection. Then, a state (session) entry is created. Subsequent packets of the same connection will pass (and be queued) based on the state entry (and the rule that created the state). I reached these conclusions with some support of "Daniel Hartmeier" who gave me some reflexions... I think the only solution is to modify the pf.c and surely other related files. The main function I would have interest in *sys/net/pf.c* would be : *pf_test(int dir, struct ifnet *ifp, struct mbuf **m0, struct ether_header *eh)* So I think things would be more comlicated in that case !!! Any suggestion ? On Sat, Apr 9, 2011 at 2:54 PM, Peter N. M. Hansteen wrote: > Stuart Henderson writes: > > > There's a big problem which makes it not generally useful: if your > > users have multithreaded downloads/uploads or P2P traffic with many > > peers, bandwidth will just split across a larger number of sessions. > > In that case queueing per source address (probably with hfsc > > linkshare which can reduce the speed of traffic after a certain > > time) would be a much better idea. > > hfsc has a lot going for it, true. And there's a number of ways to > achieve roughly what Ali is asking for in near-realtime with some > scriptery and pfctl output parsing (plus a few other approaches), but > for the use case he describes it *might* make sense to have max-src-* > state tracking options that trigger on number of bytes or packets > passed. > > We record those per state anyway, so as a gedankenexperiment, say > we could implement max-src-bytes B/s and max-src-packets P/s modeled on > max-src-conn-rate and have rules like > > pass proto tcp to $somewhere port $wanted \ >keep state (max-src-bytes 15G/86400, \ > overload flush global) > > that is, no source address allowed more than 15GB per day, or we bump > to table bytehogs for whatever treatment is appropriate or > > pass proto tcp to $somewhere port $wanted \ >keep state (max-src-packets 1G/86400, \ > overload flush global) > > to trigger on some insane number of packets instead. > > Not sure if it stands out as a screaming must-have feature, but after > about half an hour mulling the idea I kinda like it for now. > > - Peter > > -- > 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.
Re: Hello
Stuart Henderson writes: > There's a big problem which makes it not generally useful: if your > users have multithreaded downloads/uploads or P2P traffic with many > peers, bandwidth will just split across a larger number of sessions. > In that case queueing per source address (probably with hfsc > linkshare which can reduce the speed of traffic after a certain > time) would be a much better idea. hfsc has a lot going for it, true. And there's a number of ways to achieve roughly what Ali is asking for in near-realtime with some scriptery and pfctl output parsing (plus a few other approaches), but for the use case he describes it *might* make sense to have max-src-* state tracking options that trigger on number of bytes or packets passed. We record those per state anyway, so as a gedankenexperiment, say we could implement max-src-bytes B/s and max-src-packets P/s modeled on max-src-conn-rate and have rules like pass proto tcp to $somewhere port $wanted \ keep state (max-src-bytes 15G/86400, \ overload flush global) that is, no source address allowed more than 15GB per day, or we bump to table bytehogs for whatever treatment is appropriate or pass proto tcp to $somewhere port $wanted \ keep state (max-src-packets 1G/86400, \ overload flush global) to trigger on some insane number of packets instead. Not sure if it stands out as a screaming must-have feature, but after about half an hour mulling the idea I kinda like it for now. - Peter -- 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.
Re: Hello
Thanks fo answering, Yes Indeed I already thougt about using HSCF!!! And then I can manage the bandwidth between queues and give for example one 60% then the second 30% then the third 10%. But Stuart, I am not dealing with simple traffic a domestic one. But I will replay a capture of traffic that contains thousands of sessions. That's why I need in real time detect the volume of a session and then redirect sessions that exceeded a threshold to the second then the third queue.However, I liked what you said about pfctl although it would be quit complicate... I have to fetch more in that direction, thanks. On Sat, Apr 9, 2011 at 1:05 PM, Stuart Henderson wrote: > On 2011/04/09 10:44, Ali Gouta wrote: > > Hello, > > > > My issue is to count trafic of a session and then act on that session > > according to its volume . First, a session is defined as the > > following: *"@source, > > @dest, Port source, Port dest, and protocole used TCP/UDP/ICMP". > > > > *Then after creating 3 queues* *using altq with different priorities, I > want > > to redirect a session that exceeded a threshold to a less priority > queue.To > > do that I need to modify the code of pf.c. > > > > I think I suceeded to fix some parts of the code that interest me : > > I found the function : *pf_test() in sys/net/pf.c and the line > > s->bytes[dirndx] += pd.tot_len; and then pqid will surely interest me.* > > But After focusing on that deeply,I found that this line will count all > > trafic (of all connections) that crosses the firewall... But in my case I > > need to count trafic of *sessions* and act on them. Any Idea ??? thanks > in > > advance. > > The sane way to define traffic of a session in PF is "traffic > matching a state". And s->bytes does contain this, you can see it > with pfctl -ss -v. > > int pqid (as used in pf_test) is a flag set for high-priority packets > (empty acks, packets with LOWDELAY tos) telling altq whether to use the > second queue of a rule definition / state (pf_state.pqid) instead of > the first "normal" one (pf_state.qid). I think to do what you're asking > for, you'd need an analogous lowpriorityqid (and infrastructure in > pfctl to set a third queue, somewhere to pass the number of bytes > through from rules, and changes to the pf_state and pf_rule structures > to hold all of this). So it's adding a lot more complexity and I'm > not convinced it's useful enough to be worth it. > > There's a big problem which makes it not generally useful: if your > users have multithreaded downloads/uploads or P2P traffic with many > peers, bandwidth will just split across a larger number of sessions. > In that case queueing per source address (probably with hfsc > linkshare which can reduce the speed of traffic after a certain > time) would be a much better idea. (Though yes you do have to > define a large number of queues if you have a lot of users behind > it - in that case the config can be awkward to handle, so you might > want some program to generate your pf.conf) > > If you want to play around with HFSC (and I'd recommend this before > considering changing code), here's some suggested reading... > > http://forum.pfsense.org/index.php/topic,2718.msg48336.html#msg48336 > http://www.probsd.net/pf/index.php/Hednod's_HFSC_explained > http://forum.pfsense.org/index.php?topic=33950.0 > http://forum.pfsense.org/index.php/topic,3050.0.html > "Building firewalls with OpenBSD and PF" (slightly outdated as it > pre-dates PF nat changes - in particular I think the "queuing incoming > packets" section talking about needing two boxes no longer applies - > but on the whole the altq section in here is rather good).
Re: Hello
On 2011/04/09 10:44, Ali Gouta wrote: > Hello, > > My issue is to count trafic of a session and then act on that session > according to its volume . First, a session is defined as the > following: *"@source, > @dest, Port source, Port dest, and protocole used TCP/UDP/ICMP". > > *Then after creating 3 queues* *using altq with different priorities, I want > to redirect a session that exceeded a threshold to a less priority queue.To > do that I need to modify the code of pf.c. > > I think I suceeded to fix some parts of the code that interest me : > I found the function : *pf_test() in sys/net/pf.c and the line > s->bytes[dirndx] += pd.tot_len; and then pqid will surely interest me.* > But After focusing on that deeply,I found that this line will count all > trafic (of all connections) that crosses the firewall... But in my case I > need to count trafic of *sessions* and act on them. Any Idea ??? thanks in > advance. The sane way to define traffic of a session in PF is "traffic matching a state". And s->bytes does contain this, you can see it with pfctl -ss -v. int pqid (as used in pf_test) is a flag set for high-priority packets (empty acks, packets with LOWDELAY tos) telling altq whether to use the second queue of a rule definition / state (pf_state.pqid) instead of the first "normal" one (pf_state.qid). I think to do what you're asking for, you'd need an analogous lowpriorityqid (and infrastructure in pfctl to set a third queue, somewhere to pass the number of bytes through from rules, and changes to the pf_state and pf_rule structures to hold all of this). So it's adding a lot more complexity and I'm not convinced it's useful enough to be worth it. There's a big problem which makes it not generally useful: if your users have multithreaded downloads/uploads or P2P traffic with many peers, bandwidth will just split across a larger number of sessions. In that case queueing per source address (probably with hfsc linkshare which can reduce the speed of traffic after a certain time) would be a much better idea. (Though yes you do have to define a large number of queues if you have a lot of users behind it - in that case the config can be awkward to handle, so you might want some program to generate your pf.conf) If you want to play around with HFSC (and I'd recommend this before considering changing code), here's some suggested reading... http://forum.pfsense.org/index.php/topic,2718.msg48336.html#msg48336 http://www.probsd.net/pf/index.php/Hednod's_HFSC_explained http://forum.pfsense.org/index.php?topic=33950.0 http://forum.pfsense.org/index.php/topic,3050.0.html "Building firewalls with OpenBSD and PF" (slightly outdated as it pre-dates PF nat changes - in particular I think the "queuing incoming packets" section talking about needing two boxes no longer applies - but on the whole the altq section in here is rather good).
Re: Hello
Ali Gouta writes: > My issue is to count trafic of a session and then act on that session > according to its volume . First, a session is defined as the > following: *"@source, > @dest, Port source, Port dest, and protocole used TCP/UDP/ICMP". it sounds like the keyword you're really looking for is 'state', defined very close to where you've been poking around. - Peter -- 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.
Hello
Hello, My issue is to count trafic of a session and then act on that session according to its volume . First, a session is defined as the following: *"@source, @dest, Port source, Port dest, and protocole used TCP/UDP/ICMP". *Then after creating 3 queues* *using altq with different priorities, I want to redirect a session that exceeded a threshold to a less priority queue.To do that I need to modify the code of pf.c. I think I suceeded to fix some parts of the code that interest me : I found the function : *pf_test() in sys/net/pf.c and the line s->bytes[dirndx] += pd.tot_len; and then pqid will surely interest me.* But After focusing on that deeply,I found that this line will count all trafic (of all connections) that crosses the firewall... But in my case I need to count trafic of *sessions* and act on them. Any Idea ??? thanks in advance.
