Re: Dragonflybsd's pf concurrent instead of single-threaded
On 08 Jul 2014, at 04:55, Henning Brauer hb-open...@ml.bsws.de wrote: * Franco Fichtner slash...@gmail.com [2014-07-06 00:29]: Missing SMP support is the fork in the road. The window of opportunity seems to be closing. A penny for Henning's thoughts on this... my thoughts are only worth pennies? :) It's a kind thing to say, I think. :) ok, first thought: where's your diff? Not directed at Franco specifically. See below. I don't owe anybody anything. OpenBSD hacking is supposed to be fun for me. That's true. I'm not saying otherwise. on a technical note - making pf MP is utterly useless if the underlaying subsystems aren't. pool isn't, mbuf isn't, network stack isn't - the list is long. Exactly, the underlying cause for this: a lot of complicated subsystems need to be adapted. Some people have this on their ``list of things to do'' as stated a while back, but when there isn't enough incentive to work on this, at least for OpenBSD, it's hard to get started from the outside. The perfect code for the perfect SMP needs to be written and that's not something ``a diff'' from non-developers could easily accomplish. None of this is bad. OpenBSD will always be OpenBSD, no matter what. And the possible pf MP gains are drasticly overrated anyway. I'm not sure. Maybe that's a stance that fits OpenBSD well, but in networking as a whole that's not applicable. There's a good market for 10G, 40G not so much but it exists (as in drivers make their way into BSDs). Hardware vendors get ready for 100G; I've seen one of those cards and it does reveal a good deal of bottlenecks inside modern kernels. Yes, this requires specific mainstream architectures and PCIe 3.0, which is a small subset of OpenBSD system coverage. I can see that it doesn't make much sense from this point of view. That's where FreeBSD and DragonFly are a better fit. So maybe all that needs to change is the perception of pf(4) ports in other BSDs to be ``very old versions that need to be brought up to date'', because doing so wouldn't solve the most pressing issues we are confronted with pf(4) outside of OpenBSD -- the code itself is stable and the features are well-defined as is. Cheers, Franco
Re: Dragonflybsd's pf concurrent instead of single-threaded
On 06 Jul 2014, at 01:01, Predrag Punosevac punoseva...@gmail.com wrote: The rumors are that npf is a vaporware. npf(4) is a chain of clever data structures. How well that translates to the actual requirements of the networking domain I can't see. DragonFly community is tiny. You mean alive and well. That's all that matters to keep us going. ;) tiny that in-spite of HAMMER I could not use DragonFly on my production file servers because it lacks LDAP support let alone NFSv4. Let's talk about this off-list. FreeBSD always had its own genuine firewall solution IPFW. I haven't seen much use of ipfw(4) in the last years, and what it is (still) being used for is not capable of scaling up anymore. The clear preference seems to be pf(4) these days. That being said OpenBSD project has its own pace which has never being dictated by current fashion trends or a noise made by people like me who don't contribute the code. I appreciate the steady course as well, although I would not label SMP as a ``current fashion trend'' that's likely to disappear again. Cheers, Franco
Re: Dragonflybsd's pf concurrent instead of single-threaded
On 08 Jul 2014, at 09:58, Henning Brauer hb-open...@ml.bsws.de wrote: this has NOTHING to do with the problem or the question at hand. So then what has it to do with? You tell me I missed the obvious but don't provide your arguments. Lucky, I've been asked to leave this mailing list so you don't have to bother. Good luck. Cheers, Franco
Re: Dragonflybsd's pf concurrent instead of single-threaded
On 05 Jul 2014, at 23:42, Predrag Punosevac punoseva...@gmail.com wrote: I have immense respect for Matt as a user of his code since Amiga C compiler. I probably speak for lots of people both in OpenBSD and DragonFly camp if I say that I would prefer him to finish HAMMER2 and leave concurrent threading in PF to Henning. Talks about this date back at least two years. These days NetBSD is doing npf(4), and FreeBSD and DragonFly moved on to implement their own SMP support. Missing SMP support is the fork in the road. The window of opportunity seems to be closing. A penny for Henning's thoughts on this... Cheers, Franco
Re: crowding out bsd using systemd?
On 29 Jun 2014, at 13:43, Antoine Jacoutot ajacou...@bsdfrog.org wrote: Why are people poluting our lists with systemd rants??? There is nothing to discuss since we do not want and will never have systemd. If you don't understand what the systemd-utl GSoC is about then move along. First of all, this is misc@. And, secondly, whenever different opinions meet there is potential to learn and improve. Thank you for your understanding. Cheers, Franco
Re: crowding out bsd using systemd?
On 28 Jun 2014, at 19:55, frank ernest do...@mail.com wrote: wanted to know, before assuming that it is the case everywhere, do people really not like systemd and is it really hurting bsd? If so, I'd be interested in doing something about it. Thanks, David A fact is that systemd slowly tears the open source world apart. Whether that is a bad thing for BSD or a bad thing for Linux is something that only time will tell. There is no sign of decline in BSD activity, both development and usage, as far as I can tell. Another fact is that systemd is driven by a large cooperation and aimed for maximum coverage, which has been mostly achieved. Whether the framework has a skynet-esque future ahead of it is something that remains to be seen as well. With all the `tentacles' mentioned by Stuart, that is not a far-fetched, yet still daring, possibility. Finally, systemd is written by remarkable people who more often than not fail to address the constructive criticism they have been facing. Their lack for the other side will keep them from making systemd something that is worthwhile for all of today's modern operating systems if such a feat can indeed be achieved. I'm not so sure. If we are in such dire need of an init system replacement, why has there not been widespread frenzy as with schedulers, package managers, packet filters, programming languages and so forth? Cheers, Franco
Re: new OpenSSL flaws
On 07 Jun 2014, at 08:38, Maxime Villard m...@m00nbsd.net wrote: Contributing code upstream would have been a way more productive approach; It's already been stated that working with upstream is out of the question for at least the following reasons: * Bugs linger unattended for years. * The code style is next to unreadable for outsiders. * C security standards and best practices are severely lacking. * Upstream doesn't have the manpower to change any of this. And my favourite bit: * Upstream generates money by enforcing the above. It's a business model. From an economical standpoint a good one, but technologically, ethically and ideologically it's a disaster for our modern society that bases a lot of trust on OpenSSL. It's when open source effectively becomes broken source, and the only way to change that is to fork or rewrite. OpenSSL and everybody willing to use it will be able to benefit freely from LibReSSL efforts, given that they commit to improving their code base. A project that's not willing to improve on its own should, bluntly put, die as soon as possible. There is no reason to state your opinion about how OpenSSL should have been fixed given the facts that you chose to ignore. Consider the possibility that your view is wrong. And don't assume that LibReSSL is the right thing, it's just a thing. Well, a good thing. Definitely not a bad thing. I hope we can agree on that. Cheers, Franco
Re: icanhaze.c OpenSSH exploit?
On 06 May 2014, at 19:32, Ted Unangst t...@tedunangst.com wrote: On Tue, May 06, 2014 at 09:50, Dustin Lundquist wrote: Does anyone have any information that can share? http://pastebin.com/raw.php?i=gjkivAf3 OpenBSD isn't affected, so no need to worry. Thanks, now I do worry.
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: LibreSSL appreciation thread
Shut up and take my money. And keep up the great work.
Re: author emails in manpages
On Jul 12, 2013, at 3:16 PM, Jason McIntyre j...@kerhand.co.uk wrote: perhaps. either Mt is fairly new, or i never noticed it before. we could wholesale change stuff, but haven;t yet. it probably does make sense for folks who want stuff like html pages. i did add an Mt fairly recently, but there can;t be many in tree. Looks like this is almost exclusively used in mandoc/mdocml for most BSDs. Apparently nobody got the memo. ;)
Re: Why does OpenBSD use CVS?
On Apr 20, 2013, at 1:02 PM, na...@mips.inka.de (Christian Weisgerber) wrote: Alokat MacMoneysack mail...@alokat.org wrote: I find it a little bit difficult to see the commits from the developers. Because I have to check out the single files and not a single commit. You might find the cvsps package useful. Or use https://bitbucket.org/braindamaged/openbsd-src to catch up on commits or skim through the history of -current. Franco
Re: How to configure pppoe client on OpenBSD?
On Jan 13, 2013, at 7:47 PM, Michał Markowski markows...@gmail.com wrote: 2013/1/13 Random, Eyes randome...@postafiok.hu: I have an OpenBSD 5.1 installed + a cable from my ISP. I have the username/password for the PPPoE connection, but how can I configure the connection to be permanent? (I have 1 interface on the machine.) http://lmgtfy.com/?q=openbsd+pppoe There should be a let-me-find-that-man-page-for-you for that sort of thing. I mean the first hit is the man page, and apparently it's very hard for some people to get over such additional hurdles. Or if there only was a way to search in man pages. :)
Re: How to configure pppoe client on OpenBSD?
On Jan 14, 2013, at 2:28 AM, Stuart Henderson s...@spacehopper.org wrote: On 2013-01-13, Franco Fichtner slash...@gmail.com wrote: There should be a let-me-find-that-man-page-for-you for that sort of thing. There is - post the question to misc@! Or if there only was a way to search in man pages. :) But you'd half to read the manual for man(1) to learn all about that! Someone makes a joke about apropos(1) and everyone feels to 'correct' that joke by spelling it out. Just a normal day on misc@. Thanks, but, no. You need to understand that people asking question here have no idea about the marvellous man pages in OpenBSD and they never will (because then they would not be asking in the first place). If it weren't for jmc@'s love for tweaking man pages I'd still be in that very same spot, but, fortunately, that hasn't been the case for a while now. Teaching is hard, but being impatient and judgmental on people asking questions is not the way, especially on an open mailing list. Having 'annoying' questions pop up again and again is an opportunity to do something fundamental to improve the situation. Nobody gets to get grumpy over it. But somewhere deep down, some people like it that way and do not wish to change it, because it may keep the 'dump' people away. For what it's worth, the original question got cleared up a few times over, so not all is lost. ;)
Re: ftps?
On Nov 29, 2012, at 11:35 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: Because they can just hack it on top of their crusty old ftp server software, whereas using sftp would need much bigger changes? SSL/TLS makes everything more secure And DPI-based products are slow to fix their issues caused by the STARTTLS family of commands. (This is for the paranoid.)
Re: Crowding out OpenBSD
On Nov 17, 2012, at 3:49 AM, Amit Kulkarni amitk...@gmail.com wrote: https://lwn.net/Articles/524606/ don't have a subscription but for those who do, enjoy. I like Jonathan's work, but this article is ill-conceived. He picks up on Marc's upstream vendor remarks, then turns this into an issue of BSD does not have the strength to keep up with the (Linux) world we live in and that BSD might eventually be phased out due to: * lack of contemporary desktop support * lack of hardware support * lack of mobile goodies * lack of developers While it's easy to focus on the dark side of things, that's not the full picture. The whole GPL idea looks like it's getting into serious trouble in the coming years (see NVIDIA vs. DMA-BUF or Red Hat's recent SCSI target code mockery), with BSD being the more competitive license for business owners, who will NOT hesitate to ditch Linux given the chance. And GPL benefiting from BSD but not the other way around is childish at best. Upstream vendors will want to see their product not reach a dead end, which is, to be totally frank, part of the process. If GNOME doesn't make it because of their strategy, then that's a great day for desktops. And if they succeed, then everybody else will cope some way or another. On the upside, the comments to the article are surprisingly good, with lots of ideas and questions on how to not let the community as a whole fall apart. If anyone is interested in the full article, here you go: http://lwn.net/SubscriberLink/524606/611b3cb2f33e32ae/ Franco
Re: OpenBSD on GitHub
On Aug 6, 2012, at 12:02 PM, Marc Espie es...@nerim.net wrote: Well, I have an actual list of advantages that git may offer: Thanks, Marc. Good listing! I wonder what CVS brings to the table on the bright side? I understand everything that's been said. I've even come to hate GPL'ed software just because of using the license in the first place (didn't come up yet, but I know this is an issue, too). But I don't think git would be the downfall of OpenBSD. There's too much drive and too much brains at work to go down the slippery slope. But don't let that get to your heads. :P Git doesn't force a workflow on you. Where I used to work, I'd rather have everyone push their changes to the master (or trunk) commit by commit, telling them to break down larger changes, keeping bug fixes and features separate, wiping out stupid merges that did not even cause any conflicts, etc. Linux Kernel maintainers have done this for years, even the manual apply of hundreds of emailed patches. You can go the other way and maintain a -load of local patches, ponder on dead-end feature branches, do trigger happy merges, but you don't have to at all. Rebasing patches to avoid merges is the holy grail of git. Cherry-picking the most interesting commits on top of this functionality is even more awesome. Ok, back to the original question... Having an up-to-date git read-only mirror (on github, or where ever it's hip to put it) would be nice. I really don't mind the hipster crowd to go and fork the repository. I don't think those people would bother going through the painful process of sending patches the OpenBSD way with all the hassles in place. Maybe like this, it's going to be easier to grab stuff as a maintainer and get more exposure on general. Franco
Re: ss20's wanted for ports builds
On Jul 17, 2012, at 9:42 PM, Sevan / Venture37 wrote: On 17 Jul 2012, at 13:50, Gerald Thornberry ger...@thornberry.net wrote: For those of us who don't have the hardware, is there a shipping fund we could donate to? I wouldn't mind chipping in to help get the hardware where it's needed. I need to get a SS20 to phessler@ from the Uk to Germany if people want to help with that, will be looking into how much it costs to ship this week. Brilliant! Please let me know, too. Franco
Re: Virtualizing firewalling scenarios in one physical OpenBSD host
On Jul 4, 2012, at 11:13 AM, C. L. Martinez wrote: On Wed, Jul 4, 2012 at 10:49 AM, Jiri B ji...@devio.us wrote: On Wed, Jul 04, 2012 at 09:29:04AM +0200, C. L. Martinez wrote: Hi all, I wonder if with OpenBSD is possible to create virtualized firewalled implementations of conventional physical topologies and designs such as central and remote DMZs (my question has nothing to do with virtualization platforms like ESXi/vSphere or Xen or KVM), like for example CheckPoint VSX does: http://www.checkpoint.com/products/vpn-1-power-vsx/index.html. So what is that doing? The link is full of marketing shit words :) The great catch here is what VSX does: you can deploy virtual firewalls within the same physical CheckPoint machine. No, the great catch here is that VSX offers you tools to manage up to 250 of these virtual monsters in a centralized fashion. You can also give control of these firewalls to your customers. You can put lots of OpenBSD guests on a host, but there's no way you will be happy when you are seriously thinking about deploying a VSX. Franco
Re: Virtualizing firewalling scenarios in one physical OpenBSD host
On Jul 4, 2012, at 11:51 AM, Henning Brauer wrote: * Franco Fichtner slash...@gmail.com [2012-07-04 11:43]: No, the great catch here is that VSX offers you tools to manage up to 250 of these virtual monsters in a centralized fashion. You can also give control of these firewalls to your customers. You can put lots of OpenBSD guests on a host, but there's no way you will be happy when you are seriously thinking about deploying a VSX. ok, you've been brainwashed by marketing. this is not a question of the firewall at all, but a question of the management interface around it. That's what my first sentence said, actually. But you are right, it just depends on the requirements. I was trying to say without the proper tools in place, doing it might not work for a lot of people for reasons of resources, time or scale. Anyway, I feel truly humbled by this mailing list. Franco
Re: OpenBSD forked
On Jun 22, 2012, at 2:33 PM, Marc Espie wrote: A shell is one of the most complicated pieces of C code to get right, between the fucked-up parser, the lazy evaluation, the arcane shit you have to do to various file descriptors, and the signal handling. Among other things. That's because you think the goal is to write a perfect shell. The goal is to use fork, exec, signals, process groups, etc... yeah, right... and do it without any proper courses either. So that, afterwards, when I quizz students, they don't even understand how wait() works or anything about signal semantics. Yet they validated that specific project... Doing coursework is like a good introduction, but cannot help grasp every concept and titbit of what you are doing. You'll do just as much as you need to in order to pass, and half of the code is probably wrong or simply not needed. I used to fix other semesters' coursework just for fun, and most of the time I wondered how they ever passed in the first place. The real enlightenment comes with the longer projects, when you can look at the same codebase day in, day out. You see the stuff you did half a year ago and shrug. You see other people doing unspeakable things (good and bad). And from time to time you realize the full potential of subtle bugs doing all kinds of crazy things. Sometimes it makes you laugh, sometimes you'll wonder who's going to get fired for it. But in the end you learn so much every day and you'll never be the same again. It really doesn't matter what you do, but if you are not going to use what you write you should think twice about doing it. Maybe you can also focus on adding that feature you always wanted to your favorite software and learn how to deal with revision control tools. Learn debugging unknown (and maybe complex) code, and even learn how hard it can be to avoid code regressions. Franco
Re: OpenBSD forked
On Jun 20, 2012, at 4:53 PM, Peter Laufenberg wrote: On Tue, Jun 19, 2012 at 10:58 PM, Jay Patel rockworl...@gmail.com wrote: Hi all users, I am users too. Thanks cody. I am learning C too. from C primus plus any thoughts from devs. which we should read? Udacity.com had a good python class. Intro, from zero background, to writing a mini-google (crawler + indexer) in 7 weeks. Apparently the original form of duckduckgo (or another search engine) was written in one page of python. WTF? Python must be the best way NOT to learn anything about C. Haha, he probably meant Cython. :P
Re: pf-smp alpha on freebsd
On Jun 17, 2012, at 7:53 PM, Ted Unangst wrote: On Sun, Jun 17, 2012 at 11:43, Holger Glaess wrote: i dident wont start about smp on openbsd but what about this porject ? Did you read the part below? I think it's pretty clear this project isn't going to have much relevance for OpenBSD. From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the #ifdef __FreeBSD__ from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. This sounds like a messy decision. Is this single-mutex stuff in pf true for OpenBSD as of now or a port quirk of FreeBSD's version? I worked on a heavily multi-threaded firewall core for a few years and I would be glad to help pf itself instead of a 4.5-based pf port going SMP, chasing rainbows and unicorns. Franco
Re: pf-smp alpha on freebsd
On Jun 18, 2012, at 11:31 AM, Ryan McBride wrote: No, there is no single mutex around PF specifically in OpenBSD, the whole kernel is wrapped in a biglock. I think if they work out all the nits and dead-ends we may have something to learn from this effort, but I don't see this code coming back to OpenBSD. It's not critical because they can change the state table implementation later - OpenBSD has reorganised this several times with more planned - but we've put quite a bit of effort into removing hash tables in our kernel wherever possible, partly due to their attackability. My personal preference would be to go with a lockless or lock-on-write RB tree for the state table, but without an SMP-safe network stack there's little motivation to work on such things (though it remains somewhere on my todo list). Okay, I've seen practical real world applications with a single-threaded packet capture going into multiple queues for any number of parallel threads. The beauty is going lockless on those multiple queues if you can make sure the same connections always go to the same thread. This, however, is only interesting if you need to go heavy on throughput or processing, namely DPI and friends. It's fairly straight forward from pf's perspective, but I don't know if pfsync may grow more challenging in the process. Hmm, that SMP-safe network stack sounds interesting, too, but IMO this won't help pf as much as the multi-threading. The two would play together for even more scalability, though. Also, I remember having headaches from trying to bounce packets to their designated CPU (soft interrupt context) under Linux to make the distribution queues lockless themselves. SMP-infused network stacks alone won't cut it, if you are going for anything more than raw IP forwarding throughput. Franco
Re: OpenBSD is just an OS, not a firewall...
On Jun 10, 2012, at 9:05 PM, Marc Espie wrote: On Sun, Jun 10, 2012 at 02:14:08PM -0400, Chris Smith wrote: On Sun, Jun 10, 2012 at 1:58 PM, Ted Unangst t...@tedunangst.com wrote: The original post had nothing to do with OpenBSD, some nitwit hijacked the comment thread. I don't think the author has any obligation to play host to a battleground. The original post was about IPv6, someone commented that he couldn't do IPv6 because of problems with his pfSense firewall. I suggested he switch to OpenBSD to ameliorate the issue and that's when he shot off that it isn't a firewall, blah, blah, blah. I saw the comment thread as more of a segue than a hijack. Well, we had enough time to punch the dimwit into the ground before the thread vanished, didn't we ? all that nonsense about hardening... And somehow he got caught up in this if you don't have a GUI you are no firewall argument. I've heard that before at work. Two years later we had to slap together a CLI, because without it we can never be a good firewall. :P Franco
Re: German Government claims to be able to break PGP and SSH
Hi Stefan, On May 24, 2012, at 2:26 PM, Stefan Wollny wrote: Question: 3. Is the technique used also able to at least in part decode and/or analyze encrypted communication (e.g. by SSH of PGP)? Answer: Yes, the technique used is in principle able to do this, depending on the way and quality of the encryption. (Yepp - that's the complete answer!) Is this some sort of Governmental FUD by just NOT adding s.th. like if the password/passphrase is weak enough? I think the answer is very shallow and misguiding. There are only two ways to do this: (1) immediately via man-in-the-middle attacks, or (2) later decryption of recorded traffic. The first method is easily detectable, and the second method creates a lot of overhead in the long run. Storage, where to get private keys from, etc. Both of them offer full decryption, so I am not sure what the partial decode and/or analyze really means. The question is way too broad to get a precise answer. Of course you can decode SSH, but only on the protocol layer itself, not the payload. Analyzing encrypted protocols is easy, and it may raise a flag, but there is no way there's this thing that will read your emails on-the-fly even though you are using PGP. Franco
