Re: smtpd stops immediately after starting in -current
On Mon, May 19, 2014, at 02:27 PM, Philip Guenther wrote: > Actually, before doing that, you can try capturing a core for the > privseped processes? Add > kern.nosuidcoredump=3 > to /etc/sysctl.conf, reboot, and mkdir /var/crash/smtpd, then reproduce > the problem and see if there's core file(s) in /var/crash/smtpd/ Yes, there is a core file. It's been years since I looked at core files, but happy to try if you can give me some direction. Allan
Re: bind port broken
Stéphane Guedon writes: > Le lundi 19 mai 2014 14:59:54, vous avez écrit : >> You provide zero details on what you are doing, how can someone know >> what to fix without the minimum bits of information. > > I was aware of the thing, yet didn't know what to do since I have done > really really few. > > I just placed myself in /usr/ports/net/isc-bind and launched a make > clean, then make as explained on the faq page. > > Then, make produced a lot of compil work which ended at : [...] > *** Error 2 in bin/named (Makefile:559 'named') > *** Error 1 in bin (Makefile:100 'subdirs') > *** Error 1 in /usr/obj/ports/isc-bind-9.9.3pl1/build-amd64 > (Makefile:107 'subdirs') > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659 > '/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/.build_done') > *** Error 1 in /usr/ports/net/isc-bind > (/usr/ports/infrastructure/mk/bsd.port.mk:2388 'all') > > The release is bind 9.9.3, I am on amd64 and my openbsd is a 5.5 just > upgraded (so I had to rebuild my bind cause it contains the dnssec > signer I use). $ cd /usr/ports/net/isc-bind && cvs up -r OPENBSD_5_5 Makefile gives me a 9.9.5 bind port, not 9.9.3. Confusing... [...] -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Happy Birthday, Theo
/happy birthday Theo, You share the same bday as my mum ;) haha Andy On Mon, 19 May 2014 12:58:46 +, Артур Истомин wrote: > On Mon, May 19, 2014 at 12:03:37PM +0200, Marcus MERIGHI wrote: >> Happy Birthday, Theo. Thanks for doing your thing. >> >> Others: please remember to donate/buy. > > My warmest congratulations too!
Re: bind port broken
Le lundi 19 mai 2014 14:59:54, vous avez écrit : > You provide zero details on what you are doing, how can someone know > what to fix without the minimum bits of information. I was aware of the thing, yet didn't know what to do since I have done really really few. I just placed myself in /usr/ports/net/isc-bind and launched a make clean, then make as explained on the faq page. Then, make produced a lot of compil work which ended at : Error while executing cc -o .libs/named -pthread -I/usr/obj/ports/isc- bind-9.9.3pl1/build-amd64 -I/usr/obj/ports/isc- bind-9.9.3pl1/bind-9.9.3-P1/bin/named/include -I/usr/obj/ports/isc- bind-9.9.3pl1/bind-9.9.3-P1/bin/named/unix/include -I. - I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/lwres/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/lwres/unix/include -I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/lwres/include - I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/dns/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/dns/include - I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/bind9/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/bind9/include - I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/isccfg/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isccfg/include - I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/isccc/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isccc/include - I/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/lib/isc/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isc - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isc/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3-P1/lib/isc/unix/include - I/usr/obj/ports/isc-bind-9.9.3pl1/bind-9.9.3- P1/lib/isc/pthreads/include -I/usr/obj/ports/isc- bind-9.9.3pl1/bind-9.9.3-P1/lib/isc/x86_32/include -D_REENTRANT - DOPENSSL -O2 -pipe -I/usr/local/include/libxml2 -I/usr/local/include - W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat - Wpointer-arith -fno-strict-aliasing builtin.o client.o config.o control.o controlconf.o interfacemgr.o listenlist.o log.o logconf.o main.o notify.o query.o server.o sortlist.o statschannel.o tkeyconf.o tsigconf.o update.o xfrout.o zoneconf.o lwaddr.o lwresd.o lwdclient.o lwderror.o lwdgabn.o lwdgnba.o lwdgrbn.o lwdnoop.o lwsearch.o unix/os.o unix/dlz_dlopen_driver.o -L.libs -llwres -lbind9 -lisccfg - ldns -lcrypto -lisccc -lisc -lpthread -lxml2 -lz -liconv -lm -Wl,- rpath-link,/usr/local/lib *** Error 2 in bin/named (Makefile:559 'named') *** Error 1 in bin (Makefile:100 'subdirs') *** Error 1 in /usr/obj/ports/isc-bind-9.9.3pl1/build-amd64 (Makefile:107 'subdirs') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659 '/usr/obj/ports/isc-bind-9.9.3pl1/build-amd64/.build_done') *** Error 1 in /usr/ports/net/isc-bind (/usr/ports/infrastructure/mk/bsd.port.mk:2388 'all') The release is bind 9.9.3, I am on amd64 and my openbsd is a 5.5 just upgraded (so I had to rebuild my bind cause it contains the dnssec signer I use). I tried to compil "manually" bind 9.10 from the release available on the isc website and get this error as well : *** Error 1 in lib/samples (Makefile:486 'resolve') *** Error 1 in lib (Makefile:100 'subdirs') *** Error 1 in /usr/local/src/bind-9.10.0-P1 (Makefile:105 'subdirs') hope you get better info now. > > Reading this page http://www.openbsd.org/report.html could help you. > > -luis > > On Mon, May 19, 2014 at 2:53 PM, Stéphane Guedon wrote: > > hello. > > > > I don't know if I am doing things ok, but the Bind9 port seems > > broken (in a fresh 5.5 install). > > > > Thanks if someone fix it. > > > > [demime 1.01d removed an attachment of type > > application/pgp-signature which had a name of signature.asc] [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: uaudio useless?
On 2014-05-19, Mike Larkin wrote: >> > Maybe there are audio dongles that run at hi-speed, otherwise uaudio(4) >> > looks pretty useless. > > FWIW, I have 3 different uaudio dongles and they all work fine. Well, these three don't (on USB2.0 ports): ===> HA Info NG Coax 2011 uaudio0 at uhub2 port 4 configuration 1 interface 0 "Burr-Brown from TI USB Audio DAC" rev 1.10/1.00 addr 5 uaudio0: audio rev 1.00, 2 mixer controls audio1 at uaudio0 uhidev4 at uhub2 port 4 configuration 1 interface 2 "Burr-Brown from TI USB Audio DAC" rev 1.10/1.00 addr 5 uhidev4: iclass 3/0 uhid2 at uhidev4: input=1, output=0, feature=0 ===> HA Info U2 USB to SPDIF uhidev4 at uhub2 port 4 configuration 1 interface 0 "HA INFO HA INFO U2 USB TO SPDIF" rev 1.10/0.01 addr 5 uhidev4: iclass 3/0 uhid2 at uhidev4: input=18, output=27, feature=0 uaudio0 at uhub2 port 4 configuration 1 interface 1 "HA INFO HA INFO U2 USB TO SPDIF" rev 1.10/0.01 addr 5 uaudio0: ignored setting with type 8193 format uaudio0: audio rev 1.00, 2 mixer controls audio1 at uaudio0 ===> Lindy USB 2.0 Audio Adapter Pro uaudio0 at uhub2 port 4 configuration 1 interface 0 "ABC C-Media USB Headphone Set" rev 1.10/1.00 addr 5 uaudio0: audio rev 1.00, 8 mixer controls audio1 at uaudio0 uhidev4 at uhub2 port 4 configuration 1 interface 3 "ABC C-Media USB Headphone Set" rev 1.10/1.00 addr 5 uhidev4: iclass 3/0 uhid2 at uhidev4: input=4, output=4, feature=0 -- Christian "naddy" Weisgerber na...@mips.inka.de
bind port broken
hello. I don't know if I am doing things ok, but the Bind9 port seems broken (in a fresh 5.5 install). Thanks if someone fix it. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: LibreSSL @ BSDCan 2014
> On May 18, 2014, at 4:18, Marc Espie > > Actually, if you were awake at the time of the talk, you probably heard > something of a distant rumble. > > Bob is the only OpenBSD developer who's a match to the humpback whale in > terms of sound carrying power. That comes from all those years of chasing the malcontents out of the undergrad computer labs with an axe ...
Re: Boot panic on MP amd64 with 5.5, snapshot kernels
On Mon, May 19, 2014 at 03:56:05PM -0400, John D. Verne wrote: > On Mon, May 19, 2014 at 11:19:23AM -0700, Mike Larkin wrote: > > On Mon, May 19, 2014 at 01:42:49PM -0400, John D. Verne wrote: > > > On Sun, May 18, 2014 at 03:04:30PM -0400, John D. Verne wrote: > > > > I just got a new amd64 box to run OpenBSD on, but it is panicking on > > > > boot > > > > when I try to run the 5.5 kernel on it. > > > > > > > > The panic is "unknown MPS interrupt trigger 2" somewhere in the acpi > > > > code. > > > > > > > > bsd.rd, bsd and bsd.mp all panic in the same places, as does bsd.rd from > > > > the latest amd64 snapshot. > > > > > > > > > > NetBSD 6.1.4 manages to enumerate all the ACPI stuff when I use their > > > boot image. So there's that. > > > > > > As an aside, I was surprised at how different the src/sys tree is from > > > OpenBSD. But I'm going to try and see how they handle the Intel ACPICA > > > 20110623 device, which seems to be the thing that is not working right. > > > > > > > Get a dump of the AML using FreeBSD then. Can't really help otherwise. > > > > Well, the FreeBSD boot panics in a similar sort of way. "Bogus interrupt > trigger mode". This is from memory -- I didn't get a full copy of the boot > messages, though it did have "acpi" and "madt" in backtrace. > > I can get it if this is important, though this is starting to look like > a Windows-only box. > However, the FreeBSD message allowed my Google-fu to work. This looks apropos: http://forums.freenas.org/index.php?threads/kernel-panic-bogus-interrupt-trigger-mode-on-intel-j1900.20851/ And http://www.freebsd.org/cgi/query-pr.cgi?pr=187966 Nearly the exact hardware I have. Which also appears to have a buggy BIOS. -- John D. Verne
Re: Boot panic on MP amd64 with 5.5, snapshot kernels
On Mon, May 19, 2014 at 11:19:23AM -0700, Mike Larkin wrote: > On Mon, May 19, 2014 at 01:42:49PM -0400, John D. Verne wrote: > > On Sun, May 18, 2014 at 03:04:30PM -0400, John D. Verne wrote: > > > I just got a new amd64 box to run OpenBSD on, but it is panicking on boot > > > when I try to run the 5.5 kernel on it. > > > > > > The panic is "unknown MPS interrupt trigger 2" somewhere in the acpi > > > code. > > > > > > bsd.rd, bsd and bsd.mp all panic in the same places, as does bsd.rd from > > > the latest amd64 snapshot. > > > > > > > NetBSD 6.1.4 manages to enumerate all the ACPI stuff when I use their > > boot image. So there's that. > > > > As an aside, I was surprised at how different the src/sys tree is from > > OpenBSD. But I'm going to try and see how they handle the Intel ACPICA > > 20110623 device, which seems to be the thing that is not working right. > > > > Get a dump of the AML using FreeBSD then. Can't really help otherwise. > Well, the FreeBSD boot panics in a similar sort of way. "Bogus interrupt trigger mode". This is from memory -- I didn't get a full copy of the boot messages, though it did have "acpi" and "madt" in backtrace. I can get it if this is important, though this is starting to look like a Windows-only box. -- John D. Verne
Re: smtpd stops immediately after starting in -current
On Mon, May 19, 2014 at 11:22 AM, Kenneth Westerback wrote: > On 18 May 2014 15:19, Norman Golisz wrote: > ... > > smtp-in: New session 80dc422d384e8c2d from host 1000@localhost [local] > > warn: parent -> pony: pipe closed > > warn: queue -> pony: pipe closed > ... > > OpenBSD 5.5-current (GENERIC.MP) #132: Fri May 16 10:26:11 MDT 2014 > > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Try with something newer. Others (including me) have found today's > snap to work. For as yet unknown reasons. > Actually, before doing that, you can try capturing a core for the privseped processes? Add kern.nosuidcoredump=3 to /etc/sysctl.conf, reboot, and mkdir /var/crash/smtpd, then reproduce the problem and see if there's core file(s) in /var/crash/smtpd/ If this *is* a problem in the code found by the new -fshuffle-stack option, we should track it down! Philip Guenther
Re: smtpd stops immediately after starting in -current
On 18 May 2014 15:19, Norman Golisz wrote:
> Hi Gilles,
>
> On Sun May 18 2014 13:45, Gilles Chehade wrote:
>> can you share your configuration file ?
>>
>> i'm unable to reproduce no matter what i try :-/
>
> I'm also able to reproduce this crash:
>
> $ echo test | mail norman && sudo smtpd -dv
>
> debug: init ssl-tree
> info: OpenSMTPD 5.4.3 starting
> debug: bounce warning after 4h
> debug: using "fs" queue backend
> debug: using "ramqueue" scheduler backend
> debug: using "ram" stat backend
> info: startup [debug mode]
> debug: init ssl-tree
> debug: parent_send_config_ruleset: reloading
> debug: parent_send_config: configuring pony process
> debug: parent_send_config: configuring ca process
> debug: init private ssl-tree
> debug: queue: done loading queue into scheduler
> debug: ca_engine_init: using RSAX engine support
> debug: smtp: listen on 127.0.0.1 port 25 flags 0x0 pki ""
> debug: smtp: listen on IPv6:fe80::1%lo0 port 25 flags 0x0 pki ""
> debug: smtp: listen on IPv6:::1 port 25 flags 0x0 pki ""
> debug: smtp: will accept at most 501 clients
> debug: smtpd: scanning offline queue...
> debug: smtpd: enqueueing offline message
> /var/spool/smtpd/offline/1400440122.uj4xYO8YaC
> debug: smtpd: offline scanning done
> debug: smtp: new client on listener: 0x14804c2680c0
> smtp-in: New session 80dc422d384e8c2d from host 1000@localhost [local]
> warn: parent -> pony: pipe closed
> warn: queue -> pony: pipe closed
> warn: ca -> pony: pipe closed
> warn: control -> pony: pipe closed
> warn: scheduler -> queue: pipe closed
> warn: lka -> pony: pipe closed
>
>
> smtpd.conf:
>
> listen on lo0
>
> table aliases db:/etc/mail/aliases.db
>
> table secrets { me => me.local:whoohoo}
>
> accept for local alias deliver to maildir
> accept for any relay via tls+auth://m...@smtp.me.local:587 auth
>
>
> dmesg:
>
> OpenBSD 5.5-current (GENERIC.MP) #132: Fri May 16 10:26:11 MDT 2014
> t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Try with something newer. Others (including me) have found today's
snap to work. For as yet unknown reasons.
Ken
> real mem = 4166717440 (3973MB)
> avail mem = 4047036416 (3859MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
> bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
> bios0: LENOVO 6475BE3
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA
> DMAR SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4)
> EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3)
> EHC1(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 Duo CPU P8400 @ 2.26GHz, 2261.31 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
> cpu0: 3MB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
> cpu0: apic clock running at 266MHz
> 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 Duo CPU P8400 @ 2.26GHz, 2261.01 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
> cpu1: 3MB 64b/line 8-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 0xe000, 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 -1 (EXP2)
> acpiprt5 at acpi0: bus 5 (EXP3)
> acpiprt6 at acpi0: bus 13 (EXP4)
> acpiprt7 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, USB3, USB5, EHC0, EHC1
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 model "42T5264" serial 3499 type LION oem "Panasonic"
> acpibat1 at acpi0: BAT1 not present
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> acpidock0 at acpi0: GDCK docked (15)
> cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 1600, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
> vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
>
Re: Boot panic on MP amd64 with 5.5, snapshot kernels
On Mon, May 19, 2014 at 01:42:49PM -0400, John D. Verne wrote: > On Sun, May 18, 2014 at 03:04:30PM -0400, John D. Verne wrote: > > I just got a new amd64 box to run OpenBSD on, but it is panicking on boot > > when I try to run the 5.5 kernel on it. > > > > The panic is "unknown MPS interrupt trigger 2" somewhere in the acpi > > code. > > > > bsd.rd, bsd and bsd.mp all panic in the same places, as does bsd.rd from > > the latest amd64 snapshot. > > > > NetBSD 6.1.4 manages to enumerate all the ACPI stuff when I use their > boot image. So there's that. > > As an aside, I was surprised at how different the src/sys tree is from > OpenBSD. But I'm going to try and see how they handle the Intel ACPICA > 20110623 device, which seems to be the thing that is not working right. > Get a dump of the AML using FreeBSD then. Can't really help otherwise. And PS there is no such thing as an "Intel ACPICA 20110623 device". That's the parser code NetBSD is using. We have our own. > -- > John D. Verne >
Re: uaudio useless?
On Sun, May 18, 2014 at 10:17:41PM +0100, Kevin Chadwick wrote: > previously on this list Christian Weisgerber contributed: > > > Maybe > > there are audio dongles that run at hi-speed, otherwise uaudio(4) > > looks pretty useless. > FWIW, I have 3 different uaudio dongles and they all work fine. One is a Creative (I can get the model # if you want) and the other two are no-name brands. I have a fourth uaudio that attaches in an expresscard slot and that one doesn't work, but it's not for the same reason as yours (it can't understand the codecs, I think). -ml > I may have one as it supports DSD however it comes up as ugen currently > so I am not sure if it would use uaudio until I have the time to look > into how much I can get to work with OpenBSD. > > -- > ___ > > 'Write programs that do one thing and do it well. Write programs to work > together. Write programs to handle text streams, because that is a > universal interface' > > (Doug McIlroy) > > In Other Words - Don't design like polkit or systemd > ___ > > I have no idea why RTFM is used so aggressively on LINUX mailing lists > because whilst 'apropos' is traditionally the most powerful command on > Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool > to help psychopaths learn to control their anger. > > (Kevin Chadwick) > > ___
Re: match in nat-to rule
Em 19-05-2014 14:51, Peter N. M. Hansteen escreveu: > Alexey Kurinnij writes: > >> nat-to rule not work if match and work when pass: >> match out quick on egress inet from !(egress:network) to any nat-to >> (egress:0) - not work >> pass out quick on egress inet from !(egress:network) to any nat-to >> (egress:0) - work > Well, the match would need to be supplemented by a pass rule that > matches whatever the packet looks like *after* the transformation the > match rule performs. After the match rule here, the source address is > whatever (egress:0) works out to be in your system, so you need a pass > rule that matches that specification. > > And on a side note, the way to untangle stuff like this is to add log > (matches) to rules for debugging. That will log all rules your packet > matches after it has matched your logging rule. > > I have a fairly trivial illustration in the tutorial slides at > http://home.nuug.no/~peter/pf/newest/log.match.matches.html > > - Peter Also, I only use rdr-to in pass rules, not in match. That's because, as Peter said, you can't always predict what the packet will look like, after your match rule. In addition to logging, you can always use tags to control your packet flow. This way you can effectively "debug" your ruleset. Also, I'm using pflow(4) with nfsen to capture the flows and post analyze them. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: smtpd stops immediately after starting in -current
Hi Gilles,
On Sun May 18 2014 13:45, Gilles Chehade wrote:
> can you share your configuration file ?
>
> i'm unable to reproduce no matter what i try :-/
I'm also able to reproduce this crash:
$ echo test | mail norman && sudo smtpd -dv
debug: init ssl-tree
info: OpenSMTPD 5.4.3 starting
debug: bounce warning after 4h
debug: using "fs" queue backend
debug: using "ramqueue" scheduler backend
debug: using "ram" stat backend
info: startup [debug mode]
debug: init ssl-tree
debug: parent_send_config_ruleset: reloading
debug: parent_send_config: configuring pony process
debug: parent_send_config: configuring ca process
debug: init private ssl-tree
debug: queue: done loading queue into scheduler
debug: ca_engine_init: using RSAX engine support
debug: smtp: listen on 127.0.0.1 port 25 flags 0x0 pki ""
debug: smtp: listen on IPv6:fe80::1%lo0 port 25 flags 0x0 pki ""
debug: smtp: listen on IPv6:::1 port 25 flags 0x0 pki ""
debug: smtp: will accept at most 501 clients
debug: smtpd: scanning offline queue...
debug: smtpd: enqueueing offline message
/var/spool/smtpd/offline/1400440122.uj4xYO8YaC
debug: smtpd: offline scanning done
debug: smtp: new client on listener: 0x14804c2680c0
smtp-in: New session 80dc422d384e8c2d from host 1000@localhost [local]
warn: parent -> pony: pipe closed
warn: queue -> pony: pipe closed
warn: ca -> pony: pipe closed
warn: control -> pony: pipe closed
warn: scheduler -> queue: pipe closed
warn: lka -> pony: pipe closed
smtpd.conf:
listen on lo0
table aliases db:/etc/mail/aliases.db
table secrets { me => me.local:whoohoo}
accept for local alias deliver to maildir
accept for any relay via tls+auth://m...@smtp.me.local:587 auth
dmesg:
OpenBSD 5.5-current (GENERIC.MP) #132: Fri May 16 10:26:11 MDT 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4047036416 (3859MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 6475BE3
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4)
EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3)
EHC1(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 Duo CPU P8400 @ 2.26GHz, 2261.31 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 266MHz
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 Duo CPU P8400 @ 2.26GHz, 2261.01 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF
cpu1: 3MB 64b/line 8-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 0xe000, 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 -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0: bus 13 (EXP4)
acpiprt7 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, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T5264" serial 3499 type LION oem "Panasonic"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK docked (15)
cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1440x900
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev
Re: Boot panic on MP amd64 with 5.5, snapshot kernels
On Sun, May 18, 2014 at 03:04:30PM -0400, John D. Verne wrote: > I just got a new amd64 box to run OpenBSD on, but it is panicking on boot > when I try to run the 5.5 kernel on it. > > The panic is "unknown MPS interrupt trigger 2" somewhere in the acpi > code. > > bsd.rd, bsd and bsd.mp all panic in the same places, as does bsd.rd from > the latest amd64 snapshot. > NetBSD 6.1.4 manages to enumerate all the ACPI stuff when I use their boot image. So there's that. As an aside, I was surprised at how different the src/sys tree is from OpenBSD. But I'm going to try and see how they handle the Intel ACPICA 20110623 device, which seems to be the thing that is not working right. -- John D. Verne
Re: sharing network and address between tables and softwares
Em 19-05-2014 06:35, Stéphane Guedon escreveu: > I make some use of address tables in pf. Less than some of the great > expert we have there, but still. > > I was wondering if it were possible to share the tables defined in pf > to work with other softwares. > > I think particularely to use the table defined in > /etc/pf.cnf in smtpd too, to allow pass directly without auth. > > Do you understand me ? > Thanks in advance. > > [demime 1.01d removed an attachment of type application/pgp-signature which > had a name of signature.asc] > Tables on pf.conf can be files. So you could create files with the networks/hosts, have them be imported on pf.conf and read by smtpd. From what I read from the table(5) documentation, these files could be used by it, no problems. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: smtpd stops immediately after starting in -current
On Mon, May 19, 2014 at 03:55:20PM +0200, David Coppa wrote: > On Mon, May 19, 2014 at 3:22 PM, Gilles Chehade wrote: > > Can you guys update to yesterday's snapshot and confirm that you still > > experience this issue ? > > > > Two people have told me they no longer experience the crash since > > yesterday's snapshot, and > > neither do I > > Confirmed again. It's working now. > Just to be clear, I have not changed anything meanwhile. It has stopped working recently and has resumed working yesterday. Either we hit a LibreSSL fallout that was fixed meanwhile, or we still have the bug and as toddf@ pointed out the gcc randomization of local variables is exposing it ... if we're lucky :-/ -- Gilles Chehade https://www.poolp.org @poolpOrg
match in nat-to rule
nat-to rule not work if match and work when pass:
match out quick on egress inet from !(egress:network) to any nat-to
(egress:0) - not work
pass out quick on egress inet from !(egress:network) to any nat-to
(egress:0) - work
Today I install 5.5 and copy old pf.conf to new system, and remove queuing
rules, but NAT not work with this config.
I remove all restriction rules and put accept all outgoing on both
interfaces and all input on internal interface.
What I doing wrong?
# cat
/etc/pf.conf
# macros
int_if="re0"
ext_if="rl0"
tcp_ext_services="{ 22, 443, 51413 }"
tcp_int_services="{ 22, 53, 80 }"
udp_int_services="{ 53, 69 }"
icmp_types="echoreq"
# options
set block-policy drop
set skip on lo
# match rules
pass out quick on egress inet from !(egress:network) to any nat-to
(egress:0)
match in on egress proto tcp from !$int_if to (egress) port 443 \
rdr-to (egress) port 22
# filter rules
block log
antispoof quick for { lo $int_if }
pass in inet proto icmp all icmp-type $icmp_types
# filter rules for (egress)
pass in on egress inet proto tcp from any to (egress) \
port $tcp_ext_services
pass out on egress from (egress)
# filter rules for $int_if
pass in on $int_if proto tcp from $int_if:network to $int_if port
$tcp_int_servi
ces
pass in on $int_if proto udp from $int_if:network to $int_if port
$udp_int_servi
ces
pass in on $int_if from $int_if:network to !$int_if
pass out on $int_if to $int_if:network
Re: Multihoming with carp possible? and ipsec failover?
Em 17-05-2014 16:26, Florenz Kley escreveu: > On May 13, 2014, at 22:13, Giancarlo Razzolini wrote: >> go there, this e-mail would be too big. If you want I can elaborate more. > yes please! do elaborate a bit! > > fl > Well, I always wanted to write an article and post it on a blog. But never really stopped everything and wrote it. I'll try to condense things on this e-mail, but I'll also try to write a lengthier article someday. First of all, you need to enable ip forwarding and, if you want your firewall machine itself, to have multiple gateways in it's routing table, you'll need to enable multipath routing. Both these are on sysctl.conf. The multipath part is really only needed if you'll run other services on your firewall itself. Such as a dns daemon, a proxy, etc. The firewall must be able to reach the internet at all times, or you'll have problems in this case. Now, you need to determine how you will be able to tell if a determined ISP link is down. This part is the one that gets more different ways to accomplish. Somebody always will tell you to simply ping an external IP address and get over with it. I really don't like it and use it only as last resort. Anyway, one nice way to determine if a link is down, is to use snmp. You can enable snmp on your ISP router/modem/whatever, do an snmpwalk on it, determine which interfaces it show. Then you trigger a disconnect and see which one of them are down. These will be the ones you'll check. You can write a simple script that does an snmpget on the interface oid and check if the state is up or down. If your router do not have snmp, but does have another form of remote administration, like a web interface or telnet, you can either write a script that connects on it via http and go to the page where it prints the internet connection status and check if it's connected. Or you can write a expect script to connect to it via telnet and type the commands that will show if the connection is up, or not. The external ip pinging part is the easiest to implement, but also easily to get wrong. You need to ping more than one IP address and only if all of them fail to reply, them you can (hopefully) consider the link down. I hope you got the idea. Almost forgot to mention, you need to script these to simply return 0 or 1 to the shell that runs it. This is the way that ifstated will be able to tell if the link is up or down. As you can see, there are several ways to accomplish this. The next part is to write the ifstated configuration. This is not as hard as it seems. It's a state machine. It is a: do this, if this fails, do that, but if it gets back, return to the previous state. Or do something entirely different. You have at least n² states. n being the number of internet links you have. So, if you have 2 links, you have at least 4 states. If you have 3, 6 states, and so on. The reason is that you need an state where all the links are on (the state where we hope it will be most of the time) and one where all the links are off (zombie apocalypse anyone?). Remember those scripts you wrote that monitor your links? You'll configure them to run in your ifstated every x seconds. The x here you'll define based on what you want to accomplish. Mine run every 20 seconds. So basically you'll have some lines in the beginning of your ifstated.conf that are something like this: link_isp = '( "" every 20 )' The first state you define on ifstated will be the default state, unless you override with the default_state option. So, the first state will most likely be the state where all the links are up. You can run things when you enter a state. I use this to update dynamic dns records, to mail me when a link is down, reload/restart daemons that are bound to a determined isp connection, etc. But the most important thing to do is to change your pf rules when you change states. To do this, there are lots of ways too. I use anchors. So, I have n²-1 anchor files. n being the number of links you have. Because when all of them are down, there is no point in changing your rules. You could point your users to a internal web page telling them they have no internet, and, therefore, no facebook for them. But this is out of the scope. Anyway, I use ifstated to load anchors that change the pf rules to use the isp's that are working. So how you point your users to different gateways? You use the route-to option. This will point any machine using your firewall to the gateways you choose. Since this will be up entirely to you, I'll not go into details here. Just be sure to not confuse traffic that the machines behind your firewall generate, from traffic that your firewall itself generate. These need to be dealt differently, in the case of a link change. As I mentioned before, if you only have pf on the firewall, you can just use anchors and you are ok. If not, you'll need to change the routes on the firewall itself, with multipath. In my case, I simply play with the routing pr
Re: Happy Birthday, Theo
On Mon, May 19, 2014 at 12:03:37PM +0200, Marcus MERIGHI wrote: > Happy Birthday, Theo. Thanks for doing your thing. > > Others: please remember to donate/buy. My warmest congratulations too!
Re: smtpd stops immediately after starting in -current
On Mon, May 19, 2014 at 3:22 PM, Gilles Chehade wrote: > Can you guys update to yesterday's snapshot and confirm that you still > experience this issue ? > > Two people have told me they no longer experience the crash since yesterday's > snapshot, and > neither do I Confirmed again. It's working now. thanks, David
Re: sharing network and address between tables and softwares
On Mon, May 19, 2014 at 11:35, Stéphane Guedon wrote: > I make some use of address tables in pf. Less than some of the great > expert we have there, but still. > > I was wondering if it were possible to share the tables defined in pf > to work with other softwares. > > I think particularely to use the table defined in > /etc/pf.cnf in smtpd too, to allow pass directly without auth. smtd.conf: listen on lo0 port 587 tag islocal accept from any for any relay tagged islocal pf.conf: pass in something something rdr-to localhost port 587
Re: smtpd stops immediately after starting in -current
Can you guys update to yesterday's snapshot and confirm that you still experience this issue ? Two people have told me they no longer experience the crash since yesterday's snapshot, and neither do I On Sat, May 17, 2014 at 05:30:25PM -0400, Allan Streib wrote: > Just upgraded to -current from my local mirror. Was previously working with a > recent-ish -current (late April or early May) > > In /var/log/maillog: > > May 17 17:00:29 fabrik smtpd[8370]: info: OpenSMTPD 5.4.3 starting > May 17 17:00:29 fabrik smtpd[23758]: info: startup > May 17 17:00:30 fabrik smtpd[23464]: smtp-in: New session 3c7a8ed5bcd7c87e > from host 1000@localhost [local] > May 17 17:00:30 fabrik smtpd[6061]: warn: ca -> pony: pipe closed > May 17 17:00:30 fabrik smtpd[29180]: warn: control -> pony: pipe closed > May 17 17:00:30 fabrik smtpd[23758]: warn: parent -> pony: pipe closed > May 17 17:00:30 fabrik smtpd[15221]: warn: lka -> pony: pipe closed > May 17 17:00:30 fabrik smtpd[12014]: warn: queue -> pony: pipe closed > May 17 17:00:30 fabrik smtpd[11724]: warn: scheduler -> control: pipe closed > > $ sudo /usr/sbin/smtpd -d -v > debug: init ssl-tree > info: OpenSMTPD 5.4.3 starting > debug: bounce warning after 4h > debug: using "fs" queue backend > debug: using "ramqueue" scheduler backend > debug: using "ram" stat backend > info: startup [debug mode] > debug: init ssl-tree > debug: ca_engine_init: using RSAX engine support > debug: parent_send_config_ruleset: reloading > debug: parent_send_config: configuring pony process > debug: parent_send_config: configuring ca process > debug: smtp: listen on 127.0.0.1 port 25 flags 0x0 pki "" > debug: smtp: listen on IPv6:fe80::1%lo0 port 25 flags 0x0 pki "" > debug: smtp: listen on IPv6:::1 port 25 flags 0x0 pki "" > debug: smtp: will accept at most 501 clients > debug: init private ssl-tree > debug: queue: done loading queue into scheduler > debug: smtpd: scanning offline queue... > debug: smtpd: enqueueing offline message > /var/spool/smtpd/offline/1400360297.gGOeYTNHCB > debug: smtpd: offline scanning done > debug: smtp: new client on listener: 0x870670680c0 > smtp-in: New session 196f0b916c2465b1 from host 1000@localhost [local] > warn: ca -> pony: pipe closed > warn: lka -> pony: pipe closed > warn: queue -> pony: pipe closed > warn: control -> pony: pipe closed > warn: parent -> pony: pipe closed > warn: scheduler -> queue: pipe closed > > $ dmesg > OpenBSD 5.5-current (GENERIC.MP) #132: Fri May 16 10:26:11 MDT 2014 > t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 10715041792 (10218MB) > avail mem = 10421043200 (9938MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe00f0 (73 entries) > bios0: vendor Apple Computer, Inc. version "MP11.88Z.005C.B08.0707021221" > date 07/02/07 > bios0: Apple Computer, Inc. MacPro1,1 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT ECDT FACP HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT > SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSD > T SSDT SSDT > acpi0: wakeup devices P2P5(S4) P2P3(S4) ARPT(S4) RP04(S4) UHC1(S3) UHC2(S3) > UHC3(S3) UHC4(S3) EHCI(S3) AC9M(S4) EC__(S3) NRP4(S4) SR > P1(S4) SRP3(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiec0 at acpi0 > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.38 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,DT > ES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,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 332MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2660.00 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,DT > ES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF > cpu1: 4MB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 7 (application processor) > cpu2: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2659.99 MHz > cpu2: > 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,DT > ES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,NXE,LONG,LAHF,PERF > cpu2: 4MB 64b/line 16-way L2 cache > cpu2: smt 0, core 1, package 3 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU 5150 @ 2.66GHz, 2659.99 MHz > cpu3: > 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,DT > ES64,
Re: smtpd stops immediately after starting in -current
On Sun, May 18, 2014 at 2:03 PM, Kenneth Westerback wrote: > On 18 May 2014 07:52, Gilles Chehade wrote: >> On Sun, May 18, 2014 at 07:37:26AM -0400, Kenneth Westerback wrote: >>> On 18 May 2014 05:37, Gilles Chehade wrote: >>> > On Sat, May 17, 2014 at 10:40:13PM -0400, Allan Streib wrote: >>> >> On Sat, May 17, 2014, at 05:30 PM, Allan Streib wrote: >>> >> >>> >> > Just upgraded to -current from my local mirror. Was previously working >>> >> > with a recent-ish -current (late April or early May) >>> >> >>> >> By "current" I meant "snapshot" sorry if that caused any confusion. >>> >> >>> > >>> > I'll have a look at this, thanks >>> > >>> > -- >>> > Gilles Chehade >>> > >>> > https://www.poolp.org @poolpOrg >>> > >>> >>> I've found that if there is anything processed from the offline queue >>> then smtpd stops immediately. If I remove all offline files then smtpd >>> starts up fine but as soon as I send an email (using mutt) it exits. >>> >> >> strange :-/ >> >> I am running an opensmtpd -current on top of a snapshot one week-old and >> no matter what I try I can't reproduce with the default configuration. > > Oddly enough, I upgraded a working machine that had a week old > snapshot to -current and that's when the problem surfaced. :-) > > I suspect some LibreSSL fall out, but only because of the churn there, > not because of anything I saw go by that I can link to the issue. > > Ken > >> >> I just tried to enqueue offline mails after reading your mail: >> >> $ echo test | mail gilles && sudo smtpd -dv >> debug: init ssl-tree >> info: OpenSMTPD 5.4.3 starting >> [...] >> debug: smtpd: scanning offline queue... >> debug: smtpd: enqueueing offline message >> /var/spool/smtpd/offline/1400413673.u5SMhBkRCh >> debug: smtpd: offline scanning done >> debug: smtp: new client on listener: 0x13b5a7e68100 >> smtp-in: New session 4af9e1d27b2d9096 from host 0@localhost [local] >> debug: 0x13b7b4d9c000: end of message, msgflags=0x >> smtp-in: Accepted message 1540150a on session 4af9e1d27b2d9096: >> from=, to=, size=169, ndest=1, >> proto=ESMTP >> debug: scheduler: evp:1540150aac11ccde scheduled (mda) >> smtp-in: Closing session 4af9e1d27b2d9096 >> debug: smtp: 0x13b7b4d9c000: deleting session: done >> mda: new user 4af9e1d38d21e391 for ":gilles" >> debug: lka: userinfo :gilles >> debug: mda: new session 4af9e1d4e7c887ea for user ":gilles" evpid >> 1540150aac11ccde >> debug: mda: no more envelope for ":gilles" >> debug: mda: got message fd 4 for session 4af9e1d4e7c887ea evpid >> 1540150aac11ccde >> debug: mda: querying mda fd for session 4af9e1d4e7c887ea evpid >> 1540150aac11ccde >> debug: smtpd: forking mda for session 4af9e1d4e7c887ea: >> "/home/gilles/Maildir" as gilles >> debug: mda: got mda fd 5 for session 4af9e1d4e7c887ea evpid 1540150aac11ccde >> debug: mda: end-of-file for session 4af9e1d4e7c887ea evpid 1540150aac11ccde >> debug: mda: all data sent for session 4af9e1d4e7c887ea evpid 1540150aac11ccde >> debug: smtpd: mda process done for session 4af9e1d4e7c887ea: exited okay >> delivery: Ok for 1540150aac11ccde: from=, >> to=, user=gilles, method=maildir, delay=0s, >> stat=Delivered >> debug: mda: session 4af9e1d4e7c887ea done >> debug: mda: user "gilles" becomes runnable >> debug: mda: all done for user ":gilles" >> >> >>> >>> When I had four files in offline, then there were 4 "New session" >>> lines before the 'warn' messages start. >>> >>> All on -current as of yesterday, including mutt. >>> >> >> I have no idea right now what could cause that but I'm looking into it >> and hopefully I can find a way to crash this afternoon. Confirmed: same problem here too :( ciao, David
Re: sharing network and address between tables and softwares
The simple workaround would be to have a "nicer" smtpd on a different port and have PF send to that one, which would not require auth. It depends on what amount of "realtime" you require for dynamic lists, and how easy you may feed a list from the kernel into that particular daemon. 2014-05-19 11:35 GMT+02:00 Stéphane Guedon : > I make some use of address tables in pf. Less than some of the great > expert we have there, but still. > > I was wondering if it were possible to share the tables defined in pf > to work with other softwares. > > I think particularely to use the table defined in > /etc/pf.cnf in smtpd too, to allow pass directly without auth. > > Do you understand me ? > Thanks in advance. > > [demime 1.01d removed an attachment of type application/pgp-signature > which had a name of signature.asc] > > -- May the most significant bit of your life be positive.
Happy Birthday, Theo
Happy Birthday, Theo. Thanks for doing your thing. Others: please remember to donate/buy. Bye, Marcus
sharing network and address between tables and softwares
I make some use of address tables in pf. Less than some of the great expert we have there, but still. I was wondering if it were possible to share the tables defined in pf to work with other softwares. I think particularely to use the table defined in /etc/pf.cnf in smtpd too, to allow pass directly without auth. Do you understand me ? Thanks in advance. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Multi-VRF bgpd (no MPLS)
Hello,
I'm trying to prevent my boss from buying an ASA 5585-X to use an OpenBSD box
instead. NAT on ASA is such a pain...
The use would be a WAN firewall, routing for sites with potentially identical
IP ranges. Overlapping IP ranges are translated by the firewall so that from
the point of view of the main site every IP is different.
Actually, this is done using ASA contexts and static routing. I'd like to do
the same with openBSD plus BGP routing.
So I started to set up a PF box with VRFs (one BSD VRF <-> one ASA context),
this works like a charm.
Problems start when I try to do BGP routing : basically what I need is one BGP
daemon running in each VRF.
I tried to launch BGP with route -T exec bgpd -f
/etc/bgpd.conf., it learns route from the WAN, but doesn't injects
them in the rdomain .
I dealt with the problem of nexhop qualifying on rdomain 0 using nexthop
qualify via default.
I have messages like these in my logs :
neighbor 10.200.18.209 (ADH200_EXT): state change OpenConfirm -> Established,
reason: KEEPALIVE message received
nexthop 10.200.18.209 now valid: via 10.194.126.254
send_rtmsg: action 1, prefix 10.199.13.112/28: Network is unreachable
send_rtmsg: action 1, prefix 10.199.12.112/28: Network is unreachable
My bgpd.conf :
# grep -v "^#" bgpd.adh200
peer_adh200_int="10.200.6.57"
peer_adh200_ext="10.200.18.209"
pool_adh200="10.199.12.112/28"
AS 65040
router-id 10.194.126.241
listen on 10.200.18.214
listen on 10.200.6.62
rtable 200
nexthop qualify via default
neighbor $peer_adh200_int {
descr "ADH200_INT"
remote-as 65040
}
neighbor $peer_adh200_ext {
descr "ADH200_EXT"
remote-as 65041
}
Some bgpctl show :
# bgpctl sh nex
Flags: * = nexthop valid
Nexthop Route Prio Gateway Iface
* 10.200.18.209 0.0.0.0/0 8 10.194.126.254 vlan3080 (UP, active)
# bgpctl sh rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
*>10.199.12.112/28 10.200.18.209 100 0 65041 i
*>10.199.13.112/28 10.200.18.209 100 0 65041 i
# route -T 200 show
Routing tables
Internet:
DestinationGatewayFlags Refs Use Mtu Prio Iface
default10.200.18.209 UGS00 - 8 carp450
10/8 sw-t-wan-adh200UGS00 - 8 carp2200
10.200.6.56/29 link#10UC 10 - 4 carp2200
10.200.6.56/29 link#10UC 10 - 4 carp2200
sw-t-wan-adh20000:08:e3:ff:fc:08 UHLc 3 38 - 4 carp2200
10.200.6.6200:00:5e:00:01:01 UHLc 01 - 4 lo0
10.200.14.56/29link#11UC 00 - 4 carp2450
10.200.14.56/29link#11UC 00 - 4 carp2450
10.200.18.208/29 link#12UC 00 - 4 carp450
10.200.18.208/29 link#12UC 00 - 4 carp450
10.200.18.208/29 link#12UC 00 - 4 carp450
10.200.18.208/29 link#12UC 10 - 4 carp450
10.200.18.209 00:1e:c9:49:17:d8 UHLc 2 234 - 4 carp450
172.16/12 sw-t-wan-adh200UGS00 - 8 carp2200
192.168/16 sw-t-wan-adh200UGS00 - 8 carp2200
Any idea of why those routes are not injected ?
Thanks
--
Cordialement,
Pierre BARDOU
Ingénieur réseau - P2I Infrastructure
05 67 69 71 84
MiPih
12, rue Michel Labrousse - BP93668
31036 TOULOUSE Cedex 1
www.mipih.fr
Avant d'imprimer cet e-mail, pensons à l'environnement
Re: adding a route to an rdomain on a vlan interface
'rdomain' must be the first line in the file. Changing the rdomain assignment will flush all IPs on the interface, so it will be blank. Re-running netstart "works", because you aren't actually changing the interface agaain. On 2014 May 19 (Mon) at 11:06:08 +0200 (+0200), Kjell Skogsrud wrote: :Hi : :I am using OpenBSD 5.5 as a router with rdomains. :Here is a list of my interfaces and relevant hostname files. : : - em1 the egress interface. : - em0 the trunk interface : - vlan42 http://slexy.org/view/s2naF3AZBS : - vlan43 http://slexy.org/view/s20VB137SM : :I use PF to point various IPs to internal hosts on different rdomains. :It all works great except for the !route part in the hostname files. : :At boot time I see these messages: :-- :starting network :route: writing to routeing socket: Network is unreachable :add net default: gateway 172.16.4.254: Network is unreachable :-- :But using: # sh /etc/netstart afterwards works just fine. :I have made a workaround by adding sh /etc/netstart to rc.local :but would like to know if there is a better/more correct way, and also :why it does not work like normal. : :Best regards :@kjellskogsrud : -- Machine-Independent, adj.: Does not run on any existing machine.
adding a route to an rdomain on a vlan interface
Hi I am using OpenBSD 5.5 as a router with rdomains. Here is a list of my interfaces and relevant hostname files. - em1 the egress interface. - em0 the trunk interface - vlan42 http://slexy.org/view/s2naF3AZBS - vlan43 http://slexy.org/view/s20VB137SM I use PF to point various IPs to internal hosts on different rdomains. It all works great except for the !route part in the hostname files. At boot time I see these messages: -- starting network route: writing to routeing socket: Network is unreachable add net default: gateway 172.16.4.254: Network is unreachable -- But using: # sh /etc/netstart afterwards works just fine. I have made a workaround by adding sh /etc/netstart to rc.local but would like to know if there is a better/more correct way, and also why it does not work like normal. Best regards @kjellskogsrud
Re: cron reload
2014-05-15 9:32 GMT+02:00 Philip Guenther : > On Wed, May 14, 2014 at 1:26 AM, Tomek WaÅaszek wrote: >> >> Sorry for the top post >> I'm just trying to understand why there is a unix-domain socket for >> reloading the cron if without the socket (rm /var/cron/tabs/.sock) cron >> will reload new jobs. >> > > If you're wondering why the developer added it, you should check the > commit logs. Since OpenBSD's cron is derived from Vixie cron, you may need > to dig through the Vixie cron changelogs. > > If you're wondering why it still uses a unix-domain socket: > 1) the socket is used for more than just "reload". check the source for > the details > 2) will the periodic scan notice a change if the clock jumps between the > change and the scan? What if the scan happens at the same moment as the > change? what if there are two changes in the same second, and the scan > takes place between them? How confident are you that the scan doesn't have > a corner case? > 3) is there a problem with it? > > > Philip Guenther > > Point number 2 answers my question ;) thanks
Re: Microsoft keyboard and touchpad combo, touchpad doesn't work
On 19 May 2014 00:50, Martin Pieuchot wrote: > On 18/05/14(Sun) 21:15, Ville Valkonen wrote: >> Hello all, >> [...] >> I can see it attaches as wsmouse2 but nevertheless it doesn't work. Any help >> how to debug this further would be highly appreciated. >> >> Thanks in advance and keep up the good work! >> >> P.S. Yes, you can see there's Logitech Unifying receivers too. Doesn't change >> the situation even those are unplugged. >> >> ### dmesg starts >> OpenBSD 5.5-current (GENERIC.MP) #125: Sun May 11 08:28:18 MDT 2014 > > Could you try a more recent snapshot and report back if it still doesn't > work? A change that might help went in one day after the snapshot > you're using. > > M. Hello Martin, should have had tried that in the first hand. Good news, works perfectly now. Thanks a much! -- Ville
