Re: Relationship Between VLANs and Physical Interfaces in PF
* Giancarlo Razzolini grazzol...@gmail.com [2014-08-05 00:02]: On 04-08-2014 18:09, Eric Dilmore wrote: I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The gateway has one external interface and one internal, with the internal network split into several VLANs: one for secure traffic, one for guests, one for internal phones, and one for our external Asterisk phone server. Vlans work, but they add complexity. I'd prefer physical interfaces separating the networks, both for performance and security reasons. the 90s are over. However, I believe that pf queues are tied to an outbound interface. None of the rules I have attempted on the internal interface have matched at all. I can specify each vlan explicitly, but the internal interface itself doesn't seem to match any packets. tcpdump shows traffic passing both in and out when I specify the internal interface. The most indicated way is to queue your downloads on the internal interface and your uploads on the external interface. If I'm not mistaken, you need to set the queues on each vlan if. you are mistaken, queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). sth like match out on vlanX queue foo really just tags the packet should go to queue foo. once the packet hits an outbound interface, we check wether queue foo exists there and if so use it. -- 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: IPSEC with redundant remote peer address
Am Montag, den 04.08.2014, 20:36 + schrieb Peter van Oord van der Vlies: Does anyone know a way to built a setup when remote IPSEC endpoint got a failover setup on the IPSEC side ? On cisco IOS it's possible to configure multiple peers, when a peer dies it will try the other on the list. Anyone tried to fix this when the remote end is a cisco IOS device and other side is openbsd box ? If you want the OpenBSD side to be redundant, use CARP and sasyncd. On the OpenBSD side you may use CARP and sasyncd. The OpenBSD boxes will look like only one machine to the Cisco, and there is no need even to enable this fallback feature on the Cisco. If you want the Ciscos to be redundant, you have multiple options. I do not know enough of Cisco to be able to tell you whether or not one may cluster their routers/VPN gateways. But you have multiple options to emulate the fallback behaviour that you described above. 1) Just configure two tunnels, to both Cisco gateways. Give one route(8) -priority, or use a dynamic routing protocol. 2) You may use ifstated or similar to monitor the gateways and tunnels and switch over, when indicated. 3) What you probably can do on the Cisco, which kind of emulates a CARP w/o sasyncd setup is, to configure the VPN on a VRRP interface. The disadvantage of the last setup is, that you will need both peers to notice that the tunnel is broken and to re-establish it. So please be sure to enable DPD (IKE1)/liveness checks (IKE2)/keepalives (Cisco). Cheers David -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Relationship Between VLANs and Physical Interfaces in PF
On 2014 Aug 04 (Mon) at 19:01:06 -0300 (-0300), Giancarlo Razzolini wrote: :On 04-08-2014 18:09, Eric Dilmore wrote: : I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The : gateway has one external interface and one internal, with the internal : network split into several VLANs: one for secure traffic, one for : guests, one for internal phones, and one for our external Asterisk phone : server. :Vlans work, but they add complexity. I'd prefer physical interfaces :separating the networks, both for [...] and security reasons. Both of those are blatent lies. -- We should declare war on North Vietnam. We could pave the whole country and put parking strips on it, and still be home by Christmas. -- Ronald Reagan
Re: Relationship Between VLANs and Physical Interfaces in PF
Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer: queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). Strangely, the following (simplified) setup seems to work here on 5.5 nevertheless: queue vlan33q on vlan33 bandwidth 2M, max 2M match out on vlan33 all set queue vlan33q In pfctl -sq this looks exactly like I expected and it does exactly what I intended it to do. But as you (if anybody) indeed should known, what happens. Please tell me, what the above config actually does. Will the first line silently add a vlan33q to re0 that still does what it is intended? OTOH, adding a queue to a GRE interface does not work indeed. Regards David -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: kile-kde4
Am 08/05/14 um 01:44 schrieb Vadim Zhukov:
You can try to run the two following commands:
$ kwriteconfig4 --file ~/.kde/share/config/kilerc --group DirWatch
--key PreferredMethod Fam
$ rm ~/{.lyx/,}.lyxpipe*
Hi Vadim,
thank you very, very much for your efforts!
Last night I reinstalled the system with the latest amd64-current.
~ $ uname -a
OpenBSD idefix.fritz.box 5.6 GENERIC.MP#317 amd64
(Full dmesg at the end)
This time I reinstalled all packages in a different order - I started
with kile and was puzzled by the sheer number of dependencies. Samba?
VLC? Only to get kile up and running? Strange...
Long story short - kile is still disfunct. As before the program starts
but once I try e.g. to start a new document like 'scrreprt' cpu-usage
goes up (as shown by gkrellm) but that's all - the kile-windows won't
redraw.
OK - now your suggested commands (using .kde4/):
~ $ kwriteconfig4 --file ~/.kde4/share/config/kilerc --group DirWatch
--key PreferredMethod Fam
kwriteconfig4:/usr/lib/libstdc++.so.57.0:
/usr/local/lib/libestdc++.so.16.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your
program
sw@idefix
~ $ rm ~/{.lyx/,}.lyxpipe*
rm: /home/sw/.lyx/.lyxpipe*: No such file or directory
Restarting kile...
*** S * U * C * C * E * S * S ***
I can start a new document now and even a bigger document not only opens
but is compiled in no time and the PDF shown with okular! Just as I
would have expected it to work. PERFECT!
To get the test right I opened LyX for the first time after reinstall,
opened a document and let pdflatex show the PDF. With LyX still running
I reopend kile to see if it is working. It does! Good.
BTW: I noticed that in the settings kile is delivered with the ability
to run LyX-commands related to bibtex.
Vadim - you made my day! THANK YOU VERY MUCH - I owe you a beer. Will
send an extra donation to the project!
Cheers,
STEFAN
OpenBSD 5.6 (GENERIC.MP) #317: Mon Aug 4 01:38:31 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3203203072 (3054MB)
avail mem = 3109216256 (2965MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version 79ETC9WW (2.09 ) date 12/22/2006
bios0: LENOVO 2007VG2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4)
EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3)
HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.71 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.34 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 92P1139 serial 2887 type LION oem
Panasonic
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 1994 MHz: speeds: 2000, 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03
ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64
rev 0x00
drm0 at radeondrm0
radeondrm0: apic 1 int 16
azalia0 at pci0 dev 27 function 0 Intel
Re: Relationship Between VLANs and Physical Interfaces in PF
* David Dahlberg david.dahlb...@fkie.fraunhofer.de [2014-08-05 10:17]: Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer: queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). Strangely, the following (simplified) setup seems to work here on 5.5 nevertheless: queue vlan33q on vlan33 bandwidth 2M, max 2M match out on vlan33 all set queue vlan33q In pfctl -sq this looks exactly like I expected and it does exactly what I intended it to do. except that the underlaying physical if's queue destroys the effects - not necessarily always, but most of the time. by just chaning your queue def to queue vlan33q on vlan33's vlandev bandwidth 2M, max 2M (no, NOT literal .., you expand that yourself) does what you intended in the first place. But as you (if anybody) indeed should known, what happens. Please tell me, what the above config actually does. Will the first line silently add a vlan33q to re0 that still does what it is intended? no, it does queueing on vlan33. but since we end up queueing the packets on vlan33's vlandev again, the effects often just aren't there. queueing is a lot about timing... at some point we used vlans with a queue depth of 1, since there really is no point in queueing there at all, but that exposed some otehr bugs. we might eventually go back to that. -- 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/
VPLS and PWE3 status in Openbsd
Hi, What is the status of VPLS/PWE3 support on Openbsd right now ? I have been researching a bit but cannot find a definitive answer. There is several mentions of work on this on the web and in the mailing lists but nothing really clear. Back in 2011 Claudio Jeker about Openbsd 4.9/5.0 state that these features are expected in near future. http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf There is a couple of guys speaking about work on this on the mailing list in 2012 and 2013 http://comments.gmane.org/gmane.os.openbsd.tech/29882 http://openbsd.7691.n7.nabble.com/RFC-Patches-for-the-LDP-daemon-td228828.html But I didn't find mentions of this in the ldpd manpage (or am I missing something ?) Thank you
Re: VPLS and PWE3 status in Openbsd
On Tue, Aug 05, 2014 at 12:53:43PM +0200, Alucard wrote: Hi, What is the status of VPLS/PWE3 support on Openbsd right now ? I have been researching a bit but cannot find a definitive answer. There is several mentions of work on this on the web and in the mailing lists but nothing really clear. Back in 2011 Claudio Jeker about Openbsd 4.9/5.0 state that these features are expected in near future. http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf There is a couple of guys speaking about work on this on the mailing list in 2012 and 2013 http://comments.gmane.org/gmane.os.openbsd.tech/29882 http://openbsd.7691.n7.nabble.com/RFC-Patches-for-the-LDP-daemon-td228828.html But I didn't find mentions of this in the ldpd manpage (or am I missing something ?) Thank you Hi Alucard, I stopped coding VPLS/PWE3 support at the end of 2012 because it was getting messy and I didn't have time to properly write it (also I wasn't experienced enough). So after I finished my final paper which was the main reason why I was coding it I simply left it as it was. The wire(4) driver is missing MAC learning and to make it work for my presentation I had to manually add them. The VPLS implementation in LDPd was just too messy and it took me a lot of time to understand LDPd code. Now that I understand most of the ldpd code I'm ashamed of what I did at that time. So: (1) to finish wire(4) there is still a small integration with bridge(4) MAC learning code left to be done and (2) about the VPLS code in LDPd you might have a better luck talking with renato@.
Re: kile-kde4
Am 08/05/14 um 10:54 schrieb Stefan Wollny: Will send an extra donation to the project! EUR 50,- donated!
Re: openbsd and badusb
Hello ! I'm not sure that this exploit affect only Windows system. Autorun != USB stick firmware. Autorun is a part of the Windows system wich configure the device when it's mounted. (See : https://en.wikipedia.org/wiki/AutoRun for more information about) The USB stick firmware is like the BIOS... Without it your stick can't run. All hardwares provide an embedded firmware. The 'BadUSB' exploit this firmware and there's multiple possibility to do malicious things. 0. The final claim is that once infected, you'll always be infected because disinfection is nigh impossible. I'm very sceptic if you can infect that firmware it's possible to disinfect it. But yes it must be very difficult to detect that. Meh. The same could be said of the firefox exploit of the week. It too can reprogram your bios or persist itself in any number of ways. Yes of course, but that technique is a new vector of infection very powerfull. With that you're able enter in closed network. (If the exchange USB stick of course). 1. They're exploiting all manner of Windows specific autorun functionality to install or configure drivers. By default, OpenBSD will do just about nothing when a USB device is plugged in, so this is not a serious concern. It's not an AutoRun exploit :) 2. They have created a rogue keyboard device which will type naughty commands. In theory, the same keyboard could type rm -rf ~ into an xterm. Here's the interesting part. I think with that technique you can spoof a keyboard. Even in OpenBSD, when you plug a keyboard or a mouse OBSD detect it and you can use it directly. The infected USB can tell to the system : I'm not an USB stick but a keyboard. With that fact I'm sure there are a lot of malicious possibilities. Cheers ! Fabien Franchini
Re: softraid not bootable in 5.4 after visiting 5.5
On Thu, Jul 31, 2014 at 06:12:49PM +0200, Raimo Niskanen wrote: Hello misc@ I once created an USB stick (uSDHC card with reader, actually) using OpenBSD 5.4 (might have been an earlier that I later binary upgraded) that contains a softraid encrypted and bootable OpenBSD installation. It has worked just fine. Just now I created a new stick with OpenBSD 5.5 in the same way, since binary upgrading seemed awkward due to the time_t change, and while doing so I attached the old stick to copy configuration files. When attaching it softraid0 said something about roaming disk that was sdX but now sdY - updating metadata, which is not unusual. At least I think that is what triggered the problem... After this the old USB stick does not boot. The list of disks that show up in the boot prompt are: hd0, hd1, and sr0, but sr0 is no longer marked with a '*' which I beleive indicates bootability, so boot(8) tries to boot hd1 and fails. If I tell boot(8) via set device sd0a to boot from sd0 it does so and that works fine. So autmatic booting now does not work on the old stick? Is this a bug or expected? Can I fix the old stick? (just curious, it is not that important) Some more details: both sticks have an MBR with just the last slot type A6 (dedicated for OpenBSD), and their disklabels have a partition 'a' of type RAID and a swap partition 'b'. The whole installation is then within the softraid disk. The old stick was created on i386 and the new on amd64. I hope that was enough information for someone to get an idea. I myself suspect there is some kind of metadata change that got written when roaming to OpenBSD 5.5 that the old boot(8) loader gets confused by. Nevertheless it is surprising that roaming a softraid disk can change it to the worse... For the record. I have been informed that it is very likely that some kind of metadata change was written to the disk which confuses the old boot loader. Furthermore this is an odd not prioritized use case. What is supposed to work is to move a softraid disk to a new release and run it there. My guess is that if there has been a metadata format change in softraid it is a good strategy to rewrite that metadata when the disk gets imported so the new softraid code then will not have to account for multible metadata formats during normal operation. Best Regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: login.conf default openfiles
On Mon, 4 Aug 2014, Philip Guenther wrote: On Sat, Aug 2, 2014 at 7:06 AM, Ed Hynan eh_l...@optonline.net wrote: Saturday morning, saw this in /var/log/messages: Aug 2 08:29:12 lucy su: default: setting resource limit openfiles: Invalid argument (BTW, I quoted a line I produced by hand: the time is wrong, should have been approx. 03:30. The rest is the same.) That indicates that the requested -cur value was greater than the requested -max value, if any, or the current -max value if no change to the max was requested. Yes... -cur in the default class is 512, and ... # echo ulimit -n | su -m nobody 256 # echo ulimit -nH | su -m nobody 384 I'm running the commands in a root shell. I set openfiles-cur=256 and openfiles-max=384 for the daemon class, which is root's class according to userinfo root. [*] So, after putting the original login.conf in place, and su - root again on another pty, ulimit -nH is 768 (although the value 768 does not appear in the original login.conf). Soft limit is 128. OK, it seems I've triggered the log message by reducing openfiles-max in the daemon class, which is root's, but the interesting thing is that the su command succeeds. That's from /etc/weekly, which uses 'su -m nobody' for locate db update on line 52. The log message can be produced by hand with, e.g.: # echo /bin/echo FOO | SHELL=/bin/sh nice -5 su -m nobody invoked by root. Hmm, I'm unable to reproduce that on my 5.6 system. Compare the output of ulimit -nH and the openfiles-cur value in the login.conf. On my system, the normal hard (i.e., -max) limit is 1024; is that not the case on yours? If so, where is the smaller value coming from? The root .profile? Some other system config file? Inherited from a lower limit on your personal account when you su'ed to root? See above. [*] why such limits, you may ask. Simply old and limited hardware, in the role of home lan gateway router. I wanted to try tighter limits, and use so far suggests they are not a problem for the daemons in use. Last uptime before switch to 5.5: 408 days, but would have been about 3 years if not for power failures outlasting the UPS. So, I feel confident in those limits. Actually, those limits were in place before 4.9, but I forget when. They seem OK. BTW, I jumped from 4.9 to 5.5 so the 4.9 login.conf is the most recent I have handy. The 4.9 login.conf likewise has only openfiles-cur in default:, but I don't think I've seen that log message before. Some verbosity recently added? The setrlimit() syscall was changed to comply with POSIX and return an error instead of (iirc) silently clamping the soft limit to the hard limit. OK, I see the message is logged in lib/libc/gen/login_cap.c::gsetrl() after setrlimit() fails (gsetrl() then returns -1). Thanks for pointing that out; message is clear now. setusercontext(3) does not fail at the gsetrl() failure; it proceeds anyway. That explains why the log message is the only symptom and the /etc/weekly job succeeds. So, the absence openfiles-max in the original login.conf is intentional? Before that log message, I was never prompted to think this through this far. -Ed
5.4 (GENERIC) box has begun to randomly reboot
Hi, A reliable box has begun to randomly reboot in the last couple of days. There's nothing obviously unusual in /var/log/* $ ls -ld /var/crash drwxrwx--- 2 root wheel 512 Dec 24 2013 /var/crash/ $ ls -lA /var/crash total 4 -rw-r--r-- 1 root wheel 5 Jul 30 2013 minfree I set up a 1 min cron job of sysctl | fgrep hw.sensors.lm1.temp uptime The last one before a reboot was: hw.sensors.lm1.temp0=34.00 degC hw.sensors.lm1.temp2=33.50 degC 2:53PM up 31 mins, 2 users, load averages: 0.13, 0.19, 0.23 I'm guessing some bit of hardware is on it's way out, but which? $ ls -l /var/run/dmesg.boot -rw-r--r-- 1 root wheel 3612 Aug 5 14:58 /var/run/dmesg.boot OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class, 128KB L2 cache) 635 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF real mem = 535228416 (510MB) avail mem = 515035136 (491MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 01/15/99, BIOS32 rev. 0 @ 0xfdb70, SMBIOS rev. 2.0 @ 0xf0480 (24 entries) bios0: vendor American Megatrends Inc. version 063101 date 01/15/99 bios0: Supermicro Computer Intel 810 apm0 at bios0: Power Management spec V1.2 acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI BIOS has 9 Interrupt Routing table entries pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801AA LPC rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82810E Host rev 0x03 vga1 at pci0 dev 1 function 0 Intel 82810E Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xec00, size 0x400 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 30 function 0 Intel 82801AA Hub-to-PCI rev 0x02 pci1 at ppb0 bus 1 rl0 at pci1 dev 0 function 0 Realtek 8139 rev 0x10: irq 11, address 00:90:47:05:99:6d rlphy0 at rl0 phy 0: RTL internal PHY rl1 at pci1 dev 1 function 0 Realtek 8139 rev 0x10: irq 10, address 00:90:47:05:30:e8 rlphy1 at rl1 phy 0: RTL internal PHY ichpcib0 at pci0 dev 31 function 0 Intel 82801AA LPC rev 0x02: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 82801AA IDE rev 0x02: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: ST3250820A wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 wd1 at pciide0 channel 1 drive 0: Maxtor 5A320J0 wd1: 16-sector PIO, LBA48, 308921MB, 632672208 sectors wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 31 function 2 Intel 82801AA USB rev 0x02: irq 5 ichiic0 at pci0 dev 31 function 3 Intel 82801AA SMBus rev 0x02: irq 10 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 256MB SDRAM non-parity PC133CL2 spdmem1 at iic0 addr 0x51: 256MB SDRAM non-parity PC133CL2 auich0 at pci0 dev 31 function 5 Intel 82801AA AC97 rev 0x02: irq 10, ICH AC97 ac97: codec id 0x43525934 (Cirrus Logic CS4299 rev 4) ac97: codec features headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D audio0 at auich0 isa0 at ichpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x13 lm1 at wbsio0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 mtrr: Pentium Pro MTRR support vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (0e3aa2ac975978d6.a) swap on wd0b dump on wd0b WARNING: / was not properly unmounted
OpenBSD product distribution will move
At the end of September, OpenBSD distribution will move to a new distributor. As a result the old stock (CDs, Tshirts and posters) will become unavailable. Order them now, because they are going extinct! Last chance for some of those shirts..
Re: login.conf default openfiles
On Tue, Aug 5, 2014 at 6:49 AM, Ed Hynan eh_l...@optonline.net wrote: On Mon, 4 Aug 2014, Philip Guenther wrote: On Sat, Aug 2, 2014 at 7:06 AM, Ed Hynan eh_l...@optonline.net wrote: ... That indicates that the requested -cur value was greater than the requested -max value, if any, or the current -max value if no change to the max was requested. Yes... -cur in the default class is 512, and ... # echo ulimit -n | su -m nobody 256 # echo ulimit -nH | su -m nobody 384 I'm running the commands in a root shell. I set openfiles-cur=256 and openfiles-max=384 for the daemon class, which is root's class according to userinfo root. [*] So, after putting the original login.conf in place, and su - root again on another pty, ulimit -nH is 768 (although the value 768 does not appear in the original login.conf). Soft limit is 128. OK, it seems I've triggered the log message by reducing openfiles-max in the daemon class, which is root's, but the interesting thing is that the su command succeeds. Failure to set the resource limits isn't considered fatal for setusercontext(). It would be Bad if a typo there could leave you unable to login or su to root... ... So, the absence openfiles-max in the original login.conf is intentional? Before that log message, I was never prompted to think this through this far. It wasn't necessary to set them, so why over-specify them? IIRC, we had actually increased the defaults not too long ago to handle the increased demands of stuff like gnome and firefox. If we wrote out all the limits, then upgrades would be more painful as more lines would have to change. Philip Guenther
Re: softraid not bootable in 5.4 after visiting 5.5
On Tue, 5 Aug 2014, Raimo Niskanen wrote: On Thu, Jul 31, 2014 at 06:12:49PM +0200, Raimo Niskanen wrote: Hello misc@ I once created an USB stick (uSDHC card with reader, actually) using OpenBSD 5.4 (might have been an earlier that I later binary upgraded) that contains a softraid encrypted and bootable OpenBSD installation. It has worked just fine. Just now I created a new stick with OpenBSD 5.5 in the same way, since binary upgrading seemed awkward due to the time_t change, and while doing so I attached the old stick to copy configuration files. When attaching it softraid0 said something about roaming disk that was sdX but now sdY - updating metadata, which is not unusual. At least I think that is what triggered the problem... After this the old USB stick does not boot. The list of disks that show up in the boot prompt are: hd0, hd1, and sr0, but sr0 is no longer marked with a '*' which I beleive indicates bootability, so boot(8) tries to boot hd1 and fails. If I tell boot(8) via set device sd0a to boot from sd0 it does so and that works fine. So autmatic booting now does not work on the old stick? Is this a bug or expected? Can I fix the old stick? (just curious, it is not that important) Some more details: both sticks have an MBR with just the last slot type A6 (dedicated for OpenBSD), and their disklabels have a partition 'a' of type RAID and a swap partition 'b'. The whole installation is then within the softraid disk. The old stick was created on i386 and the new on amd64. I hope that was enough information for someone to get an idea. I myself suspect there is some kind of metadata change that got written when roaming to OpenBSD 5.5 that the old boot(8) loader gets confused by. Nevertheless it is surprising that roaming a softraid disk can change it to the worse... For the record. I have been informed that it is very likely that some kind of metadata change was written to the disk which confuses the old boot loader. I highly doubt this, especially given that there have been no real metadata related changes for multiple releases. The fact that sr0 still shows up means that the metadata is correctly identified. The lack of the '*' after sr0 means that the BIOC_SCBOOTABLE flag has been cleared - rerunning installboot on the softraid device will re-enable the flag (and update the boot loader). Furthermore this is an odd not prioritized use case. What is supposed to work is to move a softraid disk to a new release and run it there. My guess is that you ran 'bioctl -d' to delete the volume - this will have cleared the BIOC_SCBOOTABLE flag and set the flags to BIOC_SCNOAUTOASSEMBLE. One can argue that this is a bug, however one of the long standing gripes with softraid is that there is no distinction between create vs attach and delete vs detach. Fixing this is somewhere on my TODO list... My guess is that if there has been a metadata format change in softraid it is a good strategy to rewrite that metadata when the disk gets imported so the new softraid code then will not have to account for multible metadata formats during normal operation. Migrations between versions are handled - if necessary, the metadata will get updated when you attach the softraid volume. -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: SLiM port: weird mode for pkg-readmes/slim-1.3.6
On Mon 04/08 13:27, Stuart Henderson wrote: On 2014-08-03, Alessandro DE LAURENZIS just22@gmail.com wrote: Hello misc@, Just tried to compile SLiM (in order to remove the ConsoleKit depend), but ended-up with the following error: just22@poseidon:[slim] sudo make package `/usr/obj/ports/slim-1.3.6/fake-amd64/.fake_done' is up to date. === Building package for slim-1.3.6p2 Create /usr/ports/packages/amd64/all/slim-1.3.6p2.tgz Error: weird mode for /usr/local/share/doc/pkg-readmes/slim-1.3.6p2: 640 Error: modes don't match for /usr/local/share/doc/pkg-readmes/slim-1.3.6p2 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1878 '/usr/ports/packages/amd64/all/slim-1.3.6p2.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2426 '_internal-package') *** Error 1 in /usr/ports/mystuff/x11/slim (/usr/ports/infrastructure/mk/bsd.port.mk:2406 'package') Maybe related to [1]? Any hints? [1]: http://openbsd.7691.n7.nabble.com/ports-to-fix-td241546.html Hello Stuart, Thanks for your feedback. For now, chmod 644 /usr/ports/mystuff/x11/slim/pkg/README - I will send espie a diff to fix this in bsd.port.mk. I confirm that changing file's permissions to 644 is a valid workaround. BTW normal method is not to use sudo make [..] but to set SUDO=sudo in /etc/mk.conf, which runs fewer parts of the build as root (and naddy has been looking at some possibilities to further reduce this in the future). I know; that has been run on a new install, without port tree trimming... I read on undeadly about C. Weisgerber's work and hope to see some improvements soon. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
On utmp X session registration with XDM
Dear misc@ readres, I'm struggling with the output of who/w/last commands, at the moment partially inconsistent IMHO. I noticed that utmp session logging is explicitly disabled in XDM: just22@poseidon:[~] tail -n1 /etc/X11/xdm/GiveConsole /usr/X11R6/bin/sessreg -a -l $DISPLAY -u none -x /usr/X11R6/lib/X11/xdm/Xservers $USER (-u none prevents writing records in utmp; on the other hand, even the -x argument should be changed to /etc/X11/xdm/Xservers). Anyone could argument about this choice? Which is the right way to use the who/w/last commands in OBSD? I found an old related message on tech@ [1], but with no follow-up, so I feel alone... Nonetheless, I consider the logged user listing utilities output consistency a very valuable matter, particularly for remote machine administration. Thanks in advance for your time. [1] http://openbsd.7691.n7.nabble.com/XDM-utmp-td172012.html -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: Relationship Between VLANs and Physical Interfaces in PF
On 05/08/14 10:23, Henning Brauer wrote: * David Dahlberg david.dahlb...@fkie.fraunhofer.de [2014-08-05 10:17]: Am Dienstag, den 05.08.2014, 08:36 +0200 schrieb Henning Brauer: queueing on vlan is pretty meaningless. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). Strangely, the following (simplified) setup seems to work here on 5.5 nevertheless: queue vlan33q on vlan33 bandwidth 2M, max 2M match out on vlan33 all set queue vlan33q In pfctl -sq this looks exactly like I expected and it does exactly what I intended it to do. except that the underlaying physical if's queue destroys the effects - not necessarily always, but most of the time. by just chaning your queue def to queue vlan33q on vlan33's vlandev bandwidth 2M, max 2M (no, NOT literal .., you expand that yourself) does what you intended in the first place. Correct me if I'm wrong here Henning, but we have always used the approach of only ever assigning queues to the physical interface (whether it has VLANs or not), as this means that both the physical interfaces untagged network, plus all the tagged networks on that interface get to share the queues. Having lots of physical internal interfaces with queues on each simply means you have to divide our total WAN download bandwidth across the interfaces as they cannot borrow from each other. But if you use VLANS and place the queues on the physical interface, if the public WIFI VLAN for example is not using any bandwidth, the internal LAN can use all the bandwidth until the public WIFI wants some. Considering all this, there should never be a good reason to apply queues to the VLAN interfaces at all? But as you (if anybody) indeed should known, what happens. Please tell me, what the above config actually does. Will the first line silently add a vlan33q to re0 that still does what it is intended? no, it does queueing on vlan33. but since we end up queueing the packets on vlan33's vlandev again, the effects often just aren't there. queueing is a lot about timing... at some point we used vlans with a queue depth of 1, since there really is no point in queueing there at all, but that exposed some otehr bugs. we might eventually go back to that.
patch for iked.conf and hostapd.conf
Hello,
I tried to parse (with pfctl -nvf) the rule
match on enc0 from 192.168.1.0/24 to 192.168.2.0/24 nat-to 10.10.10.1
and all I got was:
pf.tmp:1: nat-to and rdr-to require a direction
pf.tmp:1: skipping rule due to errors
pf.tmp:1: rule expands to no valid combination
So I guess what's missing is out:
Index: src/sbin/iked/iked.conf.5
===
RCS file: /cvs/src/sbin/iked/iked.conf.5,v
retrieving revision 1.32
diff -u -p -r1.32 iked.conf.5
--- src/sbin/iked/iked.conf.5 6 May 2014 13:09:18 -
1.32 +++ src/sbin/iked/iked.conf.5 4 Aug 2014 12:40:05 -
@@ -718,7 +718,7 @@ a relevant NAT rule is required in
For the example above,
this would be:
.Bd -literal -offset indent
-match on enc0 from 192.168.1.0/24 to 192.168.2.0/24 nat-to 10.10.10.1
+match out on enc0 from 192.168.1.0/24 to 192.168.2.0/24 nat-to
10.10.10.1 .Ed
.Pp
From the peer's point of view,
--
I tried to parse (hostapd -dv -f) the example in hostapd.conf and I got:
hostapd.tmp:4: syntax error
invalid configuration in hostapd.tmp
bye!
So the patch is:
Index: hostapd.conf.5
===
RCS file: /cvs/src/usr.sbin/hostapd/hostapd.conf.5,v
retrieving revision 1.42
diff -u -p -r1.42 hostapd.conf.5
--- hostapd.conf.5 3 Sep 2013 20:44:01 - 1.42
+++ hostapd.conf.5 5 Aug 2014 10:51:56 -
@@ -798,8 +798,8 @@ For example:
.Bd -literal -offset indent
# Assign IP addresses to layer 2 addresses
table clients {
- 00:02:6f:42:d0:01 - 172.23.5.1/30
- 00:05:4e:45:d3:b8 - 172.23.5.4/30
+ 00:02:6f:42:d0:01 - 172.23.5.1/30,
+ 00:05:4e:45:d3:b8 - 172.23.5.4/30,
00:04:2e:12:03:e0 - 172.23.5.8/30
}
Cheers,
--
Vigdis
Re: patch for iked.conf and hostapd.conf
On Tue, Aug 05, 2014 at 06:19:59PM +0200, Vigdis wrote:
Hello,
I tried to parse (with pfctl -nvf) the rule
match on enc0 from 192.168.1.0/24 to 192.168.2.0/24 nat-to 10.10.10.1
and all I got was:
pf.tmp:1: nat-to and rdr-to require a direction
pf.tmp:1: skipping rule due to errors
pf.tmp:1: rule expands to no valid combination
So I guess what's missing is out:
Thanks, your diff is right.
Index: src/sbin/iked/iked.conf.5
===
RCS file: /cvs/src/sbin/iked/iked.conf.5,v
retrieving revision 1.32
diff -u -p -r1.32 iked.conf.5
--- src/sbin/iked/iked.conf.5 6 May 2014 13:09:18 -
1.32 +++ src/sbin/iked/iked.conf.54 Aug 2014 12:40:05 -
@@ -718,7 +718,7 @@ a relevant NAT rule is required in
For the example above,
this would be:
.Bd -literal -offset indent
-match on enc0 from 192.168.1.0/24 to 192.168.2.0/24 nat-to 10.10.10.1
+match out on enc0 from 192.168.1.0/24 to 192.168.2.0/24 nat-to
10.10.10.1 .Ed
.Pp
From the peer's point of view,
--
I tried to parse (hostapd -dv -f) the example in hostapd.conf and I got:
hostapd.tmp:4: syntax error
invalid configuration in hostapd.tmp
bye!
So the patch is:
Index: hostapd.conf.5
===
RCS file: /cvs/src/usr.sbin/hostapd/hostapd.conf.5,v
retrieving revision 1.42
diff -u -p -r1.42 hostapd.conf.5
--- hostapd.conf.53 Sep 2013 20:44:01 - 1.42
+++ hostapd.conf.55 Aug 2014 10:51:56 -
@@ -798,8 +798,8 @@ For example:
.Bd -literal -offset indent
# Assign IP addresses to layer 2 addresses
table clients {
- 00:02:6f:42:d0:01 - 172.23.5.1/30
- 00:05:4e:45:d3:b8 - 172.23.5.4/30
+ 00:02:6f:42:d0:01 - 172.23.5.1/30,
+ 00:05:4e:45:d3:b8 - 172.23.5.4/30,
00:04:2e:12:03:e0 - 172.23.5.8/30
}
Cheers,
--
Vigdis
--
Re: Relationship Between VLANs and Physical Interfaces in PF
On 05-08-2014 03:36, Henning Brauer wrote: the 90s are over. Yep, I know Henning. Vlan's are pretty secure. But they add complexity and if you use physical separation you can mitigate problems caused by misconfiguration. Either on OpenBSD itself or on the switches. As I said, my personal preference is to physically separate the networks. But I've used vlans and I will use again, surely. I just don't like to use them, specifically, when I don't have control of the entire network. you are mistaken, queueing on vlan is pretty meaningless. Never did tried to queue on vlans, so I was clearly mistaken. however, classification can happen anywhere, so assign queues on your vlan interface and create them on the physical one, things will Just Work (tm). sth like match out on vlanX queue foo really just tags the packet should go to queue foo. once the packet hits an outbound interface, we check wether queue foo exists there and if so use it. This is one of the greatest features of pf, in my opinion. This flexibility is what make pf what it is. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: login.conf default openfiles
On Tue, 5 Aug 2014, Philip Guenther wrote: On Tue, Aug 5, 2014 at 6:49 AM, Ed Hynan eh_l...@optonline.net wrote: Failure to set the resource limits isn't considered fatal for setusercontext(). It would be Bad if a typo there could leave you unable to login or su to root... Agreed. My case is a less drastic example: it's good that that su succeeded so the job could run. The new log message is good too, I'm glad I saw it and could respond. BTW, setusercontext(3) does not mention that setting resource failure is not fatal. So, the absence openfiles-max in the original login.conf is intentional? Before that log message, I was never prompted to think this through this far. It wasn't necessary to set them, so why over-specify them? IIRC, we had actually increased the defaults not too long ago to handle the increased demands of stuff like gnome and firefox. If we wrote out all the limits, then upgrades would be more painful as more lines would have to change. I suppose higher limits are easier all around, particularly re. the sort of software you mention. I recall changing menus to use a wrapper script because firefox was exceeding a files soft limit (NetBSD 2.0 I think, but that's beside the point). OTOH, lower limits expose more bad code. Just mentioning that, not suggesting OpenBSD shouldn't increase limits. -Ed
Re: 5.4 (GENERIC) box has begun to randomly reboot
On 08/05/14 10:02, Craig R. Skinner wrote: Hi, A reliable box has begun to randomly reboot in the last couple of days. There's nothing obviously unusual in /var/log/* $ ls -ld /var/crash drwxrwx--- 2 root wheel 512 Dec 24 2013 /var/crash/ $ ls -lA /var/crash total 4 -rw-r--r-- 1 root wheel 5 Jul 30 2013 minfree I set up a 1 min cron job of sysctl | fgrep hw.sensors.lm1.temp uptime The last one before a reboot was: hw.sensors.lm1.temp0=34.00 degC hw.sensors.lm1.temp2=33.50 degC 2:53PM up 31 mins, 2 users, load averages: 0.13, 0.19, 0.23 I'm guessing some bit of hardware is on it's way out, but which? $ ls -l /var/run/dmesg.boot -rw-r--r-- 1 root wheel 3612 Aug 5 14:58 /var/run/dmesg.boot OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class, 128KB L2 cache) 635 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF real mem = 535228416 (510MB) avail mem = 515035136 (491MB) So, a nice venerable P III.. I have several Dell's of that vintage all running well, after 10+ years. Me, I'd get the memtest CD and use that for a start. Easy. In decreasing order I'd say 5) motherboard problem, 4) power supply, 3) memory, 2) cabling failure, 1) disk controller. I did once have a really strange problem of crashing, which turned out to be the on-board IDE controller. I put a Siig sata controller in it and still works today. So a varient on )5. Don't forget about dust and around the fans. I'd take it outside and use compressed air of some kind to clean it. Good luck... --STeve Andre'
Re: 5.4 (GENERIC) box has begun to randomly reboot
On 08/05/14 10:02, Craig R. Skinner wrote: Hi, A reliable box has begun to randomly reboot in the last couple of days. ... I'm guessing some bit of hardware is on it's way out, but which? I think that's a safe guess. OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class, 128KB L2 cache) 635 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF real mem = 535228416 (510MB) avail mem = 515035136 (491MB) This box has done its time. I love running on old hw as much as anyone, but really, it isn't worth troubleshooting a box like this. If you spend an hour on it, it's not worth it...if it crashes one more time, it's not worth it. Go find yourself a P4 someone is tossing out, pull your 250G disk out of this box, put it in the P4. Loose the 30G. Enjoy the faster performance. Not only is the CPU faster, you should be running at UDMA mode 4 or 5, and you might get a lot more RAM if you are lucky. If it still crashes and reboots, it's your disk or the power you are applying. BTW: stupidly simple cause for reboots: old UPS systems. Battery goes dead, and your UPS saves you from a harmless power glitch...by turning it into a multi-second power OUTAGE. I've also seen perfectly functional UPSs that couldn't switch over fast enough for some computers, again causing a reboot. Nick.
Re: unbound on ~ last 2-3 snapshots
Just a quick followup on a thread I started on July 26. Turned out to be a configuration error on my end. Originally I had unbound listening on both localhost and the internal interface. This was a carry-over from previously using dnsmasq on 5.4. dnsmasq would log informational messages along the lines of 'Cannot bind to wildcard address due to OS limitations'. Got tired of seeing that in logs, which listening on localhost and internal eliminated. What eliminated the weirdness was binding to the wildcard addy: unbound.conf interface: 0.0.0.0 forward zone: name: . forward-addr: 127.0.0.1@5353 resolv.conf - nameserver 127.0.0.1 dnscrypt-proxy is listening on 127.0.0.1@5353 Also starting unbound with unbound_flags=-v -v -v gives much more useful info: [1407271075] unbound[1525:0] debug: Forward zone server list: [1407271075] unbound[1525:0] info: DelegationPoint.: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS [1407271075] unbound[1525:0] debug:ip4 127.0.0.1 port 5353 (len 16) The above is what you want to see if it is all hooked up correctly. Sometimes the answers are staring you right in the face and you just don't see them... Hopefully this helps anyone new to unbound and dnscrypt-proxy. -- Z
