Re: event handling in OpenBGPd
On Sun, May 04, 2014 at 10:39:33PM +0200, Vincent Gross wrote: Hi gang, I am considering to write a daemon of some kind, and I was going over OpenBGPd's sources to get some good fine-grained design examples. I noticed that although all IO's are asynchronous, libevent is not used, but I can't figure out why. So, is libevent not used by accident or by design ? in the latter case, what is precisely the feature/design consideration that made it unsuitable ? Don't use bgpd as an example. It was one of the first privsep daemon we did and at that time it was done without libevent. ospfd and all the later daemons use libevent. Their event loop is therefor a lot simpler. So yeah not using libevent in bgpd could be considered an accident. -- :wq Claudio
Re: event handling in OpenBGPd
* Claudio Jeker cje...@diehard.n-r-g.com [2014-05-05 10:50]: On Sun, May 04, 2014 at 10:39:33PM +0200, Vincent Gross wrote: I am considering to write a daemon of some kind, and I was going over OpenBGPd's sources to get some good fine-grained design examples. I noticed that although all IO's are asynchronous, libevent is not used, but I can't figure out why. I'm not a libevent-fan. So I didn't use it. For bgpd, libevent+kqueue vs poll plain doesn't matter, the number of sockets is too low. So, is libevent not used by accident or by design ? in the latter case, what is precisely the feature/design consideration that made it unsuitable ? Don't use bgpd as an example. It was one of the first privsep daemon we did and at that time it was done without libevent. ospfd and all the later daemons use libevent. Their event loop is therefor a lot simpler. So yeah not using libevent in bgpd could be considered an accident. not an accident. however, when I wrote the initial bgpd bits, I didn't think there would be so many daemons using its framework 10 years later. so things changed, and there's no problem with that. wether you use libevent or not is a matter of taste imho unless we're potentially dealing with a very large number of sockets, in which case kqueue has advantages over poll. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: event handling in OpenBGPd
On Mon, May 05, 2014 at 12:28:38PM +0200, Henning Brauer wrote: * Claudio Jeker cje...@diehard.n-r-g.com [2014-05-05 10:50]: On Sun, May 04, 2014 at 10:39:33PM +0200, Vincent Gross wrote: I am considering to write a daemon of some kind, and I was going over OpenBGPd's sources to get some good fine-grained design examples. I noticed that although all IO's are asynchronous, libevent is not used, but I can't figure out why. I'm not a libevent-fan. So I didn't use it. For bgpd, libevent+kqueue vs poll plain doesn't matter, the number of sockets is too low. So, is libevent not used by accident or by design ? in the latter case, what is precisely the feature/design consideration that made it unsuitable ? Don't use bgpd as an example. It was one of the first privsep daemon we did and at that time it was done without libevent. ospfd and all the later daemons use libevent. Their event loop is therefor a lot simpler. So yeah not using libevent in bgpd could be considered an accident. not an accident. however, when I wrote the initial bgpd bits, I didn't think there would be so many daemons using its framework 10 years later. so things changed, and there's no problem with that. wether you use libevent or not is a matter of taste imho unless we're potentially dealing with a very large number of sockets, in which case kqueue has advantages over poll. One of the big advantages of libevent is timeout handling for free. So you don't need to reinvent it on top of poll(). When a daemon has to handle a lot of different event sources libevent tends to be a lot easier since you don't need to write all the timeout handling and there is also no need to build up the pollfd array all by yourself. -- :wq Claudio
ndpi with ntop
Hi, Does anybody know of any integration between PF and ndpi? I would love to be able to block by application (bittorrent, skype...) in PF! If there is nothing out there, would it be a lot of work, is ndpi already working in OpenBSD? Thanks. Richard
Re: ndpi with ntop
Hi Richard, On 05 May 2014, at 14:21, Richard Thornton richie.thorn...@gmail.com wrote: Does anybody know of any integration between PF and ndpi? the previous consensus[1] was that pf(4) and DPI do not mix very well, but you can probably use relayd(8) and run e.g. NDPI on top[2]. Grabbing all traffic is not really fast, especially with no multithreading inside pf(4). A quick alternative would be netmap(4), but that's not available for OpenBSD. If there is nothing out there, would it be a lot of work, is ndpi already working in OpenBSD? It's *a lot* of work, especially when you want 1G and up. Cheers, Franco [1] http://marc.info/?t=13673504521r=1w=2 [2] http://quigon.bsws.de/papers/2013/vbsdcon/
Re: ndpi with ntop
You can use Snort Alpha + ipfw daq + OpenAppId to block applications via divert sockets. But dont forget it is experimental for now and i can not say it is working well... -- Destan YILANCI 5 May 2014 tarihinde 15:21 saatinde, Richard Thornton richie.thorn...@gmail.com Åunları yazdı: Hi, Does anybody know of any integration between PF and ndpi? I would love to be able to block by application (bittorrent, skype...) in PF! If there is nothing out there, would it be a lot of work, is ndpi already working in OpenBSD? Thanks. Richard
queueing question
Hi, I have setup similar to this: BOX1 BOX2 Internet---($isp_if:::$dmz_if)--DMZ--($nat_if:::$int_if)---LAN $isp_if: 10Mbit/s $dmz_if: 1Gbit/s $nat_if: 1Gbit/s $int_if: 1Gbit/s I would like to queue traffic for some services in DMZ for both Internet and LAN clients ( web, ftp, dns, xmpp ), some services residing directly on BOX2 for Internet clients ( pptp, openvpn)and some services on LAN for Internet clients (redirected custom applications). Besides this, I would like to queue outgoing traffic from LAN (high priority dns, low priority p2p etc). Should I queue on all the interfaces? Should I declare 1Gbit on non-isp interfaces and 10Mbit on isp interface? Any other advices? Thank you in advance. -- Marko Cupać
bgpd/session.c+rde.c code explanation
Hello all, I am hacking around OpenBGPd and there is a portion of code I can't quite understand. I wonder why pipe_m2r[2] is passed as a parameter to pid_t session_main(int pipe_m2s[2], int pipe_s2r[2], int pipe_m2r[2], int pipe_s2rctl[2]) (in session.c) and pipe_s2r[2] is passed to pid_t rde_main(int pipe_m2r[2], int pipe_s2r[2], int pipe_m2s[2], int pipe_s2rctl[2], int debug) (in rde.c) It seems the only usage in both these functions is a close() call. What is the point of passing the parameters ? I thought it would be close()'d from main() in bgpd.c. Thank you in advance for any hints. Regards, Denis
Re: EdgeRouter 8 port model
J Sisson [sisso...@gmail.com] wrote: I have some questions regarding the EdgeRouter 8 port (not the POE or PRO, and obviously not the LITE model, as it's already supported). I was curious if the relevant developers have had a chance to get their hands on one of these, and if so, how similar are they to the EdgeRouter LITE? I know manufacturers using the same names for devices in no way implies the devices are internally similar, so I was curious. It probably works just as well as the lite does, which is to say, lacking USB support.
Re: bgpd/session.c+rde.c code explanation
On Mon, May 05, 2014 at 08:25:23PM +0200, Denis Fondras wrote: Hello all, I am hacking around OpenBGPd and there is a portion of code I can't quite understand. I wonder why pipe_m2r[2] is passed as a parameter to pid_t session_main(int pipe_m2s[2], int pipe_s2r[2], int pipe_m2r[2], int pipe_s2rctl[2]) (in session.c) and pipe_s2r[2] is passed to pid_t rde_main(int pipe_m2r[2], int pipe_s2r[2], int pipe_m2s[2], int pipe_s2rctl[2], int debug) (in rde.c) It seems the only usage in both these functions is a close() call. What is the point of passing the parameters ? I thought it would be close()'d from main() in bgpd.c. Thank you in advance for any hints. Regards, Denis Take a look at what fork() does with file descriptors.
Re: bgpd/session.c+rde.c code explanation
Le 05/05/2014 20:35, Stefan Sperling a écrit : Take a look at what fork() does with file descriptors. Thank you Stefan, that's now crystal clear. Denis
