Re: samba maps nodoby as a home share
On Wed 26/10/2022 08:55, kasak wrote: > hello misc! > > Just want to share you some interesting samba behavior after update to 7.2 > > Samba now creates a share named "nobody" when it should not! > > The config is very simple: > > [global] > map to guest = Bad User > server min protocol = NT1 > > [homes] > comment = Home Directories > browseable = No > read only = No > > [share] > path = /mnt/HDD/share > read only = No > guest ok = Yes > guest only = Yes > > > I suspect, that samba improperly bind "nobody" as a "homes" share for guest > user. Setting 'map to guest = Bad User' means that user logins with an invalid password are rejected, unless the username does not exist, in which case it is treated as a guest login and mapped into the guest account. The latter is set to nobody [0]. > I've tried same conf on the fedora machine, with the same version of samba > (4.16.5) and there is no "nobody" share on it. > > So I think this is OpenBSD specific. If I understand smb.conf(5) correctly this is the intended behaviour, which is not specific for OpenBSD. Googling your description seems to confirm this. I can not comment on the behaviour of fedora. [0] https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#GUESTACCOUNT
pf.conf / scrub resulting in invalid checksum
I'm using mcast-proxy from ports as multicast routing proxy for use with my ISP's iptv platform. After some setting up i noticed from mcast-proxy's logging that all incoming packets are dropped because of IP invalid checksums [0]. At first I believed this was the result of hardware checksum offloading. However, after some more digging I found that my pf.conf was to blame, specifically: match inet scrub (max-mss 1460, no-df, random-id) Removing `no-df` and `random-id` as argument causes mcast-proxy to accept all incoming IGMP packets resulting in a working solution. After grepping sys/net/pf* i think that pf_test() calls pf_scrub(), which changes the fragment offset field and/or the identification field thus changing the packet header. However, it seems that the checksum of a changed packet is not updated. Can anyone shed a light on the above? [0] https://github.com/Esdenera/mcast-proxy/blob/master/usr.sbin/mcast-proxy/mcast-proxy.c#L539-L549
Re: Unison on 6.6 - compatibility
On Mon 11/11/2019 14:31, Steven Surdock wrote: > I just fired up a 6.6/amd64 host that I will use to replace an existing > 6.5/amd64 remote fileserver. I've been using Unison to synch files between > this remote server and a Windows fileserver. It seems with the bump to OCAML > 4.09 Unison is throwing an error, "input_value: ill-formed message", when > trying to sync the hosts. From my reading, this is the result of OCAML > version mismatches. I've tried various combinations of Unison on both ends > to no avail. The latest Windows binary I have is compiled with OCAML 4.0.7. > It seems my options are, > > + Keep the host at 6.5 (until Unison Window's binaries catch up.) > + Compile Unison on Windows with a compatible OCAML. > + Build Unison on 6.6 with a lower OCAML version (4.07 seems to work.) > > Any advice would be appreciated. Ports related questions belong on ports@. That said: $ cat /usr/local/share/doc/pkg-readmes/unison $OpenBSD: README,v 1.4 2019/09/22 18:29:54 chrisz Exp $ +--- | Running unison on OpenBSD +--- Unison uses native OCaml marshalling in its prococol. This means that unison might not work when the OCaml versions of two instances are out of sync. One way to work around this limitation of unison is to use the OPAM OCaml package manager to build unison with the same version of the OCaml compiler on all machines: doas pkg_add opam OPAMROOT=~/opam_unison opam init --no-setup --compiler ocaml-base-compiler.4.09.0 opam install unison lablgtk # To build without the gui, remove lablgtk $(opam var bin)/unison
Re: package request
On Wed 16/05/2018 08:58, Mayuresh Kathe wrote: > is there a process to adhere to while requesting creation of a new package? Making a port is not difficult. You could start with https://www.openbsd.org/faq/ports/ and discuss your work on po...@openbsd.org, which is a different mailing list (https://www.openbsd.org/mail.html).
Re: USB 3.0 and i/o error 5 @ CRYPTO block
On Sat 29/07/2017 17:42, Tinker wrote:
> Bjorn,
>
> mpi@ and others would love to get a copy of your system's XHCI stack's debug
> output.
>
> Can you please enable XHCI_DEBUG in your kernel and post the output.
>
> Also please see some further notes here
> https://marc.info/?l=openbsd-misc&m=149658807922576&w=2 and here
> https://marc.info/?l=openbsd-misc&m=149641168519652&w=2 .
>
> You, me and some other people need to document what works and not and submit
> the logs.
>
> Please share the debug log reports and also what steps you took to produce
> them!
Output from a kernel compiled with XHCI_DEBUG is enclosed below. Steps to
reproduce (using an encrypted, external USB drive, that tests OK on USB2):
1.) Power-on system with external drive connected to USB 3.0 port;
2.) bioctl -c C -l ${_device} softraid0
3.) mount ${_device} /mnt
4.) rsync -av ${_files} /mnt/.
After step 4 a couple of files are copied and the process halts. As stated in
my previous mail the system is still responsive however umounting of the drive
is not possible, and a hard reset is required.
Output from XHCI_DEBUG
xhci0 at pci5 dev 0 function 0 "Renesas uPD720201 xHCI" rev 0x03: msi
xhci0: xHCI version 1.0
xhci0: CAPLENGTH=0x20
xhci0: DOORBELL=0x800
xhci0: RUNTIME=0x600
xhci0: 64 bytes context
xhci0: supported page size 0x0001
xhci0: 6 ports and 32 slots
xhci0: 4 scratch pages
usb1 at xhci0: USB revision 3.0
xhci0: DCBAAP=00x97a
xhci0: CRCR=00 (097a1000)
xhci0: ERSTBA=00xf1dc9000
xhci0: ERDP=00x97a2000
xhci0: USBCMD=0x5
xhci0: IMAN=0x2
xhci0: port=2 change=0x04
xhci0: port=2 change=0x04
xhci0: xhci_cmd_slot_control
xhci0: dev 1, input=0xff00097c slot=0xff00097c0040
ep0=0xff00097c0080
xhci0: dev 1, setting DCBAA to 0x097c1000
xhci0: xhci_cmd_set_address BSR=1
xhci0: xhci_cmd_set_address BSR=0
xhci0: dev 1 addr 1
xhci0: xhci_cmd_configure_ep dev 1
xhci0: xhci_cmd_configure_ep dev 1
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_reset_ep_async dev 1 dci 3
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 3
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a1080 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a10a0 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a10c0 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a10e0 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a1010 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a1030 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a1050 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a1070 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a1090 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097a10b0 0x1300 0x1008401)
xhci0: error stopping endpoint
xhci0: xhci_cmd_set_tr_deq_async dev 1 dci 4
xhci0: xhci_cmd_stop_ep dev 1 dci 4
xhci0: event error code=19, result=33 trb=0x800022185e80
(0x097
USB 3.0 and i/o error 5 @ CRYPTO block
I tried using a 2.5"-drive in an USB3.0 enclosure hooked up to an USB 3.0 port on a machine running OpenBSD current, dmesg enclosed below. The drive has been encrypted using softraid. When rsyncing files to the encrypted filesystem the copying is halted, but the system is still responsive. A quick check of /var/log/message showed: Jul 29 13:46:22 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248926416 Jul 29 13:47:27 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248926480 Jul 29 13:48:33 gateway /bsd: softraid0: sd6: i/o error 5 @ CRYPTO block 248780616 ... In this state it is not possible to umount the filesystem or remove the device from softraid using bioctl. Workaround to umount the filesystem is a hard reset. My first thought was that the drive itself was broken. A fsck gave the same I/O errors. Now the strange part: When I attach the external drive to a USB 2 port, everything works as expected. No errors, and fsck finds no issues. In this configuration the external, encrypted drive is reliable. It seems that my issue is related to the USB 3.0 port of my machine. Are there any known issues with USB 3.0 and FDE using softraid? Any ideas to rule out a hardware issue? -- Björn Ketelaars GPG key: 0x4F0E5F21 OpenBSD 6.1-current (GENERIC.MP) #16: Fri Jul 28 21:09:01 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4242419712 (4045MB) avail mem = 4107489280 (3917MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xf3bdb000 (64 entries) bios0: vendor HP version "J06" date 11/09/2013 bios0: HP ProLiant MicroServer Gen8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PCI0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2295.09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2295091360 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2294.80 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 13 (IPT1) acpiprt1 at acpi0: bus -1 (IPT2) acpiprt2 at acpi0: bus -1 (IPT3) acpiprt3 at acpi0: bus -1 (IPT4) acpiprt4 at acpi0: bus 3 (IPT5) acpiprt5 at acpi0: bus -1 (IPT6) acpiprt6 at acpi0: bus 4 (IPT7) acpiprt7 at acpi0: bus 1 (IPT8) acpiprt8 at acpi0: bus 7 (PT02) acpiprt9 at acpi0: bus -1 (PT03) acpiprt10 at acpi0: bus 2 (PT05) acpiprt11 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu1 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpitz0 at acpi0: critical temperature is 31 degC "IPI0001" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0303" at acpi0 not configured "PNP0F13" at acpi0 not configured "ACPI000D" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci1 at ppb0 bus 7 ppb1 at pci0 dev 6 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci2 at ppb1 bus 2 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 8 int 21 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5 pci3 at ppb2 bus 13 ppb3 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5 pci4 at ppb3 bus 3 bge0 at pci4 dev 0 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.2.46.0: msi, address d0:bf:9c:46:de:14 brgphy0 at bge0 phy 1: BCM5720C 10/100/1000baseT PHY, rev. 0 bge1 at pci4 dev 0 function 1 "Broadcom BCM5720&qu
Re: re0 and re1 watchdog timeouts, and system freeze
On Mon 12/06/2017 15:11, David Gwynne wrote:
> On Fri, Jun 09, 2017 at 07:19:34PM +0200, Bj??rn Ketelaars wrote:
> > On Fri 09/06/2017 12:07, Martin Pieuchot wrote:
> > > On 08/06/17(Thu) 20:38, Bj??rn Ketelaars wrote:
> > > > On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> > > > > On 07/06/17(Wed) 09:43, Bj??rn Ketelaars wrote:
> > > > > > On Sat 03/06/2017 08:44, Bj??rn Ketelaars wrote:
> > > > > > >
> > > > > > > Reverting back to the previous kernel fixed the issue above.
> > > > > > > Question: can
> > > > > > > someone give a hint on how to track this issue?
> > > > > >
> > > > > > After a bit of experimenting I'm able to reproduce the problem.
> > > > > > Summary is
> > > > > > that queueing in pf and use of a current (after May 30), multi
> > > > > > processor
> > > > > > kernel (bsd.mp from snapshots) causes these specific watchdog
> > > > > > timeouts
> > > > > > followed by a system freeze.
> > > > > >
> > > > > > Issue is 'gone' when:
> > > > > > 1.) using an older kernel (before May 30);
> > > > > > 2.) removal of queueing statements from pf.conf. Included below the
> > > > > > specific
> > > > > > snippet;
> > > > > > 3.) switch from MP kernel to SP kernel.
> > > > > >
> > > > > > New observation is that while queueing, using a MP kernel, the
> > > > > > download
> > > > > > bandwidth is only a fraction of what is expected. Exchanging the MP
> > > > > > kernel
> > > > > > with a SP kernel restores the download bandwidth to expected level.
> > > > > >
> > > > > > I'm guessing that this issue is related to recent work on PF?
> > > > >
> > > > > It's certainly a problem in, or exposed by, re(4) with the recent MP
> > > > > work
> > > > > in the network stack.
> > > > >
> > > > > It would help if you could build a kernel with MP_LOCKDEBUG defined
> > > > > and
> > > > > see if the resulting kernel enters ddb(4) instead of freezing.
> > > > >
> > > > > Thanks,
> > > > > Martin
> > > >
> > > > Thanks for the hint! It helped in entering ddb. I collected a bit of
> > > > output,
> > > > which you can find below. If I read the trace correctly the crash is
> > > > related
> > > > to line 1750 of sys/dev/ic/re.c:
> > > >
> > > > d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);
> > >
> > > Could you test the diff below, always with a MP_LOCKDEBUG kernel and
> > > tell us if you can reproduce the freeze or if the kernel enters ddb(4)?
> > >
> > > Another question, how often do you see "watchdog timeout" messages?
> > >
> > > Index: re.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/ic/re.c,v
> > > retrieving revision 1.201
> > > diff -u -p -r1.201 re.c
> > > --- re.c 24 Jan 2017 03:57:34 - 1.201
> > > +++ re.c 9 Jun 2017 10:04:43 -
> > > @@ -2074,9 +2074,6 @@ re_watchdog(struct ifnet *ifp)
> > > s = splnet();
> > > printf("%s: watchdog timeout\n", sc->sc_dev.dv_xname);
> > >
> > > - re_txeof(sc);
> > > - re_rxeof(sc);
> > > -
> > > re_init(ifp);
> > >
> > > splx(s);
> >
> > The diff (with a MP_LOCKDEBUG kernel) resulted in similar traces as before.
> > ddb Output is included below.
> >
> > With your diff the number of timeout messages decreased from 9 to 2 before
> > entering ddb.
>
> can you try the diff below please?
>
> Index: hfsc.c
> ===
> RCS file: /cvs/src/sys/net/hfsc.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 hfsc.c
> --- hfsc.c8 May 2017 11:30:53 - 1.39
> +++ hfsc.c12 Jun 2017 05:08:01 -
> @@ -817,7 +817,7 @@ hfsc_deferred(void *arg)
> KASSERT(HFSC_ENABLED(ifq));
>
> if (!ifq_empty(ifq))
> - (*ifp->if_qstart)(ifq);
> + ifq_start(ifq);
>
> hif = ifq->ifq_q;
Your diff fixes my issue.
Previously I was able to reproduce the problem within a minute. I have been
running a kernel with your patch for the last three hours without a hitch. No
more re0/re1 watchdog timeouts, no more bandwidth issues while using queueing
and no more ddb.
Thanks!
Re: re0 and re1 watchdog timeouts, and system freeze
On Fri 09/06/2017 12:07, Martin Pieuchot wrote:
> On 08/06/17(Thu) 20:38, Björn Ketelaars wrote:
> > On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> > > On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> > > > On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > > > >
> > > > > Reverting back to the previous kernel fixed the issue above.
> > > > > Question: can
> > > > > someone give a hint on how to track this issue?
> > > >
> > > > After a bit of experimenting I'm able to reproduce the problem. Summary
> > > > is
> > > > that queueing in pf and use of a current (after May 30), multi processor
> > > > kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> > > > followed by a system freeze.
> > > >
> > > > Issue is 'gone' when:
> > > > 1.) using an older kernel (before May 30);
> > > > 2.) removal of queueing statements from pf.conf. Included below the
> > > > specific
> > > > snippet;
> > > > 3.) switch from MP kernel to SP kernel.
> > > >
> > > > New observation is that while queueing, using a MP kernel, the download
> > > > bandwidth is only a fraction of what is expected. Exchanging the MP
> > > > kernel
> > > > with a SP kernel restores the download bandwidth to expected level.
> > > >
> > > > I'm guessing that this issue is related to recent work on PF?
> > >
> > > It's certainly a problem in, or exposed by, re(4) with the recent MP work
> > > in the network stack.
> > >
> > > It would help if you could build a kernel with MP_LOCKDEBUG defined and
> > > see if the resulting kernel enters ddb(4) instead of freezing.
> > >
> > > Thanks,
> > > Martin
> >
> > Thanks for the hint! It helped in entering ddb. I collected a bit of output,
> > which you can find below. If I read the trace correctly the crash is related
> > to line 1750 of sys/dev/ic/re.c:
> >
> > d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);
>
> Could you test the diff below, always with a MP_LOCKDEBUG kernel and
> tell us if you can reproduce the freeze or if the kernel enters ddb(4)?
>
> Another question, how often do you see "watchdog timeout" messages?
>
> Index: re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.201
> diff -u -p -r1.201 re.c
> --- re.c 24 Jan 2017 03:57:34 - 1.201
> +++ re.c 9 Jun 2017 10:04:43 -
> @@ -2074,9 +2074,6 @@ re_watchdog(struct ifnet *ifp)
> s = splnet();
> printf("%s: watchdog timeout\n", sc->sc_dev.dv_xname);
>
> - re_txeof(sc);
> - re_rxeof(sc);
> -
> re_init(ifp);
>
> splx(s);
The diff (with a MP_LOCKDEBUG kernel) resulted in similar traces as before.
ddb Output is included below.
With your diff the number of timeout messages decreased from 9 to 2 before
entering ddb.
ddb{1}> show panic
the kernel did not panic
ddb{1}> machine ddbcpu 0
Stopped at db_enter+0x9: leave
ddb{0}> trace
db_enter(8196b640,200,804d1600,10,8000220e9938,282) at db_e
nter+0x9
x86_ipi_handler(80074010,819e7160,102860,c,4,1813a9522) at x86_
ipi_handler+0x85
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
___mp_lock(819e7160,8187acf0,1,1,8000220a38c0,8000220a7
ab0) at ___mp_lock+0x4a
___mp_acquire_count(819e7160,1,8000220a38c0,8000220a7ab0,ff
011da1e1c8,81019942) at ___mp_acquire_count+0x33
mi_switch(ff011b4a93c0,818bf7e7,9cd,8000220e9bb0,8000220a7a
b0,8000220e9ba0) at mi_switch+0x22b
sleep_finish(8000220e9bb0,1,118,8000220e9bb0,ff011b4a93c0,8
18bf7e7) at sleep_finish+0xc2
tsleep(ff011b4a93c0,118,818bf7e7,9cd,0,40) at tsleep+0x164
kqueue_scan(ff011b4a93c0,40,143d48714800,8000220e9dd0,8000220a7ab0,
8000220e9de4) at kqueue_scan+0x15b
sys_kevent(8000220a7ab0,8000220e9e60,8000220e9eb0,8000220a7ab0,
48,1) at sys_kevent+0x2f6
syscall() at syscall+0x29f
--- syscall (number 72) ---
end of kernel
end trace frame: 0x143d48714800, count: -11
0x143c524f280a:
ddb{0}> machine ddbcpu 1
Stopped at re_encap+0x24d: movl0(%r15),%eax
ddb{1}> trace
re_encap(80084000,dd,ff00d6e03f00,800842c0,400,8008
4000) at re_encap+0x24d
re_start(800842c0,7,ff00d6dd7200,80084338,800842c0,
81091d70) at re_start+0x8c
ifq_serialize(80084
Re: re0 and re1 watchdog timeouts, and system freeze
On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> > On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > >
> > > Reverting back to the previous kernel fixed the issue above. Question: can
> > > someone give a hint on how to track this issue?
> >
> > After a bit of experimenting I'm able to reproduce the problem. Summary is
> > that queueing in pf and use of a current (after May 30), multi processor
> > kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> > followed by a system freeze.
> >
> > Issue is 'gone' when:
> > 1.) using an older kernel (before May 30);
> > 2.) removal of queueing statements from pf.conf. Included below the specific
> > snippet;
> > 3.) switch from MP kernel to SP kernel.
> >
> > New observation is that while queueing, using a MP kernel, the download
> > bandwidth is only a fraction of what is expected. Exchanging the MP kernel
> > with a SP kernel restores the download bandwidth to expected level.
> >
> > I'm guessing that this issue is related to recent work on PF?
>
> It's certainly a problem in, or exposed by, re(4) with the recent MP work
> in the network stack.
>
> It would help if you could build a kernel with MP_LOCKDEBUG defined and
> see if the resulting kernel enters ddb(4) instead of freezing.
>
> Thanks,
> Martin
Thanks for the hint! It helped in entering ddb. I collected a bit of output,
which you can find below. If I read the trace correctly the crash is related
to line 1750 of sys/dev/ic/re.c:
d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
db_enter(8196acc0,80002200b8b8,8000e6a8,10,800022023c58
,282) at db_enter+0x9
x86_ipi_handler(8196acd0,819f26a0,14a2d1,c,800022023cd0,fff
f819f95a0) at x86_ipi_handler+0x85
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
___mp_lock(819f26a0,818552f0,1,1,80002200b8b8,8000e
6a8) at ___mp_lock+0x4a
___mp_acquire_count(819f26a0,1,80002200b8b8,8000e6a8,ff
ff81a11680,81707182) at ___mp_acquire_count+0x33
mi_switch(0,0,8000e6a8,800022023ed0,8000e6a8,800022023e
c0) at mi_switch+0x22b
sleep_finish(800022023ed0,1,810b7110,800022023ed0,0,0) at sleep
_finish+0xc2
softclock_thread(8000e6a8,2a2,0,0,29e123d3cabb9a12,800022023f10) at
softclock_thread+0x94
end trace frame: 0x0, count: -8
ddb{0}> machine ddbcpu 1
Stopped at re_encap+0x24d: movl0(%r15),%eax
ddb{1}> show panic
the kernel did not panic
ddb{1}> trace
re_encap(80084000,363,ff00d221cc00,800842c0,400,800
84000) at re_encap+0x24d
re_start(800842c0,7,ff00d171d000,80084338,800842c0,
815fdbf0) at re_start+0x8c
ifq_serialize(800842c0,80084360,80084090,ff00d2fbd0
00,800842c0,0) at ifq_serialize+0xf8
if_enqueue(80084090,ff00d2fbd000,8096a240,ff00d2fbd000,
37,2) at if_enqueue+0x90
ether_output(80084090,ff00d171d000,8096a240,ff011b66777
8,804d1000,8096a240) at ether_output+0x1d6
ip_output(ff00d171d000,0,800022032cc0,1,0,0) at ip_output+0x8a1
ip_forward(ff00d171d000,802a4090,0,0,8244c78a,8244c78a) at ip_forwa
rd+0x1e7
ipv4_input(802a4090,ff00d171d000,800,800,ff000990ff80,8
02a4090) at ipv4_input+0x4f7
ether_input(802a4090,ff00d171d000,0,810afed0,802a42
88,802a4090) at ether_input+0xbd
if_input_process(2,800022032eb0,0,0,800022032eb0,80019080) at i
f_input_process+0xfa
taskq_thread(80019080,2a2,80019080,81493240,0,80002
2032f10) at taskq_thread+0x79
end trace frame: 0x0, count: -11
ddb{1}> dmesg
OpenBSD 6.1-current (GENERIC.MP) #7: Thu Jun 8 19:10:36 CEST 2017
b...@gateway.lan:/home/code/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4245995520 (4049MB)
avail mem = 4111519744 (3921MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (6 entries)
bios0: vendor coreboot version "SageBios_PCEngines_APU-45" date 04/05/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE2
0(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) U
OH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (bo
Re: re0 and re1 watchdog timeouts, and system freeze
On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
>
> Reverting back to the previous kernel fixed the issue above. Question: can
> someone give a hint on how to track this issue?
After a bit of experimenting I'm able to reproduce the problem. Summary is
that queueing in pf and use of a current (after May 30), multi processor
kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
followed by a system freeze.
Issue is 'gone' when:
1.) using an older kernel (before May 30);
2.) removal of queueing statements from pf.conf. Included below the specific
snippet;
3.) switch from MP kernel to SP kernel.
New observation is that while queueing, using a MP kernel, the download
bandwidth is only a fraction of what is expected. Exchanging the MP kernel
with a SP kernel restores the download bandwidth to expected level.
I'm guessing that this issue is related to recent work on PF?
--- SNIP ---
# queueing
#
queue up on re0 bandwidth 15M max 15M
queue up_def parent up bandwidth 1M qlimit 10 default
queue up_dns parent up bandwidth 2M qlimit 20
queue up_ssh parent up bandwidth 6M qlimit 50
queue up_web parent up bandwidth 6M qlimit 50
match on egress set queue up_def
match out on egress proto {tcp, udp} to port 1:1024 set queue up_web
match on egress proto tcp to port 22 set queue up_ssh
match out on egress proto {tcp, udp} to port 53 set queue up_dns
match on egress proto icmp set queue up_dns
match out on egress proto tcp to port {119, 563} set queue up_def
queue down on re1 bandwidth 150M max 150M
queue down_def parent down bandwidth 10M qlimit 100 default
queue down_dns parent down bandwidth 20M qlimit 200
queue down_ssh parent down bandwidth 60M qlimit 500
queue down_web parent down bandwidth 60M qlimit 500
match on re1 set queue down_def
match in on re1 proto {tcp, udp} to port 1:1024 set queue down_web
match on re1 proto tcp to port 22 set queue down_ssh
match in on re1 proto {tcp, udp} to port 53 set queue down_dns
match on re1 proto icmp set queue down_dns
match in on re1 proto tcp to port {119, 563} set queue down_def
--- SNIP ---
--
Björn Ketelaars
GPG key: 0x4F0E5F21
re0 and re1 watchdog timeouts, and system freeze
naa.5002538043584d30 sd0: 30533MB, 512 bytes/sector, 62533296 sectors, thin ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling iic0 at piixpm0 pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x40 ppb3 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40 pci4 at ppb3 bus 4 ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ppb4 at pci0 dev 21 function 0 "ATI SB800 PCIE" rev 0x00 pci5 at ppb4 bus 5 ohci3 at pci0 dev 22 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, version 1.0, legacy support ehci2 at pci0 dev 22 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 usb2 at ehci2: USB revision 2.0 uhub2 at usb2 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 pchb1 at pci0 dev 24 function 0 "AMD AMD64 14h Link Cfg" rev 0x43 pchb2 at pci0 dev 24 function 1 "AMD AMD64 14h Address Map" rev 0x00 pchb3 at pci0 dev 24 function 2 "AMD AMD64 14h DRAM Cfg" rev 0x00 km0 at pci0 dev 24 function 3 "AMD AMD64 14h Misc Cfg" rev 0x00 pchb4 at pci0 dev 24 function 4 "AMD AMD64 14h CPU Power" rev 0x00 pchb5 at pci0 dev 24 function 5 "AMD AMD64 14h Reserved" rev 0x00 pchb6 at pci0 dev 24 function 6 "AMD AMD64 14h NB Power" rev 0x00 pchb7 at pci0 dev 24 function 7 "AMD AMD64 14h Reserved" rev 0x00 usb3 at ohci0: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "ATI OHCI root hub" rev 1.00/1.00 addr 1 usb4 at ohci1: USB revision 1.0 uhub4 at usb4 configuration 1 interface 0 "ATI OHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x52 usb5 at ohci2: USB revision 1.0 uhub5 at usb5 configuration 1 interface 0 "ATI OHCI root hub" rev 1.00/1.00 addr 1 usb6 at ohci3: USB revision 1.0 uhub6 at usb6 configuration 1 interface 0 "ATI OHCI root hub" rev 1.00/1.00 addr 1 vmm0 at mainbus0: SVM/RVI umass0 at uhub2 port 1 configuration 1 interface 0 "Generic Flash Card Reader/Writer" rev 2.01/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets, initiator 0 sd1 at scsibus2 targ 1 lun 0: SCSI2 0/direct removable serial.058f6366058F63666485 sd1: 7600MB, 512 bytes/sector, 15564800 sectors vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (28fcdc10008babff.a) swap on sd0b dump on sd0b WARNING: / was not properly unmounted re1: watchdog timeout re0: watchdog timeout re1: watchdog timeout re1: watchdog timeout re1: watchdog timeout re1: watchdog timeout re1: watchdog timeout re0: watchdog timeout re1: watchdog timeout -- Björn Ketelaars GPG key: 0x4F0E5F21
Re: kernel panic - panic: ehci_device_clear_toggle: queue active
On Thu 03/12/2015 09:54, Martin Pieuchot wrote: > On 30/11/15(Mon) 18:28, Björn Ketelaars wrote: > > Hello, > > > > I repeatedly hit the kernel panic below. Easy to reproduce as it happens > > over > > and over again within 60 minutes after rebooting. Root cause is not known. > > > > I'm running snapshot on an USB stick. I tried different USB ports with the > > same > > result. Next step will be an attempt with a different USB stick. > > > > I think this issue has been mentioned before: > > > > https://marc.info/?t=14184059141&r=1&w=3 > > http://openbsd-archive.7691.n7.nabble.com/panic-ehci-device-clear-toggle-queue-active-td231729.html > > http://article.gmane.org/gmane.os.openbsd.bugs/19812/ > > > > Any ideas on how to tackle this issue? > > You can try the diff below and tell me if it helps. > > Index: ehci.c > === > RCS file: /cvs/src/sys/dev/usb/ehci.c,v > retrieving revision 1.187 > diff -u -p -r1.187 ehci.c > --- ehci.c26 Jun 2015 11:17:34 - 1.187 > +++ ehci.c14 Oct 2015 14:24:19 - > Yes, it helps! I build and installed a new kernel using your diff and tested it with a couple of USB-sticks on different USB-ports. No panics... Reverting to an old (unpatched) kernel, using the above routine, soon resulted in a hang. I'm currently running a kernel with your diff. As stated: it helps. Thanks!
kernel panic - panic: ehci_device_clear_toggle: queue active
Hello, I repeatedly hit the kernel panic below. Easy to reproduce as it happens over and over again within 60 minutes after rebooting. Root cause is not known. I'm running snapshot on an USB stick. I tried different USB ports with the same result. Next step will be an attempt with a different USB stick. I think this issue has been mentioned before: https://marc.info/?t=14184059141&r=1&w=3 http://openbsd-archive.7691.n7.nabble.com/panic-ehci-device-clear-toggle-queue-active-td231729.html http://article.gmane.org/gmane.os.openbsd.bugs/19812/ Any ideas on how to tackle this issue? -- Björn Ketelaars GPG key: 0x4F0E5F21 OpenBSD 5.8-current (GENERIC.MP) #0: Mon Nov 30 08:22:20 CET 2015 r...@gateway.lan:/storage/8899fc1454db04de.a/home/code/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4242419712 (4045MB) avail mem = 4109725696 (3919MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xf3bdb000 (64 entries) bios0: vendor HP version "J06" date 11/09/2013 bios0: HP ProLiant MicroServer Gen8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PCI0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2295.13 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz, 2294.79 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpiprt0 at acpi0: bus 13 (IPT1) acpiprt1 at acpi0: bus -1 (IPT2) acpiprt2 at acpi0: bus -1 (IPT3) acpiprt3 at acpi0: bus -1 (IPT4) acpiprt4 at acpi0: bus 3 (IPT5) acpiprt5 at acpi0: bus -1 (IPT6) acpiprt6 at acpi0: bus 4 (IPT7) acpiprt7 at acpi0: bus 1 (IPT8) acpiprt8 at acpi0: bus 7 (PT02) acpiprt9 at acpi0: bus -1 (PT03) acpiprt10 at acpi0: bus 2 (PT05) acpiprt11 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu1 at acpi0: C2(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpitz0 at acpi0: critical temperature is 31 degC ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci1 at ppb0 bus 7 ppb1 at pci0 dev 6 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci2 at ppb1 bus 2 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 8 int 21 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5 pci3 at ppb2 bus 13 ppb3 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5 pci4 at ppb3 bus 3 bge0 at pci4 dev 0 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.2.46.0: msi, address d0:bf:9c:46:de:14 brgphy0 at bge0 phy 1: BCM5720C 10/100/1000baseT PHY, rev. 0 bge1 at pci4 dev 0 function 1 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.2.46.0: msi, address d0:bf:9c:46:de:15 brgphy1 at bge1 phy 2: BCM5720C 10/100/1000baseT PHY, rev. 0 ppb4 at pci0 dev 28 function 6 "Intel 6 Series PCIE" rev 0xb5 pci5 at ppb4 bus 4 xhci0 at pci5 dev 0 function 0 "Renesas uPD720201 xHCI" rev 0x03: msi usb1 at xhci0: USB revision 3.0 uhub1 at usb1 "Renesas xHCI root hub" rev 3.00/1.00 addr 1 ppb5 at pci0 dev 28 function 7 "Intel 6 Series PCIE" rev 0xb5 pci6 at ppb5 bus 1 "Hewlett-Packard iLO3 Slave" rev 0x05 at pci6 dev 0 function 0 not configured vga1 at pci6 dev 0 function 1 "Matrox MGA G200eH" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) "Hewlett-Packard iLO3 Management"
Re: AMD64 packages
you could try http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ On Thu, Dec 11, 2014 at 11:59 AM, FRIGN wrote: > On Wed, 10 Dec 2014 21:27:46 -0500 > "STeve Andre'" wrote: > > > You might want to subscribe to the ports-changes changes list, > > which will show you what's been changed. The source-changes > > list will show you all the other cvs commits. Look at > > > > http://www.openbsd.org/mail.html > > Btw, now that the topic has come up. Is there a way to view the > diffs quickly on a source- or port-change? > Just reading the titles is not very helpful and I also don't feel > like pulling the entire OpenBSD CVS-tree just to view the recent > code-changes. > > I'm subscribed to numerous mailing lists, and all of them provide > diff-data in the mail itself. I'm sure more people would subscribe > to such a list if it actually encouraged to read and check the > source. > > Cheers > > FRIGN > > -- > FRIGN > > -- Björn Ketelaars GPG key: 0x4F0E5F21
Panic - sensor installed twice
I just installed a new snapshot and gave the system a reboot. Unfortunately the kernel panicked with an interesting message: "sensor installed twice". I guess this panic is intended because of a commit (1.31) to src/sys/kern/kern_sensors.c a couple of days ago. A trace, etc. is included below. I tend to believe that this panic has something to do with lm as disabling this device solves the issue described. Dmesg show something interesting: lm2 at wbsio0 port 0xca0/8: W83627DHG lm1: disabling sensors due to alias with lm2 I have no idea what this means. Perhaps registration of lm1 and lm2 counts as a double install of a sensor? Any ideas how to solve this issue without disabling lm? -- Björn Ketelaars GPG key: 0x4F0E5F21 Loading. probing: pc0 com0 com1 mem[613K 2037M a20=on] >> OpenBSD/amd64 BOOT 3.28 booting hd0a:/bsd: 6659808+2126028+247720+0+592960 [72+553368+368348]=0xa10f80 entry point at 0x1000160 [7205c766, 3404, 24448b12, 8fe0a304] [ using 922432 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 Auto-DetThe Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org S.M.A.R.T. Capable and Status OK OpenBSD 5.6-current (GENERIC.MP) #544: Fri Nov 7 10:36:24 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2120744960 (2022MB) avail mem = 2060541952 (1965MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries) bios0: vendor American Megatrends Inc. version "1.2a" date 02/21/12 bios0: Supermicro X7SPA-H acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI EINJ BERT ERST HEST acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.88 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-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 cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 1, remapped to apid 4 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P1) acpiprt2 at acpi0: bus 1 (P0P4) acpiprt3 at acpi0: bus 2 (P0P8) acpiprt4 at acpi0: bus 3 (P0P9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 Skipping LVDS initialization for Supermicro X7SPA-H No connectors reported connected with modes Cannot find any crtc or sizes - going 1024x768 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 uhci1 at pci0 dev 26 funct
[LibreSSL] unable to encrypt file
I'm trying to encrypt a file using openssl and a prompted password on OpenBSD. Unfortunately there is no prompt and all I get is a 'bad password read': $ openssl version LibreSSL 2.0 $ openssl des3 -in file bad password read Attempting the same on a different *non OpenBSD* system and a plain-vanilla openssl install: $ openssl versio OpenSSL 1.0.1i 6 Aug 2014 $ openssl des3 -in file enter des-ede3-cbc encryption password: Verifying - enter des-ede3-cbc encryption password: ... Is this expected behaviour of LibreSSL? -- Björn Ketelaars GPG key: 0x4F0E5F21 OpenBSD 5.6-beta (GENERIC.MP) #304: Fri Jul 25 12:02:01 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2120744960 (2022MB) avail mem = 2055561216 (1960MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries) bios0: vendor American Megatrends Inc. version "1.2a" date 02/21/12 bios0: Supermicro X7SPA-H acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI EINJ BERT ERST HEST acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.89 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-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.1.0.0.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.66 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 1, remapped to apid 4 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P1) acpiprt2 at acpi0: bus 1 (P0P4) acpiprt3 at acpi0: bus 2 (P0P8) acpiprt4 at acpi0: bus 3 (P0P9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 Skipping LVDS initialization for Supermicro X7SPA-H No connectors reported connected with modes Cannot find any crtc or sizes - going 1024x768 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 19 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:25:90:04:70:74 ppb2 at pci0 dev 28 function
Re: Multiple, simultaneous interfaces using dhclient
It sounds like that your default inet route is overwritten after dhclient on
vlan1 is issued. Did you have a look at the route table before and after each
call of dhclient?
> On 13 Jul 2014, at 02:49, Rogier Krieger wrote:
>
> Dear list,
>
> as my ISP is migrating to a new network setup, I'm forced to tinker with my
> local setup. Unfortunately, I'm struggling to get two interfaces (vlan0,
> vlan1) working simultaneously with DHCP.
>
> Separately, they work fine. Together, vlan1 drops my internet connection
> (vlan0); the latter won't return until I manually re-issue dhclient vlan0.
> Upon lease renewal, the same occurs, lest I kill the dhclient instance for
> vlan1.
>
> I wonder if I'm doing something silly. Is the having two simultaneous
> dhclient instances a supported setup? The second instance is for an IPTV
> set-top-box (STB) that I'd like to keep away from my regular LAN, hence the
> routing domains.
>
> I've disabled PF while trying to get this working, so as to minimise the
> amount of things I can do wrong.
>
> Does anyone have a cluebat for me? Insight greatly appreciated.
>
> Regards,
>
>
>
> Background:
> It's a FttH link that provides two tagged networks (vlan 34 for IP; vlan 4
> for IPTV). The latter provides an private range address (in 10.10.12.0/22)
> for a set-top-box.
>
> For the STB:
> - IPTV Traffic is to be NATed to vlan4 (towards the 10.10.12.0/22 and
> 185.6.48.0/26 ranges)
> - Other/Internet traffic (e.g. program guides) needs to travel via the
> regular IP uplink (vlan 34) and should be NATed there
>
>
>
> # cat /etc/dhclient.conf
> supersede host-name "fluor";
> prepend domain-name-servers "27.0.0.1;
>
> interface "vlan1" {
>#ignore routers;# vlan1 is in rdomain 1; default route won't hurt us
> }
>
>
> # cat /etc/hostname.em0
> description "internal"
> -inet6
> up
>
> # cat /etc/hostname.em1
> description "uplink"
> -inet6
> up
>
> # cat /etc/hostname.vlan0
> description "ip (uplink)"
> vlan 34 vlandev em1
> dhcp
> -inet6
>
> # cat /etc/hostname.vlan1
> description "tv (uplink)"
> rdomain 1
> group tv
> vlan 4 vlandev em1
> dhcp
> -inet6
>
> # cat /etc/hostname.vlan52
> description "tv (downlink)
> rdomain 1
> group tv
> vlan 52 vlandev em0
> inet 10.0.52.1/24
> -inet6
>
>
>
>
> --
> If you don't know where you're going, any road will get you there.
relayd CA engine failed
I'm attempting a SSL accelerator using relayd on current using the following
config:
# cat /etc/relayd.conf
prefork 1
relay wwwssl {
listen on 48.42.218.18 port 443 ssl
forward to 10.0.0.11 port http
}
Unfortunately relayd exits complaining about "CA engine failed: No such file or
directory":
# relayd -dvv
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
relay_load_certfiles: using certificate /etc/ssl/48.42.218.18.crt
relay_load_certfiles: using private key /etc/ssl/private/48.42.218.18.key
relay_privinit: adding relay wwwssl
protocol -1: name default
flags: used, relay flags: ssl
ssl flags: sslv3, tlsv1
type: tcp
fatal: CA engine failed: No such file or directory
ca exiting, pid 24561
fatal: parent: Broken pipe
fatal: CA engine failed: No such file or directory
hce exiting, pid 25463
I have no idea about what file or directory is missing. Any suggestions maybe?
# dmesg
OpenBSD 5.5-current (GENERIC) #68: Thu May 1 06:43:26 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 536375296 (511MB)
avail mem = 515190784 (491MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:00:24:cb:aa:38
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
00:00:24:cb:aa:39
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address
00:00:24:cb:aa:3a
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address
00:00:24:cb:aa:3b
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0,
legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
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
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (4cbdfbe18ce5a24a.a) swap on wd0b dump on wd0b
ndp info overwritten for fe80:2::e2f8:47ff:fe41:aa20 by e0:f8:47:41:aa:20 on vr1
--
Björn Ketelaars
GPG key: 0x4F0E5F21
Re: Unbound in base (review)
2012/3/26 Jakob Schlyter :
> Any more feedback on this? We need more testing to proceed!
Unbound has been imported to work on in-tree (not yet linked to the
build) [1]. It compiles and functions on amd64 and i386. I can only
guess who is actually working on further integrating this tool in
base. Therefore I'm sending the diff below to everyb...@misc...for
inspiration.
--
Bjvrn Ketelaars
[1] http://marc.info/?l=openbsd-cvs&m=133278525113948&w=2
Index: distrib/sets/lists/base/mi
===
RCS file: /mnt/cvs/src/distrib/sets/lists/base/mi,v
retrieving revision 1.566
diff -u -r1.566 mi
--- distrib/sets/lists/base/mi 8 Mar 2012 19:28:45 - 1.566
+++ distrib/sets/lists/base/mi 2 Apr 2012 11:33:11 -
@@ -2548,6 +2548,7 @@
./usr/sbin/dig
./usr/sbin/dnssec-keygen
./usr/sbin/dnssec-signzone
+./usr/sbin/drill
./usr/sbin/dvmrpctl
./usr/sbin/dvmrpd
./usr/sbin/editmap
@@ -2699,6 +2700,12 @@
./usr/sbin/traceroute
./usr/sbin/traceroute6
./usr/sbin/trpt
+./usr/sbin/unbound
+./usr/sbin/unbound-anchor
+./usr/sbin/unbound-checkconf
+./usr/sbin/unbound-control
+./usr/sbin/unbound-control-setup
+./usr/sbin/unbound-host
./usr/sbin/usbdevs
./usr/sbin/user
./usr/sbin/useradd
@@ -5152,6 +5159,11 @@
./var/spool/uucppublic
./var/tmp
./var/tmp/vi.recover
+./var/unbound
+./var/unbound/etc
+./var/unbound/var
+./var/unbound/var/dev
+./var/unbound/var/run
./var/www
./var/www/bin
./var/www/bin/bgpctl
Index: distrib/sets/lists/etc/mi
===
RCS file: /mnt/cvs/src/distrib/sets/lists/etc/mi,v
retrieving revision 1.146
diff -u -r1.146 mi
--- distrib/sets/lists/etc/mi 2 Apr 2012 03:08:44 - 1.146
+++ distrib/sets/lists/etc/mi 2 Apr 2012 11:33:11 -
@@ -166,6 +166,7 @@
./etc/rc.d/sshd
./etc/rc.d/statd
./etc/rc.d/syslogd
+./etc/rc.d/unbound
./etc/rc.d/tftpd
./etc/rc.d/watchdogd
./etc/rc.d/wsmoused
@@ -244,6 +245,9 @@
./var/named/standard/loopback
./var/named/standard/loopback6.arpa
./var/run/utmp
+./var/unbound/etc/root.hint
+./var/unbound/etc/unbound.conf
+./var/unbound/var/run/root.key
./var/www/cgi-bin/printenv
./var/www/cgi-bin/test-cgi
./var/www/conf/bgplg.css
Index: distrib/sets/lists/man/mi
===
RCS file: /mnt/cvs/src/distrib/sets/lists/man/mi,v
retrieving revision 1.1128
diff -u -r1.1128 mi
--- distrib/sets/lists/man/mi 29 Mar 2012 11:03:59 - 1.1128
+++ distrib/sets/lists/man/mi 2 Apr 2012 11:33:11 -
@@ -353,6 +353,7 @@
./usr/share/man/man1/dirname.1
./usr/share/man/man1/domainname.1
./usr/share/man/man1/dprofpp.1
+./usr/share/man/man1/drill.1
./usr/share/man/man1/du.1
./usr/share/man/man1/echo.1
./usr/share/man/man1/ed.1
@@ -758,6 +759,7 @@
./usr/share/man/man1/uname.1
./usr/share/man/man1/uncompress.1
./usr/share/man/man1/unexpand.1
+./usr/share/man/man1/unbound-host.1
./usr/share/man/man1/unifdef.1
./usr/share/man/man1/uniq.1
./usr/share/man/man1/units.1
@@ -2537,6 +2539,7 @@
./usr/share/man/man5/texinfo.5
./usr/share/man/man5/ttys.5
./usr/share/man/man5/tzfile.5
+./usr/share/man/man5/unbound.conf.5
./usr/share/man/man5/usermgmt.conf.5
./usr/share/man/man5/utmp.5
./usr/share/man/man5/uuencode.5
@@ -3040,6 +3043,10 @@
./usr/share/man/man8/ttyflags.8
./usr/share/man/man8/tunefs.8
./usr/share/man/man8/umount.8
+./usr/share/man/man8/unbound-anchor.8
+./usr/share/man/man8/unbound-checkconf.8
+./usr/share/man/man8/unbound-control.8
+./usr/share/man/man8/unbound.8
./usr/share/man/man8/updatedb.8
./usr/share/man/man8/usbdevs.8
./usr/share/man/man8/uucpd.8
Index: etc/Makefile
===
RCS file: /mnt/cvs/src/etc/Makefile,v
retrieving revision 1.316
diff -u -r1.316 Makefile
--- etc/Makefile1 Apr 2012 18:32:51 - 1.316
+++ etc/Makefile2 Apr 2012 11:33:11 -
@@ -53,9 +53,9 @@
inetd isakmpd ldapd ldattach ldpd lpd mopd mrouted named nginx \
nsd ntpd ospfd ospf6d portmap pflogd rarpd rbootd relayd ripd \
route6d rtadvd rtsold rwhod sasyncd sendmail sensorsd smtpd \
- snmpd spamd sshd syslogd watchdogd wsmoused xdm ypbind ypldap \
- yppasswdd ypserv kdc kadmind kpasswdd nfsd mountd lockd statd \
- spamlogd sndiod popa3d tftpd
+ snmpd spamd sshd syslogd unbound watchdogd wsmoused xdm ypbind \
+ ypldap yppasswdd ypserv kdc kadmind kpasswdd nfsd mountd lockd \
+ statd spamlogd sndiod popa3d tftpd
MISETS=base${OSrev}.tgz comp${OSrev}.tgz \
man${OSrev}.tgz game${OSrev}.tgz etc${OSrev}.tgz
@@ -219,6 +219,13 @@
${DESTDIR}/var/named/standard/loopback; \
${INSTALL} -c -o root -g wheel -m 644 db.loopback6.arpa \
${DESTDIR}/var/named/standard/loopback6.arpa
+ cd unbound; \
+
Unbound in base (review)
2012/3/14 Jakob Schlyter mailto:ja...@kirei.se)>: > Could you provide an update complete tarfil for review by other developers? I think we should start considering importing this. Latest iteration: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.9.tar.gz Current status includes work on suggestions / remarks from Jakob: - run unbound-control-setup if no keys found; - shipping of a default root.key (for use with auto-trust-anchor-file in unbound.conf). This 'solves' a difficult and ugly workaround with unbound-anchor as suggested in previous iterations; - start nsd before unbound. Detailed information can be found in the tarball (README). -- BjC6rn Ketelaars
Re: Unbound in base
> > From unbound-anchor.8 I understand that unbound-anchor can be run from the
> > command line, or run as part of startup scripts _before_ the actual
> > (unbound)
> > DNS server is started. So there is no need for DNS. Proposal therefor is to
> > run unbound-anchor automatically before starting the unbound daemon (rc_pre
> > in
> > unbound rc-script).
>
>
> This (i.e. connecting out to https://data.iana.org from the system startup
> scripts) should *not* happen by default even if unbound is enabled. There
> would need to be a separate option controlling this.
How about letting /var/unbound/etc/unbound.conf control this behavior?
In the startup script (rc.d-script):
rc_pre() {
if ! egrep "# *auto-trust-anchor-file:" /var/unbound/etc/unbound.conf
>/dev/null; then
sudo -u _unbound /usr/sbin/unbound-anchor
fi
}
The same behavior can be obtained by writing a wrapper. Although these
'solutions' work, they are not elegant. What say thou?
Re: Unbound in base
2012/2/15 Ralf mailto:r...@ackstorm.de)>:
> I have briefly tested your tarball on hppa yesterday. It compiles
> and works so far.
>
Nice to hear :-)
> I haven't gotten the DNSSec to work, so I ran with module-config:
> iterator. But I'm not too familiar with DNSsec, so I might have done
> something wrong on that part. And I cheated a bit when compiling and
> installing, as the machine didn't have the full source tree, so I did
> some steps manually, maybe I left something out.
>
The supplied unbound.conf should work (mental note to myself: assumption is
the mother of all b&). Could you check that there is a root.key in
/var/unbound/etc? If not, please run unbound-anchor manually, do not forget to
set the right permissions on root.key or run as _unbound (this is part of the
current unbound rc.d-script - rc_pre()).
If there is a root.key you could use drill to test:
drill @127.0.0.1 www.nic.cz (http://nic.cz) (rcode: noerror)
drill @127.0.0.1 www.rhybar.cz (http://rhybar.cz) (rcode: servfail)
or use dig:
dig @127.0.0.1 www.nic.cz (http://www.nic.cz) +dnssec (ad flag should be set)
Make sure that unbound is running ...
> There was an issue with the rc.diff patch:
>
> + if [ X"${unbound_flags}" != X"NO" ]; then
> + echo -n "unbound-control-setup: generating self-signed
certificate and private keys... "
> + if sudo -u _unbound unbound-control-setup >/dev/null
2>&1; then
> + echo done.
> + else
> + echo failed.
> + fi
> + fi
> + fi
>
You are right! I will correct this. BTW, in the current unbound.conf,
control-enable is not set to 'yes'. Even if there are keys and certificates
unbound-control will not work as it should. The idea is to use unbound-control
for stopping and starting the daemon (rc.d-script), so this has to be changed
as well.
In the meantime I simplified the rc.d-script a bit:
#!/bin/sh
#
# $OpenBSD: unbound
daemon="/usr/sbin/unbound-control"
daemon_flags="-c /var/unbound/etc/unbound.conf"
. /etc/rc.d/rc.subr
pexp="unbound${daemon_flags:+ ${daemon_flags}}"
rc_reload=NO
rc_pre() {
sudo -u _unbound /usr/sbin/unbound-anchor
}
rc_start() {
${daemon} start
}
rc_stop() {
${daemon} stop
}
rc_cmd $1
As you can see rc_pre() runs unbound-anchor. This is still a point of
discussionb&
--
BjC6rn Ketelaars
Re: Unbound in base
2012/2/13 Stuart Henderson : ... >> After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to >> large to send to this list. if anyone feels like looking at the workb&do not >> hesitate to mail me. > > Please do. It would be nice to put them on a public server. > WIP can be found here: http://goo.gl/BIRR5 .tar.gz contains a README which explains the status -- Bjvrn Ketelaars
Unbound in base
Hello, After some recent discussions [1, 2] on the topic of unbound in base, and (more important) really liking the idea of an alternative for BIND in base, I made a start with fitting the different pieces of the puzzle. What is finished: 1.) Integration of ldns 1.6.12 and unbound 1.4.15 and writing of relevant Makefile wrappers. Wrapper script also compiles and installs drill; 2.) Testing (read: does it compile and work) on AMD64. Stuart Henderson had some good remarks on integrating the above [3]. What do you guys think of the following: What to do with the BIND tools (dig/host/nslookup)? Unbound offers drill. From drill.1: "The name drill is a pun on dig. With drill you should be able get even more information than with dig.". Proposal therefore is to replace the BIND tools with drill. Do we run unbound-anchor automatically? if so, how do we handle possibly not having working DNS at that time to resolve data.iana.org (http://data.iana.org) (http://data.iana.org)? >From unbound-anchor.8 I understand that unbound-anchor can be run from the command line, or run as part of startup scripts _before_ the actual (unbound) DNS server is started. So there is no need for DNS. Proposal therefor is to run unbound-anchor automatically before starting the unbound daemon (rc_pre in unbound rc-script). How and when do we automatically generate unbound-control keys? if so, where should that be done? b& >From unbound-control.8: The script unbound-control-setup generates these control keys in the default run directory. If you change the access control permissions on the key files you can decide who can use unbound-control. Run the script under the same username as you have configured in unbound.conf or as root, so that the daemon is permitted to read the files, for example with: sudo -u unbound unbound-control-setup. If you have not configured a username in unbound.conf, the keys need read permission for the user credentials under which the daemon is started. The script preserves private keys present in the directory. After running the script as root, turn on control-enable in unbound.conf. The unbound-control-script can be called from rc->make_keys(). The knob 'control-enable' can be set as default. After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to large to send to this list. if anyone feels like looking at the workb&do not hesitate to mail me. Again, what do you guys think? Kind regards, BjC6rn [1] http://marc.info/?l=openbsd-misc&m=132205020820910&w=2 [2] http://marc.info/?l=openbsd-tech&m=132573371521516&w=2 [3] http://marc.info/?l=openbsd-misc&m=132217547525487&w=2
Re: Apache (base) and proxy_module
2010/11/23 Bjvrn Ketelaars :
> I'm running an application with a web-interface behind an Apache
> reverse proxy (from base). As this application is on the same host as
> Apache it is running on another port (8080 instead of 80).
> Unfortunately Apache sends back the wrong Host-Header. After carefully
> checking the CVS-log for a bit of inspiration I found that a similar
> problem was solved almost nine months ago [1]. When returning to an
> older revision (1.19.2.1) of proxy_http.c my problems were gone. After
> carefully looking at the code I think I have found a solution for the
> former problem as well as my problem.
>
> # diff -u proxy_http.c.orig proxy_http.c
> --- proxy_http.c.orig Tue Nov 23 12:05:25 2010
> +++ proxy_http.cTue Nov 23 12:44:26 2010
> @@ -367,7 +367,7 @@
>AP_HOOK_DECLINE(DECLINED),
>&rc, r, f, desthost, destportstr, destportstr);
> if (rc == DECLINED) {
> - if (destportstr != NULL && destport != DEFAULT_HTTP_PORT)
> + if (destportstr != NULL || destport != DEFAULT_HTTP_PORT)
>ap_bvputs(f, "Host: ", desthost, ":", destportstr, CRLF,
NULL);
>else
>ap_bvputs(f, "Host: ", desthost, CRLF, NULL);
>
> What do you think?
>
> [1]
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/modules/proxy/pr
oxy_http.c
>
I believe I made a mistake:
destportstr != NULL => will be evaluated as true when a port is given.
destport != DEFAULT_HTTP_PORT => will ALWAYS be evaluated as false
because in line 118 (proxy_http.c) destport is set to
DEFAULT_HTTP_PORT and never changes. What really has to be compared is
the value of destportstr with destport (or DEFAULT_HTTP_PORT). So the
expression should be:
atoi(destportstr) != destport
New diff:
# diff -u proxy_http.c.orig proxy_http.c
--- proxy_http.c.orig Tue Nov 23 12:05:25 2010
+++ proxy_http.cTue Nov 23 14:00:15 2010
@@ -367,7 +367,7 @@
AP_HOOK_DECLINE(DECLINED),
&rc, r, f, desthost, destportstr, destportstr);
if (rc == DECLINED) {
- if (destportstr != NULL && destport != DEFAULT_HTTP_PORT)
+ if (destportstr != NULL && atoi(destportstr) != destport)
ap_bvputs(f, "Host: ", desthost, ":", destportstr, CRLF,
NULL);
else
ap_bvputs(f, "Host: ", desthost, CRLF, NULL);
What do you think?
Apache (base) and proxy_module
I'm running an application with a web-interface behind an Apache
reverse proxy (from base). As this application is on the same host as
Apache it is running on another port (8080 instead of 80).
Unfortunately Apache sends back the wrong Host-Header. After carefully
checking the CVS-log for a bit of inspiration I found that a similar
problem was solved almost nine months ago [1]. When returning to an
older revision (1.19.2.1) of proxy_http.c my problems were gone. After
carefully looking at the code I think I have found a solution for the
former problem as well as my problem.
# diff -u proxy_http.c.orig proxy_http.c
--- proxy_http.c.orig Tue Nov 23 12:05:25 2010
+++ proxy_http.cTue Nov 23 12:44:26 2010
@@ -367,7 +367,7 @@
AP_HOOK_DECLINE(DECLINED),
&rc, r, f, desthost, destportstr, destportstr);
if (rc == DECLINED) {
- if (destportstr != NULL && destport != DEFAULT_HTTP_PORT)
+ if (destportstr != NULL || destport != DEFAULT_HTTP_PORT)
ap_bvputs(f, "Host: ", desthost, ":", destportstr, CRLF, NULL);
else
ap_bvputs(f, "Host: ", desthost, CRLF, NULL);
What do you think?
[1]
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/modules/proxy/proxy_http.c
spamd, blacklists and rc
hello,
I wondered why spamd-setup would not reload the blacklists from spamd.conf
in blacklist-mode after a reboot.
/etc/rc mentions:
if [ X"${spamd_flags}" != X"NO" ]; then
if [ X"${spamd_black}" != X"NO" ]; then
spamd_flags="${spamd_flags} -b"
fi
echo -n ' spamd'; eval /usr/libexec/spamd ${spamd_flags}
/usr/libexec/spamd-setup -D
if [ X"${spamd_black}" = X"NO" ]; then
echo -n ' spamlogd'
/usr/libexec/spamlogd ${spamlogd_flags}
fi
fi
As it seems spamd-setup runs without the -b option (blacklisting mode
only). Can I replace the above excerpt of /etc/rc by:
if [ X"${spamd_flags}" != X"NO" ]; then
if [ X"${spamd_black}" != X"NO" ]; then
spamd_flags="${spamd_flags} -b"
echo -n ' spamd'; eval /usr/libexec/spamd ${spamd_flags}
/usr/libexec/spamd-setup -b -D
else
echo -n ' spamd'; eval /usr/libexec/spamd ${spamd_flags}
/usr/libexec/spamd-setup -D
echo -n ' spamlogd'
/usr/libexec/spamlogd ${spamlogd_flags}
fi
fi
Or am I missing something?
Kind regards,
BjC6rn Ketelaars
Re: rtorrent problems - solved?
viq wrote: Sorry for the "carpet bombing", I grabbed the list of people who I saw report problems with rtorrent. I'm writing to ask those who had problems with rtorrent try it again with newest snapshots, I was not able to reproduce the problem on a box that used to freeze. Please test and report, maybe Otto just fixed another obscure bug ;) I'm experiencing the same. Rtorrent is working without taking down the complete system. It seems that Arthur Grabowski's work [1] paid of. There is however one point of concern; Rtorrent is a real memory hog; it just keeps on taking and taking... Kind regards, BjC6rn Ketelaars [1] http://marc.info/?l=openbsd-cvs&m=121501219121627&w=2
mmap() on i386
Hello,
I posted a question on ports@ concerning rtorrent on i386. My problem
with this package is that it crashes after sometime taking down (!) the
complete system.
In a response [1] the following was suggested:
"rtorrent mmap()s files and apparently puts a lot of pressure on the
kernel UVM subsystem, exposing bugs there..."
Looking at a response [2] on a message posted on Libtorrent-devel, I
believe it is not an OpenBSD-only situation:
"/me marks another notch on the list of kernels and compilers
r/libtorrent has killed..."
As it seems rtorrent works fine on sparc64.
My question: Is it possible that there is a problem with mmap() on i386?
Kind regards,
Bjvrn Ketelaars
[1] http://marc.info/?l=openbsd-ports&m=119972122106684&w=2
[2] http://rakshasa.no/pipermail/libtorrent-devel/2008-January/001423.html
OpenBSD 4.2-current (GENERIC) #622: Thu Jan 3 02:37:35 MST 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 399 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 536440832 (511MB)
avail mem = 510816256 (487MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/30/98, BIOS32 rev. 0 @ 0xec700,
SMBIOS rev. 2.1 @ 0xf1146 (48 entries)
bios0: vendor Compaq version "686T5" date 06/30/98
bios0: Compaq Deskpro EN Series SFF
acpi0 at bios0: rev 0, can't enable ACPI
bios0: ROM list: 0xc/0x8000 0xc8000/0x800 0xe/0x8000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
agp0 at pchb0: aperture at 0x4400, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Rage Pro" rev 0x5c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 10 function 0 "Intel 8255x" rev 0x05, i82558: irq 11,
address 00:50:8b:70:84:c0
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
fxp1 at pci0 dev 13 function 0 "Intel 8255x" rev 0x05, i82558: irq 11,
address 00:08:c7:5a:38:e9
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 0
ral0 at pci0 dev 14 function 0 "Ralink RT2561S" rev 0x00: irq 11,
address 00:0c:f6:25:39:87
ral0: MAC/BBP RT2561C, RF RT2527
piixpcib0 at pci0 dev 20 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 20 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 20 function 2 "Intel 82371AB USB" rev 0x01: can't map
i/o space
piixpm0 at pci0 dev 20 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
admtemp0 at iic0 addr 0x4c: adm1021
spdmem0 at iic0 addr 0x50: 256MB SDRAM non-parity PC133CL3
spdmem1 at iic0 addr 0x51: 256MB SDRAM non-parity PC133CL3
isa0 at piixpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc_cmd: send error
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
kbc: aux echo error 1
kbc: cmd word write error
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
biomask f7e5 netmask ffe5 ttymask ffe7
mtrr: Pentium Pro MTRR support
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
WARNING: / was not properly unmounted
pckbc: command timeout
Re: Getting isakmpd and MacOSX racoon to work together
On Mon, 11 Jun 2007 18:18:45 +1000, "Christopher Vance" <[EMAIL PROTECTED]> wrote: > I have several machines running OpenBSD 4.1, and am really impressed > by how easy it is to get IPSEC working between them these days. Thanks > people, it's great. > > Unfortunately one other machine I'd dearly like to include is a MacOSX > 10.4.9 machine, running racoon. > > Yes I have googled, yes I have spent several days on this, and yes, I > do want to strangle the Mac. > > Before I struggle too much longer trying to configure racoon to do the > right thing, or give in to using a package not in the OpenBSD base > system, is there someone out there actually running IPSEC with MacOSX > on one end and OpenBSD on the other, using racoon to do it? I'd > really appreciate it if you could share working config. > > Failing the above, if you've chosen between openvpn, poptop, or other > non-base packages, which worked out best for you? > > -- > Christopher I'm using an IPSEC-tunnel on my Macbook (OSX) to an OpenBSD 4.1 machine. After giving up on Racoon I tried IPSecuritas (http://www.lobotomo.com/index.html). IPSecuritas is a GUI in combination with a 'own' compiled version of Racoon (newer version, better NAT-Traversal support etecera). Before looking at IPSecuritas I tried OpenVPN. Personally I realy dislike the idea of installing third-party kernel modules on my Macbook (there are no tun-interfaces on a standard OSX-install). On the other side; it worked...
Re: IPv6 and illegal prefixlen
Claudio Jeker wrote: On Thu, Dec 28, 2006 at 09:20:19AM +0100, Bjvrn Ketelaars wrote: Marco S Hyman wrote: up giftunnel 212.182.166.172 64.71.128.81 up inet6 2001:470:1F01:::1AE1 2001:470:1F01:::1AE0 prefixlen 128 !route add -inet6 default 2001:470:1F01:::1AE0 Mine looks like this (and it works just fine) - hostname.gif0 - tunnel 208.201.244.208 208.201.234.221 inet6 alias 2001:05a8:0:1::0123 128 dest 2001:05a8:0:1::0122 ! route add -inet6 default ::1 ! route change -inet6 default -ifp gif0 - hostname.gif0 - With this setup route show also has the "route: illegal prefixlen" message. Ignore it. I don't think it has anything to do with your problem. // marc I used your hostname.gif0 as an example which, of course, gave the same result. This means that I still experience the same problem. When I try to setup rtadvd the daemon spits out: rtadvd[2175]: sendmsg on fxp1: No route to host I have a gut feeling that this message is related to the "route: illegal prefixlen" message. I doubt that. The "route: illegal prefixlen" message is a bad type conversion in route(8) itself and the following diff resolves this issue. I'm not using IPv6 and so I don't know what your rtadvd issue is. The diffs resolved the problem of the "route: illegal prefixlen" message. Thank you! Thanks to Marc I finally figured it out; it seems that rtadvd 'pings' from the auto configured link-local address instead of from the inet6 alias. This means that pf should pass icmp6 traffic from the link-local address to the internal network. Thanks Marc and Claudio!
Re: IPv6 and illegal prefixlen
Marco S Hyman wrote: > up giftunnel 212.182.166.172 64.71.128.81 > up inet6 2001:470:1F01:::1AE1 2001:470:1F01:::1AE0 prefixlen 128 > !route add -inet6 default 2001:470:1F01:::1AE0 Mine looks like this (and it works just fine) - hostname.gif0 - tunnel 208.201.244.208 208.201.234.221 inet6 alias 2001:05a8:0:1::0123 128 dest 2001:05a8:0:1::0122 ! route add -inet6 default ::1 ! route change -inet6 default -ifp gif0 - hostname.gif0 - With this setup route show also has the "route: illegal prefixlen" message. Ignore it. I don't think it has anything to do with your problem. // marc I used your hostname.gif0 as an example which, of course, gave the same result. This means that I still experience the same problem. When I try to setup rtadvd the daemon spits out: rtadvd[2175]: sendmsg on fxp1: No route to host I have a gut feeling that this message is related to the "route: illegal prefixlen" message. For completeness: rtadvd.conf fxp1:\ :addr="2001:838:3c6::":prefixlen#64: my sysctl.conf contains: net.inet6.ip6.forwarding=1 net.inet6.ip6.accept_rtadv=0 Kind regards, Bjvrn
IPv6 and illegal prefixlen
Hello, I hit a snag in setting up IPv6 via a gif-interface. Im using the following hostname.gif0 on a snapshot (22-12-06): up giftunnel 212.182.166.172 64.71.128.81 up inet6 2001:470:1F01:::1AE1 2001:470:1F01:::1AE0 prefixlen 128 !route add -inet6 default 2001:470:1F01:::1AE0 With this setup Im able to 'ping6' to the outside (IPv6) world - this means that the tunnel is working. What I dont get is the output from 'route show': Internet6: DestinationGatewayFlagsRefsUseMtuInterface ::/104localhost.hydroxid UGRS00 - lo0 ::/96 localhost.hydroxid UGRS00 - lo0 route: illegal prefixlen ::/4 localhost.hydroxid UGS 1 56 - gif0 ... What illegal prefixlen? I see no reason that the used route is invalid. Im I missing something? Kind regards, Bjvrn
dhcpd and leased_ip_table
Hello,
I like the idea of using a "leased_ip_table" in dhcpd (-L option) in
combination with pf. Unfortunately Im not clear on one point; it seems
that the L option only works in combination with the A option
("abandoned_ip_table"). Without the A option the leased_ip_table is not
filling up.
If Im reading the man page correctly the use of the A option, in
combination with the L option, is not mandatory. Is there an
explanation for this behavior?
Kind regards,
Bjvrn
Re: Wild card greytrapping setup in spamdb
On Thu, 09 Nov 2006 02:04:39 -0500, Daniel Ouellet <[EMAIL PROTECTED]> wrote: jared r r spiegel wrote: On Wed, Nov 08, 2006 at 02:46:35PM -0500, Daniel Ouellet wrote: So, I see absolutely nothing wrong with this, but only huge benefit. with the "not" wildcard stuff, it seems like that would perhaps be a bit heavier to implement than the "definately is" matching. Yes granted. I never said it was easy for sure. But even a simple match everything could be nice. I have a few domains that do nothing and I would be happy to turn them into spam trap! (;> Plus as Bob describe very well in his presentations, never under estimate the power of sex. So, may be I could register a sex attractive domain and use that for a spam trap! (:> block drop from ! to any Could be nice, but may sure not be trivial either. in the meantime, have you considered handling this yourself and just using the maillog to your advantage? for example, you can grep maillog looking for loglines referencing invalid users /for your local domains/. I put Bob PERL script in use and so far, I have only very nice things to say about it! Make the full spamd system much more efficient and as he describe it. It is deadly! (;> i'm using the following to add bullshit addresses to the greytrap, probably could kill the 'zegrep' vs. 'egrep' stuff because it looks like zegrep gracefully handles non gzipped stuff, but whatever. Adding a long list of variation emails is sure doable and not a huge problem. I was just thinking that having list of emails not in use trap would be nice. But Bob new script does support LDAP for email accounts and would do that as well. So, I guess I need to setup an LDAP server and try it then. Should be fun! (:> i don't paste this because i say "copy and paste this and use it", but rather, check this out for an idea and do it in your own way. Thanks, I will have a look, but I have to say, I LOVE Bob PERL script here: http://www.ualberta.ca/~beck/greyscanner This is a joy to run! Thanks Bob! Best, Daniel Indeed Bobbs script is a joy to run. But as he said it is a prototype! For example if ones connection to the Internet is temporary down, the script will interpret the missing result of the MX-lookup as a reason to trap a legit grey entry.
Re: ipsec vpn
Matt Bettinger wrote: On 11/8/06, Adam <[EMAIL PROTECTED]> wrote: Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote: -snip the high school creative writing assignment- Let's see, you show up to answer an ipsec question by advocating openvpn instead. Then you decide to tell openbsd developers how they should be acting on their mailing list. You even use 'M$' and dismiss anyone who disagrees with you as a troll since you can't actually argue a point. Who exactly is the troll again? Adam Sniip Can we try to get back on track with the thread please. I think there are quite a few people out there who would benefit from some useful information on a typical vpn configuration with windows clients. Does anyone have an ipsec.conf example with correct transform set to allow dynamic windows clients to connect to an OpenBSD vpn gateway using pre-shared key? The old way works fine but the ipsec.conf appears alot cleaner to configure. Thanks. -mb I'm using the following in ipsec.conf (test-enviroment): ike passive esp tunnel from any to any \ main auth hmac-md5 enc des group modp768 \ quick auth hmac-md5 enc des group modp768 \ psk 01234 Maybe this will work for you...
Re: Snapshot and network connections trouble
Moritz Grimm wrote: Bjvrn Ketelaars wrote: Last week (January 24, 2006) I updated our gateway to snapshot (i386). Everything seems to work fine except that users are complaining about internet-connections being dropped. The main complaint is that it is possible to use the internet but it is not possible to transfer files. I checked this complaint, and indeed there are some problems best described as connections being closed to fast. As a test I reverted to a backup (Snapshot December 29, 2005) which solved the dropping of connections. Is there anyone who recognizes this problem and maybe has a solution? [...] pass in on $wan_if inet proto tcp from ! to 10.0.0.100 port 5000 flags S/SA synproxy state pass in on $wan_if inet proto udp from ! to 10.0.0.100 port 5000 keep state pass out on $wan_if proto tcp from any to ! modulate state flags S/SA [...] It looks like this could be related to modulate/synproxy state being currently broken: http://marc.theaimsgroup.com/?l=openbsd-pf&m=113844738811816&w=2 It would be interesting to know if the patch helps, I suppose? Moritz Applied the path, compiled and tested the new kernel. Everything works fine now! Thanks
Snapshot and network connections trouble
Last week (January 24, 2006) I updated our gateway to snapshot (i386).
Everything seems to work fine except that users are complaining about
internet-connections being dropped. The main complaint is that it is
possible to use the internet but it is not possible to transfer files. I
checked this complaint, and indeed there are some problems best
described as connections being closed to fast.
As a test I reverted to a backup (Snapshot December 29, 2005) which
solved the dropping of connections.
Is there anyone who recognizes this problem and maybe has a solution?
Im using a three legged setup; two Intel NICs (fxp0 and fxp1) and one
Prism 2.5 (wi0). I included a copy of pf.conf and the output of dmesg.
# macros
wan_if = "fxp0"
lan_if = "fxp1"
wir_if = "wi0"
wan_lan_tcp = "{ssh, smtp, http, https}"
wan_lan_udp = "{isakmp, ipsec-nat-t}"
wan_lan_icmp = "{echoreq}"
wir_lan_tcp = "{ssh}"
wir_lan_udp = "{domain, isakmp, ipsec-nat-t}"
table const {127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12,
10.0.0.0/8}
# options
set block-policy return
set loginterface $wan_if
# scrub incoming packets
scrub on $wan_if reassemble tcp no-df random-id
# nat/rdr
nat on $wan_if from $lan_if:network to any -> ($wan_if)
nat on $wan_if from $wir_if:network to any -> ($wan_if)
rdr on $wan_if proto tcp from !10.0.0.100 to ($wan_if) port 5000 ->
10.0.0.100
rdr on $wan_if proto udp from !10.0.0.100 to ($wan_if) port 5000 ->
10.0.0.100
# setup a default block policy
block log (all)
# loopback interface (lo0)
set skip on lo0
# encryption interface (enc0)
set skip on enc0
# external interface ($wan_if)
pass in on $wan_if inet proto tcp from ! to ($wan_if) port
$wan_lan_tcp flags S/SA keep state
pass in on $wan_if inet proto udp from ! to ($wan_if) port
$wan_lan_udp keep state
pass in on $wan_if inet proto esp from ! to ($wan_if) keep state
pass in on $wan_if inet proto icmp from ! to ($wan_if)
icmp-type $wan_lan_icmp keep state
pass in on $wan_if inet proto tcp from ! to 10.0.0.100 port
5000 flags S/SA synproxy state
pass in on $wan_if inet proto udp from ! to 10.0.0.100 port
5000 keep state
pass out on $wan_if proto tcp from any to ! modulate state
flags S/SA
pass out on $wan_if proto udp from any to ! keep state
pass out on $wan_if proto icmp from any to ! keep state
# internal interface ($lan_if)
pass in on $lan_if from $lan_if:network to any keep state
pass out on $lan_if from any to $lan_if:network keep state
# wireless interface ($wir_if)
pass in on $wir_if proto tcp from $wir_if:network to $wir_if port
$wir_lan_tcp keep state
pass in on $wir_if proto udp from $wir_if:network to $wir_if port
$wir_lan_udp keep state
pass in on $wir_if proto esp from $wir_if:network to $wir_if keep state
pass out on $wir_if from any to $wir_if:network keep state
OpenBSD 3.9-beta (GENERIC) #593: Tue Jan 24 02:00:54 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 398 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 268017664 (261736K)
avail mem = 237572096 (232004K)
using 3297 buffers containing 13504512 bytes (13188K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(e4) BIOS, date 06/30/98, BIOS32 rev. 0 @ 0xec700
pcibios0 at bios0: rev 2.1 @ 0xec700/0x3900
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf7440/112 (5 entries)
pcibios0: PCI Interrupt Router at 000:20:0 ("Intel 82371AB PIIX4 ISA"
rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x800 0xe/0x8000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Rage Pro" rev 0x5c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 10 function 0 "Intel 8255x" rev 0x05, i82558: irq 11,
address 00:50:8b:70:84:c0
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
fxp1 at pci0 dev 13 function 0 "Intel 8255x" rev 0x05, i82558: irq 11,
address 00:08:c7:5a:38:e9
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 0
wi0 at pci0 dev 14 function 0 "Intersil PRISM2.5" rev 0x01: irq 11
wi0: PRISM2.5 ISL3874A(Mini-PCI) (0x8013), Firmware 1.0.7 (primary),
1.3.6 (station), address 00:09:5b:69:98:4c
pcib0 at pci0 dev 20 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 20 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19541MB, 40021632 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA, 78167MB, 160086528 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
uhci0 at pci0 dev 20 function
Apache and mod_dav
I am trying to implement WebDAV into Apache (stock OpenBSD 3.7 version). After adding mod_dav (package) to Apache and making the necessary adjustments to httpd.conf (following http://www.webdav.org/mod_dav/faq/) I managed to see/open the freshly made 'share' but not write to it; error.log (Apache) mentions 'Could not open the lock database'. In an attempt to resolve this challenge, I tried the following: 1.) Run Apache outside chroot; 2.) Chmod everything remotely connected to mod_dav to 777; 3.) Used the following settings in httpd.conf. DAVLockDB /var/www/htdocs/DAV DAVMinTimeout 600 Options FollowSymLinks AllowOverride None AllowOverride None Order allow,deny Allow from all DAV On Unfortunately these attempts were not fruitful and error.log still mentions 'Could not open the lock database'. Any suggestions? -- Insanity in individuals is something rare - but in groups, parties, nations and epochs, it is the rule.
