Re: dwb questions
| When the process starts, it issues an error message: | | dwb:/usr/local/lib/libestdc++.so.16.0: /usr/lib/libstdc++.so.57.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your program | | | Also, if anyone could point me to the info about adding | noscript/flashblock extension, it would be even better. | I am aware that it must be possible to disable js and | to block cookies, but cannot find the way. | Hi Zoran, The error message you see relates to webkit, I see it with xombrero browser as well but it never seems to result in any problems displaying pages. Brett.
dwb questions
I was quite happy, seeing dwb browser included in packages for lattest current. Since I found no name of porter, I'd like to ask few questions to the list. When the process starts, it issues an error message: dwb:/usr/local/lib/libestdc++.so.16.0: /usr/lib/libstdc++.so.57.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your program Nothing to be worry about, dwb works even with it. I added extensions: adblock_subscriptions and cookies. Now, in top, I see new processes, that do not go away, when I close dwb: at-spi-bus-launc at-spi2-registry Somebody knows what they are? Also, if anyone could point me to the info about adding noscript/flashblock extension, it would be even better. I am aware that it must be possible to disable js and to block cookies, but cannot find the way. Best regards Zoran
Re: npppd Ipsec L2TP mtu issues.
Hi, On Sun, 7 Sep 2014 21:00:31 +0200 Jens Hansen wrote: > I can successfully connect to my opensbsd 5.5. isakmpd / npppd IPSEC L2TP > vpn setup. > But (not knowing too much about netwoking) i think i'm having a mtu > problem. I can do low volume traffic fine, but transmitting larger files > stalls. I've tried as per suggested by others around the web the > following. > Added scrub on enc0 with an max mss of the pppx0 mtu. "scrub" should be used for the VPN tunnel internal packets. They pass through on pppx0, pppx1,...pppxN. (pppx creates a new clone for each VPN session.) "pppx" interface group should be used. match on pppx scrub ( max-mss 1410 ) > Tried with and without tcp-mss-adjust set to yes in npppd.conf. At first, I think you should set "mru" not to fragment L2TP/IPsec packets on your network and it also is used to fragment properly for the packets inside the VPN links. Also "tcp-mss-adjust yes" may be useful if you want to avoid the PMTU-D blackhole problem. --yasuoka
Re: no zlib from zlib.net
On Sun, Sep 14, 2014 at 10:13:42AM +0800, Tito Mari Francis Esca??o wrote: > Good day, > I'm planning to experiment modifying FirefoxOS to be based on OpenBSD > instead of the default Linux kernel, and it seems we don't have the > corresponding zlib from www.zlib.net. I checked on Ubuntu and they use > zlib 1.2.8, this is the latest version as per zlib homepage. Can > somebody please advise me on this? > Thanks. OpenBSD's zlib is 1.2.3, the associated ChangeLog in src/lib/libz states this version wa released in 2005. The Makefile's CVS log shows sustaining engineering to OpenBSD's libz, with the last commit in 2012.
no zlib from zlib.net
Good day, I'm planning to experiment modifying FirefoxOS to be based on OpenBSD instead of the default Linux kernel, and it seems we don't have the corresponding zlib from www.zlib.net. I checked on Ubuntu and they use zlib 1.2.8, this is the latest version as per zlib homepage. Can somebody please advise me on this? Thanks.
OpenBSD 5.5: ICMP port unreachable to DHCP relay agent...
Hi All, Previously I sent out a very long e-mail about this and I didn't get any responses, so this is my second attempt which will be much shorter. Basically, I am having a problem with the included version of dhcpd in OpenBSD 5.5 stable, and I'm not sure if it's an issue with OpenBSD, or my configuration. I suspect the latter. I have OpenBSD acting as the DHCP server for my private LAN. I have two subnets declared in dhcpd.conf. The first subnet is for a network directly served by the OpenBSD server (clients and OpenBSD server in same L3 broadcast domain). The subnet has fixed assignments for all the clients based on their MAC address, and this is no problem. The second subnet is for a network that is not directly connected to the OpenBSD box, instead there is a static route to reach it. Routing between the two networks works perfectly, and in fact the OpenBSD box is the DNS server for the clients in this remote network. I cannot, however, get DHCP working for those clients. Only when I give a client a static IP address does it work. The L3 switch which serves the clients (it is their default gateway) is configured to act as a DHCP relay, and forwards the DHCP traffic from the clients to the OpenBSD box. Here's the failure: 1. Client broadcasts DHCP Discover 2. L3 switch relays the DHCP discover to the OpenBSD box as a unicast to UDP port 67. 3. OpenBSD box receives the relayed unicast DHCP Discover, and responds with an ICMP unreachable message for UDP port 67, which is received by the L3 switch. It's as if port 67 is not listening on the OpenBSD system. I have verified dhcpd is set to listen on all interfaces. I found that netstat never displays an open socket for port 67, but I have since come to learn dhcpd does not use sockets, but BPF which apparently there is no way I can find to see open connections. This is not a firewall issue, I have tried with pf totally disabled, and in fact I also learned pf can't restrict traffic from a BPF connection to begin with. But port 67 is clearly open. The clients in the same broadcast domain which send their UDP DHCP Discovers to 255.255.255.255 port 67 work perfectly. Does anybody know why the OpenBSD system would be sending ICMP port unreachable messages to the DHCP relay agent in response to its relayed DHCP discovers? The DNS queries from these clients to the OpenBSD system (same IP as the dhcp server) on port 53 all work perfectly. Unlike dhcpd, I can verify with netstat that BIND is listening on port 53 for DNS queries. Warm regards, Andrew
Re: LibreSSL & Post-Quantum World, NTRU
2014-09-13 19:27 GMT+02:00 why not : > hello > > Besides NTRU is having a GPL licence, https://github.com/NTRUOpenSourceProject/ntru-crypto/issues/4 https://github.com/tbuktu/libntru but: http://blog.cr.yp.to/20140213-ideal.html Daniel
Re: pfsync and trunk
On Sat, Sep 13, 2014 at 10:17 AM, Henning Brauer wrote: > * Tony Sarendal [2014-09-03 06:48]: > > The initial request disappearing and the firewalls staying demoted > > "forever" are independent issues. > > sure about that? the demotion counter for the interface group pfsyncX > is part of (usually carp) is kept raised until the bulk transfer > finishes. > Looks like separate issues. I have done more testing since, using 5.5. In all cases the demote counter restores after the bulk transfer completes, or after pfsync gives up after 12 retries. I have a few 5.4 where I can't explain the 33 demote counter, but I can't replicate it when testing. I could replicate the problem with the initial request disappearing when using trunk. The "sleep" solves it, I can live with that. On our heavier firewalls bulk transfer never completes, but carp restores after the 12 retries, close to 29h after reboot. /T
Re: Has anyone gotten qemu to install a Linux vm on OpenBSD5.5, 64bit?
On Sat, Sep 13, 2014 at 10:18:31PM +1000, Brett Mahar wrote: > On Fri, 12 Sep 2014 21:15:59 -0400 > Steve Litt wrote: > > | Hi all, > | > | Has anyone gotten qemu to install a Linux vm on OpenBSD5.5, 64bit? > > Hi Steve, > > There's a readme that is installed when you install the qemu package, you > should check that out. I had opensuse running a while ago (lots of the other > linux distributions would not work). What I did was: > > After creating .img file: > > $ ulimit -d 200 > > $ qemu -m 1300 -no-acpi -monitor stdio -no-fd-bootchk -hda virtual.img -cdrom > openSUSE-11.4-GNOME-LiveCD-i686.iso -boot d > > Then when you get to the installer screen, select f4[kernel version]>safe > mode; F3[graphics]>vesa > > Once installed and virtual disk compressed, normal booting works with: > > $ qemu -m 1300 -no-acpi -no-fd-bootchk -hda virtual.img > > then selecting failsafe mode to boot into a console (no x11) desktop. If you > want a graphical desktop > environment, choose failsafe mode and then delete "nomodeset x11 failsafe" > from the boot arguments. > > This would need to be adjusted for newer qemu, command line options I used > recently with pcbsd were: > > $ qemu-system-x86_64 -m 256 -cdrom > PCBSD10.0.2-RELEASE-06-20-2014-x64-DVD-USB.iso pcbsd-qemu.img > > launch: > $ qemu-system-x86_64 -m 1200 -display gtk -vga std -sdl -hda pcbsd-qemu.img > > Brett. Thanks a lot. I will try that too because I had problems with Linux distributions too. Maybe, this 'Damn Small Linux' thing might be usable... . Gentoo booted, too (the install iso), but I don't want to waste my entire life compiling linux stuff inside qemu. However, I got MINIX up and running within qemu (the system compiles inside the qemu box without any problems) and of course, OpenBSD runs inside qemu, too.
LibreSSL & Post-Quantum World, NTRU
hello Besides NTRU is having a GPL licence, what are the obstacles that need to be overcome to have it in LibreSSL? https://github.com/NTRUOpenSourceProject/ntru-crypto https://www.youtube.com/results?search_query=NTRU+crypto https://crypto.stackexchange.com/questions/11629/public-key-cryptosystems-without-poly-time-quantum-attacks https://www.youtube.com/results?search_query=Quantum%20Computing%20Cryptography It would survive in a Post-Quantum computing era (10-20 years?), while other PKI systems would fail. have a great day,
Re: pf block return sends rst through wrong interface
Hi Thomas, A possible solution to your problem might be to put ext_if1 into its own rdomain with its default route out through ext_if1. /Benno Henning Brauer(hb-open...@ml.bsws.de) on 2014.09.12 18:10:26 +0200: > * Thomas Pfaff [2014-08-28 13:51]: > > I have a router with two external interfaces, ext_if1 and ext_if2, > > where everything gets routed through ext_if2 by default (gateway) > > except for a few daemons on ext_if1. > > > >pass in on $ext_if1 inet proto tcp from any to $ext_if1 \ > > port ssh reply-to ($ext_if1 $ext_gw1) > > > > This seems to work as expected, sending return traffic through > > ext_if1 rather than the default gateway. > > > > The problem is when a connection attempt is made on $ext_if1 to > > a blocked port (set block-policy return). RST is sent through > > ext_if2 rather than ext_if1, thus showing up at the destination > > with the wrong source address. > > > > I'm unable to find a rule that will get the router to send RST > > through the correct interface, so other than using block-policy > > drop to not send RST, is there a way to make it send through > > the correct interface (ext_if1 in this case)? > > pf-generated packets like these RSTs bypass the ruleset, thus never > hit your reply-to. > > I'm not aware of a solution. > > (route-to and reply-to are stupid to begin with. Avoid at all cost.) > > -- > Henning Brauer, h...@bsws.de, henn...@openbsd.org > BS Web Services GmbH, http://bsws.de, Full-Service ISP > Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully > Managed > Henning Brauer Consulting, http://henningbrauer.com/ > --
Re: Has anyone gotten qemu to install a Linux vm on OpenBSD5.5, 64bit?
On Fri, 12 Sep 2014 21:15:59 -0400 Steve Litt wrote: | Hi all, | | Has anyone gotten qemu to install a Linux vm on OpenBSD5.5, 64bit? Hi Steve, There's a readme that is installed when you install the qemu package, you should check that out. I had opensuse running a while ago (lots of the other linux distributions would not work). What I did was: After creating .img file: $ ulimit -d 200 $ qemu -m 1300 -no-acpi -monitor stdio -no-fd-bootchk -hda virtual.img -cdrom openSUSE-11.4-GNOME-LiveCD-i686.iso -boot d Then when you get to the installer screen, select f4[kernel version]>safe mode; F3[graphics]>vesa Once installed and virtual disk compressed, normal booting works with: $ qemu -m 1300 -no-acpi -no-fd-bootchk -hda virtual.img then selecting failsafe mode to boot into a console (no x11) desktop. If you want a graphical desktop environment, choose failsafe mode and then delete "nomodeset x11 failsafe" from the boot arguments. This would need to be adjusted for newer qemu, command line options I used recently with pcbsd were: $ qemu-system-x86_64 -m 256 -cdrom PCBSD10.0.2-RELEASE-06-20-2014-x64-DVD-USB.iso pcbsd-qemu.img launch: $ qemu-system-x86_64 -m 1200 -display gtk -vga std -sdl -hda pcbsd-qemu.img Brett. PS whatever you run it will be slow.
Re: pf: reassemble tcp
On 13/09/14 11:55, Henning Brauer wrote: * Kapetanakis Giannis [2014-09-06 00:50]: I'm asking about "reassemble tcp". According to some 2010's threads in misc@ it used to cause problems to some users. I'm wondering what's the status now. unchanged. Thanks for the reply G
Re: How to disable keyboard+mouse input in FVWM?
On 12 September 2014 19:22, wrote: > Still didn't found a way to disable the mouse and keyboard. > > Any hints please? I asked you before what you meant by this, and suggested: Style * NeverFocus Is that not what you're after? It's a pretty odd request. Are you trying to build some kind of kiosk? I've written about such things in the past. -- Thomas Adam
Re: How to disable the mouse cursor in FVWM?
On 12 September 2014 19:18, wrote: > Hello, > > we are using OpenBSD 5.5 with FVWM. > > How can we disable the mouse cursor? > > So we shouldn't see the mouse cursor if we push the mouse a little. > > Is the solution somewhere here? : Not via FVWM directly. You might be able to use unclutter to always hide the pointer though. -- Thomas Adam
Re: pf: reassemble tcp
* Kapetanakis Giannis [2014-09-06 00:50]: > I'm asking about "reassemble tcp". > > According to some 2010's threads in misc@ it used to cause problems to some > users. > I'm wondering what's the status now. unchanged. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: pf: reassemble tcp
* Sonic [2014-09-05 17:12]: > On Fri, Sep 5, 2014 at 4:42 AM, Kapetanakis Giannis > wrote: > > yeah, don't use reassemble tcp. it's not perfect. > Isn't that default behavior? hell, no. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: TCP checksum problems with NAT (maybe vlans/tun)
* Matt Hamilton [2014-09-06 14:11]: > Based on the info above it would seem that the routing table thinks > the packet should be routed to bnx0 based on the IP address. bnx0 > supports HW tcp checksums, so the OS does not create the checksum > itself. > > But the packet never goes out bnx0, it is picked up by the bridge and > sent down tun0 instead. tun interfaces do no recompute the tcp > checksum and so by the time the packet gets to my laptop the checksum > has never been correctly calculated and my laptop ignores the packet. > > So what do we need to do to fix this? Is getting the tun interface to > calculate the checksums the way to go? seems like you manage to hit a case where the %*&#^(*@!^(_! bridge confuzzles interfaces. AGAIN. did I mention the bridge has to die? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: PF Tagging
* andy [2014-09-02 21:12]: > Hoping this is a pretty dumb question and someone can just shoot me down > with an instant answer but is there any reason why I can't compare against > multiple tags? because list expansion for that case is not implemented in the parser. not hard to do at all... -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: low power device
On 12 September 2014, Zé Loff wrote: > On Fri, Sep 12, 2014 at 05:31:01PM +0200, Martijn van Duren wrote: > > On Fri, 2014-09-12 at 16:22 +0100, Zé Loff wrote: > > > On Fri, Sep 12, 2014 at 04:28:46PM +0200, Lars wrote: > > > > On 12.09.2014 15:27, Martijn van Duren wrote: > > > > >Hello misc@, > > > > > > > > Hi, > > > > > > > > >Currently I have an old desktop PC running > > > > >as a home server/media center, which runs > > > > >OpenBSD. Most of the time it's idling, but does run > > > > >(open)ssh/(open)smtp/imap(dovecot)/http(nginx/apache > > > > >+subversion)/minidnla, which I want to keep available. > > > > > > > > > >Is there any board/device known which can support these > > > > >requirements and is fully (within the requirements) supported > > > > >by OpenBSD? > > > > > > > > > > > > > As a personal preference I would avoid using ARM boards and > > > > would try to go with x86/amd64 boards instead. I don't know > > > > how well those ARM devices are supported on OpenBSD (I have > > > > only a little experince with running Linux on those), but the > > > > performance was pretty disappointing(with Linux). *I* would > > > > decide for the APU from pcengines. http://pcengines.ch/apu.htm > > > > > > My first thought too, but it has no video, which is probably > > > required by the OP. > > > > Video is not an requirement, since I primarily use it for streaming > > via DLNA, so network and storage are sufficient. > > Oh, in that case, I agree with Lars. I have a APU (the 2Gb) model > running a bunch of light services for my small lan (pf, dhcpd, > unbound, nsd, ntpd, wifi AP), and apart from heating a lot (passive > cooling through the enclosure) it runs fine. [...] +1 for APU.1C, it's a nice machine, much faster than ARM boards. I'd also buy a small mSATA disk for system (pretty much any model would do, except the Chinese thing sold by PC Engines), and an external 3.5" USB disk with an external power brick for DLNA. Don't try to mount a 2.5" SATA disk inside the case; it would overheat, and it would need more power than the power brick that comes with APU.1C can provide. For similar reasons, you should probably avoid external disks powered over USB (that is, most 2.5" external disks these days). Also make sure to upgrade to the latest firmware if you want to run OpenBSD. Regards, Liviu Daia
Re: pfsync and trunk
* Tony Sarendal [2014-09-03 06:48]: > The initial request disappearing and the firewalls staying demoted > "forever" are independent issues. sure about that? the demotion counter for the interface group pfsyncX is part of (usually carp) is kept raised until the bulk transfer finishes. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: OpenBGPD not installing routes that happen to originate from the same ASN in another location into the RIB
* Gregory Edigarov [2014-09-12 20:28]: > On 09/12/14 19:07, Henning Brauer wrote: > >* Paul S. [2014-08-28 11:19]: > >>Earlier today, however, I discovered that routes that I'm announcing under > >>the same ASN (in another location) are being received and put into the RIB > >>-- but never into the kernel's FIB. > >that's correct behaviour, routes from the same AS aren't supposed to be > >distributed via BGP but your IGP. > IGP is correct solution in most cases, but it doesn't cover the situation > when you need to accept a route originated from your remote location or a > customer connected to your remote location. > and your remote location is a few AS hops away from you. That's not how BGP works. > that's where 'allow-as in' come into play. > although i would agree that it is a hack. indeed. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
