Re: smtpd smtp_proceed_wiz function

2021-11-08 Thread Chris Cappuccio
Crystal Kolipe [kolip...@exoticsilicon.com] wrote:
> On Mon, Nov 08, 2021 at 06:13:14PM +, Stuart Henderson wrote:
> > On 2021/11/08 14:52, Crystal Kolipe wrote:
> > > I'm not aware of a 'wiz' command in any SMTP related RFC.
> > This will become clear if you look into sendmail history :)
> 
> Got it :).
> 
> I assume that this won't be implemented in OpenBSD any time soon
> then.

We could emulate it and pretend that we are an ancient vulnerable 
verison of Sendmail, or pretty much any version since they all
contain a plethora of vulnerabilities.

While we're at it, maybe emulate Microsoft Exchange and EXIM :)

Chris 



Re: [patch] httpd static gzip compression

2021-11-04 Thread Chris Cappuccio
Solene Rapenne [sol...@perso.pw] wrote:
> On jeudi 4 novembre 2021 15:09:39 CET, Stuart Henderson wrote:
> > 
> > btw this was rejected before,
> > 
> > https://github.com/reyk/httpd/issues/21
> 
> It's not clear if "static" compression is rejected. Sure, on-the-fly
> compilation is complicated and bring issues, static compression
> is easy to implement and predictible IMO.

In my opinion, this feature makes sense if it can be activated by the
'location' ...

It requires explicit preparation by the site operator so it should
only activated on demand, per-directory

It makes sense to me in this context

If someone explicitly requests the .gz version, they get it, regardless
of this setting

If someone requests the non-gz version, their browser should only
get the gz if it agrees to transparently handle the compression

And the gz swap only gets activated if the site operator tells
httpd this is the desired behavior for a particular directory tree through
the location keyword...

Chris



Re: forwarding in parallel ipsec workaround

2021-10-02 Thread Chris Cappuccio
Hrvoje Popovski [hrv...@srce.hr] wrote:
> 
> box didn't panic, just stopped forwarding traffic through tunnel.

any chance any progress has been made here? is there any newer versions
of these diffs floating around?



Re: Willing to test any driver for AX210

2021-08-04 Thread Chris Cappuccio
The iwlwifi driver has this commit for adding the "device family AX210"

https://patchwork.kernel.org/project/linux-wireless/patch/20190207223622.9642-14-l...@coelho.fi/

There are other commits too. It requires driver adaptation, firmware,
the iwx driver will have to be extended.



Re: [External] : forwarding in parallel

2021-07-07 Thread Chris Cappuccio
Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
> diff --git a/sys/net/if_tpmr.c b/sys/net/if_tpmr.c
> index f6eb99f347c..4ffa5b18293 100644
> @@ -725,10 +759,9 @@ tpmr_p_dtor(struct tpmr_softc *sc, struct tpmr_port *p, 
> const char *op)
>   if_detachhook_del(ifp0, >p_dtask);
>   if_linkstatehook_del(ifp0, >p_ltask);
>  
> - smr_barrier();
> + tpmr_p_rele(p);
>  
> - if_put(ifp0);
> - free(p, M_DEVBUF, sizeof(*p));
> + smr_barrier();
>  
>   if (ifp->if_link_state != LINK_STATE_DOWN) {
>   ifp->if_link_state = LINK_STATE_DOWN;

The order is changing here, it was smr_barrier and then the
equivalent of tpmr_p_rele, now it is tpmr_p_rele first,
smr_barrier second, is that change intentional ?

Chris



Re: gpio(4) support for APU2

2021-06-30 Thread Chris Cappuccio
Chris Narkiewicz [he...@ezaquarii.com] wrote:
> On Wed, Jan 29, 2020 at 10:47:28PM +0800, Nathanael Rensen wrote:
> > The diff below adds gpio(4) support to wbsio(4) for Nuvoton NCT5104D
> > (pcengines APU2).
> 
> I'm resurrecting this thread. I was looking for GPIO support for APU2
> board and found this patch in archives.
> 
> Any chance of taking it in?
> 

This is not the first patch to support gpio on wbsio, it's at least
the third, but arguably the best :)

Mark Kettenis said:

"But as before this diff does nothing to make sure it is actually
safe to touch these gpio pins.  Other machines might have the same
chip but use the pins internally to switch power to on-board
components."

A simple way to do this could be some kind of description file
specific to the board. Kind of like an FDT, but just for GPIO pins. 
GPIO Descriptor Tree?

So, when you are using an APU1/APU2, copy apu.gpiodt to /etc/gpiodt
and the kernel will load it on boot like a firmware image to decide
what pins you get access to from userland. Or maybe gpioctl would
load allowed pin use settings in rc.securelevel ?

Is this a sane way to go? If so, what attributes would be needed for
each pin? Something like user, locked, kernel?

apu.gpiodt:

gpio0@wbsio {
hwproduct = "APU";
pin0 = "locked";
pin1 = "locked";
pin2 = "locked";
pin3 = "user";
pin4 = "user";
pin5 = "user";
pin6 = "user";
pin7 = "user";
pin8 = "user";
pin9 = "user";
pin10 = "user";
pin11 = "user";
pin12 = "user";
pin13 = "user";
pin14 = "user";
pin15 = "user";
};

Chris



Re: list hyperv features in dmesg

2021-06-14 Thread Chris Cappuccio
Peter J. Philipp [p...@delphinusdns.org] wrote:
> 
> Before:
> pvbus0 at mainbus0: Hyper-V 10.0
> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f
> hyperv0: heartbeat, kvp, shutdown, timesync
> hvs0 at hyperv0 channel 2: ide, protocol 6.2
> 
> After:
> 
> pvbus0 at mainbus0: Hyper-V 10.0
> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f 
> TIME_REFCNT,SYNIC,SYNTIMER,APIC
> ,HYPERCALL,VP_INDEX,GUEST_IDLE
> hyperv0: pm features 0x2 
> hyperv0: features3 0xbed7b2 ,XMM_HYPERCALL3,GUEST_IDLE3,NUMA3,TIME_FREQ3
> hyperv0: heartbeat, kvp, shutdown, timesync
> hvs0 at hyperv0 channel 2: ide, protocol 6.2
> 
> Below is patch, what do you think?  Is it worthy?
> 

If you're going to print flags for some unsupported features, why
not print them all? 

The 'features3' line doesn't look clean

Typically uppercase flags like this are formatted like 

In any event, I'm not sure what benefit this brings. Doesn't 
"hyperv0: heartbeat, kvp, shutdown, timesync" already show what features
are in use?

I imagine it might be interesting to know what features are available but
not in use. Is there a command-line utility that could be extended to show
this info?

Chris



Re: Thread Local Storage in clang

2021-05-28 Thread Chris Cappuccio
Marc Espie [es...@nerim.net] wrote:
> 
> Thinking some more about it, I would suspect the configury stuff in that
> library to expect native support... tls doesn't work on OpenBSD unless you
> respect the toolchain.
> 
> in particular, it won't fly without the support library (the emutls stuff
> in libc++abi)
> 
> clang platforms aren't incredibly common.  It definitely looks like the most
> likely explanation.

Never mind, clang works fine, it's gcc that fails. For some reason after 
upgrading to 6.9 and upgrading ports, the librdkafka started choosing
gcc instead of clang and I was looking in the wrong direction.



Thread Local Storage in clang

2021-05-28 Thread Chris Cappuccio
I tried to compile librdkafka on OpenBSD 6.5 (clang 7.0.1) and clang compiled
the __thread parts with some built-in mechanism. I upgraded the system to
OpenBSD 6.9 and TLS is no longer supported by the in-tree clang. Was this
intended to be turned off? Did the 6.5 version even work? Is Thread Local
Storage support in clang desired in general or no? Marc Espie's clang 
presentation from July 2017 mentions that we do and that Mark Kettenis
helped make it happen. I'm having a hard time finding much other discussion
either way.



Re: ftpd(8): remove useless parameter of get_line()

2021-05-17 Thread Chris Cappuccio
Jan Klemkow [j.klem...@wemelug.de] wrote:
> Hi,
> 
> This diff removes the useless FILE* parameter of get_line().  In every
> call this parameter is always "stdin".  Thus, we can replace ever use of
> the variable iop with stdin.
> 
> Like every other diff, I tested this diff with the ftpd regression
> tests.
> 
> OK?
> 

looks fine to me



Re: sysctl net.inet.ip.arpqueued read only

2021-04-27 Thread Chris Cappuccio
Vitaliy Makkoveev [m...@openbsd.org] wrote:
> 
> 
> > On 26 Apr 2021, at 01:43, Theo de Raadt  wrote:
> > 
> > I am not a fan of this strange behaviour, where the min+max values
> > have additional behaviours.  It is too surprising, and surprising
> > often turns into error-prone.
> 
> Agreed. Also according sysctl_int_bounded() code this behaviour looks
> like non obvious side effect. 
> 

Would 0, 0 min, max be a simple and obvious way to say "read only" ?



Re: iwn: fix hangs with Tx aggregation

2021-03-16 Thread Chris Cappuccio
Stefan Sperling [s...@stsp.name] wrote:
> 
> Sending BA req frames with the firmware node which represents the AP seems to
> fix the problem. I have not yet managed to trigger it again with this patch.
> My best explanation is that this allows the firmware to retry block ack
> requests properly, and to stop retrying once a BA is received from the AP.
> 
> ok?
> 

I suspect you're absolutely right. Thank you for debugging this shitty firmware.



Re: uvm_fault_lower refactoring

2021-02-22 Thread Chris Cappuccio
Martin Pieuchot [m...@openbsd.org] wrote:
> On 16/02/21(Tue) 11:20, Martin Pieuchot wrote:
> > Start by moving `pgo_fault' handler outside of uvm_fault_lower().
> > 
> > If a page has a backing object that prefer to handler to fault itself
> > the locking will be different, so keep it under KERNEL_LOCK() for the
> > moment and make it separate from the rest of uvm_fault_lower().
> > 
> > ok?
> 
> Anyone?
> 

It makes sense, and works on my workstation...



Re: vmm(4): cpuid leaf 0x15 fixes clock speed problem in Linux guest [PATCH]

2020-12-07 Thread Chris Cappuccio
Pratik Vyas [m...@pd.io] wrote:
> 
> This cpuid emulation bit was added during the time when using tsc was
> the only way to get a precise clock and before pvclock was added [2].  This
> also doesn't work on AMD machines (on at least mine).  We could get rid
> of this cpuid emulation.
>

If cpuid emulation makes Jozef's case worse, where does it actually help?



Re: Mellanox ConnectX-6 Driver no working

2020-11-03 Thread Chris Cappuccio
Nilson Lopes [noslin...@gmail.com] wrote:
> 
> If we look carefully in the list of PCI codes in  '/sys/dev/pci/pcidevs'
> source code here
> https://github.com/openbsd/src/blob/master/sys/dev/pci/pcidevs#L6323-L6335,
> we see that the card I'm using is known as MELLANOX MT28908.
> [image: image.png]
> 
> 
> But, the source code for the 'mcx' driver  does not have that particular
> model:
> https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c#L2536-L2546

It may be as simple as adding the pci device to the matching list in 
sys/dev/pci/if_mcx.c and installing your new kernel. You could just put the new 
if_mcx.o file into the kernel relink directory and relink if you want to do 
quick tests.

Also you are best using 6.8-current as it has some mcx fixes that are post 
6.8-release. 

Chris



Re: TCP congestion control progression

2020-08-09 Thread Chris Cappuccio
Brian Brombacher [br...@planetunix.net] wrote:
> 
> I am wondering what approach the project is planning to use to modernize 
> the congestion control algorithms.  I'm interested in assisting the project 
> with development effort in this area.  I've spent time making modifications
> for my own purposes and would prefer to understand the projects goals before
> continuing, if possible.
> 

Various improvements have been made over the years for dynamic window size,
also further tweaks for higher bandwidth over high latency connections. I'd
recommend sharing your current modifications here to get feedback.

Chris



Re: ADMtec aue(4) interface supporting VLAN_MTU ?

2020-04-21 Thread Chris Cappuccio
Tom Smyth [tom.sm...@wirelessconnect.eu] wrote:
> Hi Chrisz,
> 
> 4 bytes for the vlan header .. have you tried increasing the parent
> intetface mtu by 4bytes
> 

IFCAP_VLAN_MTU is a direct bypass for this. "hardmtu" on the parent interface
is perhaps more interesting as it will limit everything including these
encapsulations



Re: SATA HDD hot-plugging question

2019-10-30 Thread Chris Cappuccio
sysadmin [r...@bh0.amt.ru] wrote:
> Hello.
> 
> Does the ahci driver support SATA HDD hot-plugging? There is no
> information about it in the ahci(4) man page.

although it isn't supported today, i think it would be fairly easy to do
if you have an itch for it.



Re: Fix a segmentation fault in awk

2019-08-12 Thread Chris Cappuccio
Frederic Cambus [f...@statdns.com] wrote:
> 
> [1] http://distcache.FreeBSD.org/ports-distfiles/nawk-20121220/awk.tar.gz
> 

Following the lack of hosting from Bell Labs, the post-2012 tree is on
Github.  Brian Kernighan's page now points to:

https://github.com/onetrueawk/awk

Looking through the history it includes some fixes from OpenBSD.

Chris



Re: Fix a segmentation fault in awk

2019-08-12 Thread Chris Cappuccio
Andras Farkas [deepbluemist...@gmail.com] wrote:
> On Mon, Aug 12, 2019 at 3:45 PM Frederic Cambus  wrote:
> > Hi tech@,
> > Here is a diff to fix a segmentation fault in awk, from upstream
> > version 20121220 [1]. Upstream fix didn't check for strdup return value
> > so I added the check.
> I've always been curious, why isn't the latest version of awk, the
> 2012 version, used in OpenBSD?  There may be a reason, but I've never
> been able to figure it out.

Ironically the last update was in 2011. Todd Miller has been keeping it up-to-
date until that point. It'd make sense for someone to analyze the local
changes and import the newer version. The only reason seems to be that the
work needs to be done. Importing the fix is a good first step.

Chris



Re: ADMtec aue interface does not work with full 1500 VLAN_MTU

2019-07-07 Thread Chris Cappuccio
Christopher Zimmermann [chr...@openbsd.org] wrote:
> This works:
> 
> doas ifconfig vlan67 mtu 1496
> 
> this doesn't:
> 
> doas ifconfig vlan67 mtu 1497
> 
> 
> Should we therefore disable VLAN_MTU on this chipset?
> 
> - ifp->if_capabilities = IFCAP_VLAN_MTU;
> -


Yes absolutely. If IFCAP_VLAN_MTU actually worked for some chip versions,
more work is needed to distinguish the working chipsets.

Chris



Re: ld.so speedup (part 2)

2019-04-29 Thread Chris Cappuccio
Stuart Henderson [s...@spacehopper.org] wrote:
> 
> This doesn't match my experience:
> 
> $ time sudo rcctl start samba
> smbd(ok)
> nmbd(ok)
> 0m00.81s real 0m00.31s user 0m00.31s system

He was linking Samba with Kerberos libs too.



Re: Talking about time (ntpd -s)

2019-04-24 Thread Chris Cappuccio
sven falempin [sven.falem...@gmail.com] wrote:
> 
> Alast why not just wait for something to respond and then set time ??
> This (bit ugly) diff reveals some dead code in ntpd
> 
> https://pastebin.com/9PwqBDHz
> 
> Is there another way to bootstrap time correctly ?
> 

ntpd will wait under normal invocation, but -s jumps the system time and
ntpd is only given the limited amount of time for this to happen. The system
does not want to jump to a new time once other daemons are started. That's
why the behavior is the way it is now. If you know you have an interface
that takes a long time to come up for some reason, you can add an appropriate
'sleep' statement in the hostname.if file, or even a script that takes on
a more complicated set of actions before allowing the system to move forward.



Re: nvme_pci.c patch for MSI-X

2019-03-28 Thread Chris Cappuccio
I think the current MSI-X implementation is a minimal skeleton, enough for some
devices under virtualization. I don't know if it's enough for NVMe on real
hardware.

Jason Tubnor [ja...@tubnor.net] wrote:
> Hi,
> 
> Below is a patch that fixes an issue where NVMe storage is presented only
> via MSI-X.  This issue came about as the NVMe implementation in bhyve only
> uses MSI-X.
> 
> Thanks to Chuck Tuffli for the initial patch.  It was adjusted to deal with
> with both cases.
> 
> Thank,
> 
> Jason Tubnor
> 
> Index: sys/dev/pci/nvme_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/nvme_pci.c,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 nvme_pci.c
> --- sys/dev/pci/nvme_pci.c 10 Jan 2018 15:45:46 - 1.7
> +++ sys/dev/pci/nvme_pci.c 24 Mar 2019 08:22:42 -
> @@ -105,7 +105,7 @@ nvme_pci_attach(struct device *parent, s
>   return;
>   }
> 
> - if (pci_intr_map_msi(pa, ) != 0) {
> + if ((pci_intr_map_msix(pa, 0, ) != 0) && (pci_intr_map_msi(pa, ) !=
> 0)) {
>   if (pci_intr_map(pa, ) != 0) {
>   printf(": unable to map interrupt\n");
>   goto unmap;



make NET_TASKQ optionable

2018-12-30 Thread Chris Cappuccio
For future testing purposes, is this ok for the tree?

Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.570
diff -u -p -u -r1.570 if.c
--- if.c20 Dec 2018 10:26:36 -  1.570
+++ if.c30 Dec 2018 18:49:41 -
@@ -233,7 +233,9 @@ int ifq_congestion;
 
 int netisr;
 
+#ifndef NET_TASKQ
 #defineNET_TASKQ   1
+#endif
 struct taskq   *nettqmp[NET_TASKQ];
 
 struct task if_input_task_locked = TASK_INITIALIZER(if_netisr, NULL);



Re: allow weak passwd

2018-12-11 Thread Chris Cappuccio
Ted Unangst [t...@tedunangst.com] wrote:
> 
> i get tired of typing the same password five times.

The first three times, just hit 'a' 
The fourth time, enter the password you want



Re: pvclock(4)

2018-12-03 Thread Chris Cappuccio
Reyk Floeter [r...@openbsd.org] wrote:
>
> Yes, KVM???s stable bit is not a reliable indication as it is seems to depend 
> on the capabilities of the KVM version and not the actual availability of the 
> feature on the particular hardware. How annoying.
>
> As mentioned before: I???d like to disable pvclock for now and I can do that 
> in the morning CET if nobody beats me to it.
>
> I have an idea how to deal with old platforms afterwards but this needs some 
> more tests and thoughts.
>

Perhaps the solution is as "simple" as checking the status of the bit
after the presence of the bit is established ?

Index: pvclock.c
===
RCS file: /cvs/src/sys/dev/pv/pvclock.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 pvclock.c
--- pvclock.c   24 Nov 2018 13:12:29 -  1.2
+++ pvclock.c   4 Dec 2018 00:53:56 -
@@ -127,8 +127,10 @@ pvclock_match(struct device *parent, voi
 void
 pvclock_attach(struct device *parent, struct device *self, void *aux)
 {
-   struct pvclock_softc*sc = (struct pvclock_softc *)self;
-   paddr_t  pa;
+   struct pvclock_softc*sc = (struct pvclock_softc *)self;
+   struct pvclock_time_info*ti;
+   paddr_t  pa;
+   uint8_t  flags;
 
if ((sc->sc_time = km_alloc(PAGE_SIZE,
_any, _zero, _nowait)) == NULL) {
@@ -151,6 +153,13 @@ pvclock_attach(struct device *parent, st
 
/* Better than HPET but below TSC */
sc->sc_tc->tc_quality = 1500;
+
+   ti = sc->sc_time;
+   flags = ti->ti_flags;
+   if ((flags & PVCLOCK_FLAG_TSC_STABLE) == 0) {
+   printf(": unstable timestamp counter\n");
+   return;
+   }
 
tc_init(sc->sc_tc);
 



Re: pvclock(4)

2018-12-03 Thread Chris Cappuccio
johnw [johnw.m...@gmail.com] wrote:
> 
> Hi, after disable pvclock, it can boot with new kernel again, thanks.
...
> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 105.29 MHz, 06-17-0a
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,XSAVE,HV,NXE,LONG,LAHF,PERF,ARAT,MELTDOWN
...

This CPU clearly doesn't have the invariant TSC (it is required according
to Reyk Floeter's tech@ posting from Nov 19th.) So, pvclock does not handle
this situation properly, apparently checking for KVM_FEATURE_CLOCKSOURCE2
and KVM_FEATURE_CLOCKSOURCE_STABLE_BIT is not enough. 

Chris



Re: Vim core dump

2018-11-20 Thread Chris Cappuccio
def...@posteo.de [def...@posteo.de] wrote:
> Hi, all
> 
> Could you be so kind to explain me why OpenBSD has no Dump core issue with
> Vim :
> https://github.com/vim/vim/issues/3619
> 

This is the wrong list for random discussion, but obviously, OpenBSD
is so far superior it can even help to avoid OTHER people's mistakes :)

Chris



Re: OpenBSD on AMD Ryzen7 2700 Asrock B450 chipset

2018-11-06 Thread Chris Cappuccio
Denis [den...@mindall.org] wrote:
> 
> Hardware is relatively new. Can test any compatibility issues/fixes on it.
> 
> There are a lot of "unconfigured" hardware is present in dmesg:
> 
> OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD

The RAMDISK kernels are stripped down. The GENERIC.MP output is more
interesting. Please send it to dm...@openbsd.org (not tech@)



Re: NTPd server using DVB-T as clocksource

2018-10-29 Thread Chris Cappuccio
Lars Schotte [l...@gustik.eu] wrote:
> Well, I know that OpenBSD currently has no support for DVB-T but Linux
> does, so I would run that RaspberryPi with Linux. However, the question
> would be how to pair its output with OpenNTPd or NTPd.
> 

OpenBSD actually does support some of the ugen userland based decovers for
the R820T, as well as the RPi3.

In any event if the target is OpenNTPd, formatting the data as NMEA 0183
would be appropriate.



Re: NTPd server using DVB-T as clocksource

2018-10-28 Thread Chris Cappuccio
Lars Schotte [l...@gustik.eu] wrote:
> 
> Now, I do not like all this, that's why I ordered
> vk-172 gmouse g-mouse USB GPS/GLONASS USB over amazon
> and hope I can use that in combination with some Raspberry PI as NTPd
> clocksource, as I saw some ppl doing.
> 
> But that is only one clocksource, multiple would be preferrable.
> I have some DVB-T adapter lying around that can also be used as a
> clocksource, since those old DVB-T adapters are not good for TV anymore
> since ppl are sending DVB-T2, there is still for the forseeable
> future enough frequencies that will be still old DVB-T and those have
> time signal in them that can be used SOMEHOW.
> 

In OpenBSD, you would write a kernel USB driver that sets up the DVB-T
adapter to receive the appropriate signal and decode it. But the DVB
decoding might be too involved for what should be a small kernel driver.
Maybe you can hack the dvbdate utility into a source of NMEA 0183 data
to be opened as a socket from ntpd. 

Chris



Re: Linux DRM

2018-09-05 Thread Chris Cappuccio
Joseph Mayer [joseph.ma...@protonmail.com] wrote:
> 
> For the one who has not reviewed the code, can you quantify and
> illustrate approximately how bad it is?
> 

Perhaps he was reading from someone who does know some detail of the code?

https://arcan-fe.com/2018/04/25/towards-secure-system-graphics-arcan-and-openbsd/



Re: About differences with GNU patch(1)

2018-06-20 Thread Chris Cappuccio
Vadim Zhukov [persg...@gmail.com] wrote:
> , 20 ??. 2018 ??. ?? 21:17, Vadim Zhukov :
> >
> > Hi,
> >
> > The Ansible "patch" module fails to work on OpenBSD because it tries
> > to use "--dry-run" command-line option on patch(1), while ours
> > supports -C/--check instead. For now, I have an obvious, hm, patch :)
> > for patch.py that replaces --dry-run with --check. But what way do
> > people prefer: to move OpenBSD's patch(1) closer to GNU one, or to add
> > some logic to patch.py that'll detect correct command-line option to
> > use?
> >
> > There's also an issue with --binary: we don't support this option on
> > OpenBSD, and  GNU patch manual page says it's a no-op on POSIX anyway.
> > Would it be okay to add --binary as a no-op option to our patch?
> 
> BTW, the FreeBSD patch got --dry-run 4 years ago:
> https://svnweb.freebsd.org/base/head/usr.bin/patch/patch.c?r1=267490=267512
> 
> NetBSD got it in 2005:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/patch/patch.c.diff?r1=1.22=1.23_with_tag=MAIN
> 
> Neither has --binary.
> 

Marc Espie did -C in 1998. See:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/patch.c.diff?r1=1.10=1.11

I think OpenBSD generally shies away from --gnu-style-options because they're
rather ugly compared to the originals. Unfortunately GNU is apparently setting
the standard for FreeBSD and NetBSD now.

Chris



Re: em: minimum ethernet frame size

2018-02-02 Thread Chris Cappuccio
sc->hw.min_frame_size is only used for TBI mode, which is only available
on the 82543 according to em_set_media_type()

You'd need to carefully analyze how the TBI_ACCEPT macro is used to see
what's right here. The macro even seems to assume that the vlan tag size
might be part of min_frame_size.

Michele Curti [michele.cu...@gmail.com] wrote:
> Hi,
> in sys/dev/pci/if_em.c at line 469 there is:
>   sc->hw.min_frame_size =
>   ETHER_MIN_LEN + ETHER_CRC_LEN;
> 
> But ETHER_MIN_LEN already includes the CRC size:
> #define ETHER_MIN_LEN   64  /* Minimum frame length, CRC included   */
> 
> In revision 1.41 the code changed in this way:
> sc->hw.min_frame_size =
> -   MINIMUM_ETHERNET_PACKET_SIZE + ETHER_CRC_LEN;
> +   ETHER_MIN_LEN + ETHER_CRC_LEN;
> 
> But MINIMUM_ETHERNET_PACKET_SIZE was the size without CRC.
> 
> #define MINIMUM_ETHERNET_FRAME_SIZE  64   /* With FCS */
> #define ETHERNET_FCS_SIZE4
> #define MINIMUM_ETHERNET_PACKET_SIZE \
> (MINIMUM_ETHERNET_FRAME_SIZE - ETHERNET_FCS_SIZE)
> 
> So I attached the following diff to restore the original minimum 
> size (by the way, what's the effect of having min_frame_size set 
> to 68? Discarding valid packets sized from 64 to 67?)
> 
> Regards,
> Michele
> 
> 
> Index: sys/dev/pci/if_em.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em.c,v
> retrieving revision 1.336
> diff -u -p -r1.336 if_em.c
> --- sys/dev/pci/if_em.c   25 Jul 2017 20:45:18 -  1.336
> +++ sys/dev/pci/if_em.c   2 Feb 2018 11:13:43 -
> @@ -466,8 +466,7 @@ em_attach(struct device *parent, struct 
>   MAX_JUMBO_FRAME_SIZE;
>   }
>  
> - sc->hw.min_frame_size = 
> - ETHER_MIN_LEN + ETHER_CRC_LEN;
> + sc->hw.min_frame_size = ETHER_MIN_LEN;
>  
>   /* Allocate Transmit Descriptor ring */
>   if (em_dma_malloc(sc, sc->sc_tx_slots * sizeof(struct em_tx_desc),



Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

2017-08-29 Thread Chris Cappuccio
li...@wrant.com [li...@wrant.com] wrote:
> 
> Please let me know if you want me to generate some dumps or similar, but
> unfortunately, I can't yet test patches or handle compilation on my own.
> I realise my info on this is incredibly lacking as quality & usefulness.
> 

Stuart Henderson has an archive of kernels from snapshot builds that you
can use to better narrow down when the regression started.

Unfortunately I don't remember the URL. Someone who has it easily accessible
may choose to provide it in a reply. You should be able to boot the older
kernels with either the 6.2-beta userland, or with the 6.1 userland. One or
the other will work typically. If you can try them and narrow down,
that's all that's necessary.

Chris



Re: Please test: HZ bump

2017-08-21 Thread Chris Cappuccio
I've been testing the second version of this diff in a number of areas 
(servers, desktop, laptop, routers) and I haven't noticed anything interesting
with power usage, run time on the laptops nor anything else, anywhere. That's
probably a good thing...



Re: ripd(8) fails on P2P links

2016-12-05 Thread Chris Cappuccio
Piotr Durlej [pi...@durlej.net] wrote:
> 
> And here is a patch:
> 

Whoops, I missed this part...And unlike mine it is correct, as there may
not be a destination configured. I think this is the right way to go.

> diff --git a/usr.sbin/ripd/packet.c b/usr.sbin/ripd/packet.c
> index 37b4a91..b956ec0 100644
> --- a/usr.sbin/ripd/packet.c
> +++ b/usr.sbin/ripd/packet.c
> @@ -232,15 +232,17 @@ find_iface(struct ripd_conf *xconf, unsigned int
> ifindex, struct in_addr src)
> 
>  /* returned interface needs to be active */
>  LIST_FOREACH(iface, >iface_list, entry) {
> -if (ifindex != 0 && ifindex == iface->ifindex &&
> -!iface->passive && (iface->addr.s_addr &
> +if (ifindex == 0 || ifindex != iface->ifindex)
> +continue;
> +
> +if (iface->passive)
> +continue;
> +
> +if ((iface->addr.s_addr &
>  iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
> -/*
> - * XXX may fail on P2P links because src and dst don't
> - * have to share a common subnet on the otherhand
> - * checking something like this will help to support
> - * multiple networks configured on one interface.
> - */
> +return (iface);
> +
> +if (iface->dst.s_addr && iface->dst.s_addr == src.s_addr)
>  return (iface);
>  }
> 



Re: ripd(8) fails on P2P links

2016-12-05 Thread Chris Cappuccio
For P2P links, the destination address should be configured as
the peer. If so, perhaps this works?

Index: packet.c
===
RCS file: /cvs/src/usr.sbin/ripd/packet.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 packet.c
--- packet.c25 Oct 2014 03:23:49 -  1.12
+++ packet.c6 Dec 2016 01:34:09 -
@@ -233,15 +233,13 @@ find_iface(struct ripd_conf *xconf, unsi
/* returned interface needs to be active */
LIST_FOREACH(iface, >iface_list, entry) {
if (ifindex != 0 && ifindex == iface->ifindex &&
-   !iface->passive && (iface->addr.s_addr &
-   iface->mask.s_addr) == (src.s_addr & iface->mask.s_addr))
-   /*
-* XXX may fail on P2P links because src and dst don't
-* have to share a common subnet on the otherhand
-* checking something like this will help to support
-* multiple networks configured on one interface.
-*/
-   return (iface);
+   !iface->passive) {
+   if ((iface->addr.s_addr & iface->mask.s_addr) == 
+   (src.s_addr & iface->mask.s_addr))
+   return (iface);
+   if (iface->dst.s_addr == src.s_addr)
+   return (iface);
+   }
}
 
return (NULL);



Re: rebound quantum entanglement

2016-09-15 Thread Chris Cappuccio
Theo de Raadt [dera...@openbsd.org] wrote:
> > That rebound acts like a nameserver is what prompted the idea to
> > hijack the resolver. But it's really a tool that takes over certain
> > duties from the libc resolver, so the libc resolver should be properly
> > configurable to hand over duties, or not. 'search' is the logical
> > place for this.
> 
> So maybe the first generation Ted proposes has some problems.  And
> what have YOU DONE recently??
> 

Sorry guys. I didn't mean to shit all over Ted's first revision. I was
just flabbergasted at the casual tone of this conversation, in contrast
to what was being discussed.

> Look, I think some people don't understand the goal.
> 
> search won't work in roaming + non-roaming situations.  There are
> solutions being discussed to make that easier, they dovetail into
> this slightly.
> 

Roaming means dhclient right?

SOCK_DNS sounds like a great clue.

Chris



Re: rebound quantum entanglement

2016-09-15 Thread Chris Cappuccio
Bryan Steele [bry...@gmail.com] wrote:
> On Thu, Sep 15, 2016 at 10:14:51AM -0400, Ted Unangst wrote:
> > Florian Obser wrote:
> > > Not everything listening on localhost port 53 is a recursive resolver.
> > > nsd(8) per defaults listens on 0.0.0.0 and will respond with REFUSED for
> > > almost every query. asr stops in that case and does not try the next
> > > resolver in the list.
> > 
> > Ah! There's the catch. The good news is I think we can still bind to
> > localhost:53 if nsd is on *:53 (right?). This matters if rebound isn't
> > listening.
> 
> Perhaps I'm confused, but what happens when rebound is stopped by the
> user or it crashes? I think that would mean requests would fallback to
> nsd on *:53 which as Florian mentioned, would not try the next
> nameserver in resolv.conf.
> 

This entire discussion is bat-shit crazy to me!

Adding secret nameservers to resolv.conf is plain wrong. Hijacking the
libc resolver is an approach for systemd, not OpenBSD.

I already configure special nameservers on certain machines, that
bind to 127.0.0.1, for my own reasons. In a general sense, when
I configure the system to do something, and it does something
different, I now have to recompile libc. What !??!?!

This point that has been reached in this discussion just reinforces
the idea that this approach is wrong.

The sensible thing to do is add a 'search' parameter to resolv.conf. 
If programs parse resolv.conf themselves, and they break, we should
fix them. 

It seems like the default should be 'search rebound file bind' and
'search rebound bind file' if no 'lookup' keyword is specified. Most
users won't ever have 'search rebound' visible in their resolv.conf.

That rebound acts like a nameserver is what prompted the idea to
hijack the resolver. But it's really a tool that takes over certain
duties from the libc resolver, so the libc resolver should be properly
configurable to hand over duties, or not. 'search' is the logical
place for this.

Chris



Re: switch the cubie miniroot to cubieboard2

2016-09-01 Thread Chris Cappuccio
si...@slackware.it [si...@slackware.it] wrote:
> Speaking as a Cubieboard owner here ;-)
> Would it be too much hassle to provide both images? (and a pony!)
> 

It's fairly easy to take a miniroot image for a similar board, and
adapt it to your board.

Since both the Cubieboard and Cubieboard2 are Allwinner based,
the miniroot's general structure does not change.

1. Install u-boot-2016.07p1 from ports/packages (packages if you don't
want to wait all day)

2. Examine /usr/src/distrib/armv7/ramdisk/install.md and find
a similar board (same or similar chipset).

3. Find the proper u-boot/dtb stuff in /usr/local/share/u-boot

4. Download the miniroot image for a board that has the same
or similar chipset to your board

5. vnconfig vnd0 miniroot.fs

6. Install proper u-boot image to the miniroot image. The install.md
file tells you how to copy the proper u-boot/dtb over. For instance,
Cubieboard is Allwinner A10/A20, and my Lime is A20.

install.md says:

cubie)
dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
bs=1024 seek=8 >/dev/null 2>&1

So, to get my Lime or Lime2 working, I do this:

dd if=/usr/local/share/u-boot/A20-OLinuXino-Lime2/u-boot-sunxi-with-spl.bin 
of=/dev/rvnd0c bs=1024 seek=8

(Note: Lime and lime2 bootloaders will appear to work on both boards,
but if you don't use the right one, the Realtek ethernet PHY will
not be properly initialized.)

7. vnconfig -u vnd0

8. Write miniroot.fs to your SD card

You don't have to use vnd, but this is conceptually simpler
and less error prone than trying to chop it up with dd.

Chris



Re: ifconfig baudrate

2016-08-31 Thread Chris Cappuccio
Reyk Floeter [r...@openbsd.org] wrote:
> 
> Ok, it makes some sense to have this information for Ethernet.
> 

I am strongly opposed to this change on wired or wireless. Why the
push for having less information?

> For 11n and all these new wireless rates it doesn't provide any useful
> information, what does "HT-MCS0" mean?  Or "HT-MCS70"?  In this case
> it would be much more useful to have the actual speed and not some
> obscure technical details from 802.11.
> 

This is a standard. On 11n, everything from MCS0 to MCS7 is
the single stream version of MCS8 to MCS15. The PHY rate can't tell
you which is in effect alone. We don't support >MCS7 yet so maybe
this is less obvious.

You want to go away from having to know anything about the 11n
MCS table to figure out your expected baud rate? You should
display both.

I'd much rather know what modulation and error coding scheme is in
effect, than know only what the physical data rate is. It's utterly
meaningless by itself.

Chris



Re: armv7 Cortex-A7 fix

2016-08-11 Thread Chris Cappuccio
Tinker [ti...@openmailbox.org] wrote:
> On 2016-08-11 08:30, Mark Kettenis wrote:
> > Finally found the pmap bug that kept Cortex-A7 from working.  Turns
> > out we have to flush the TLB when removing a L1 slot as well.  Already
> > committed the diff, but here it is for those that are interested.
> 
> For the unintroduced but curious, of what material consequence was the pmap
> bug

Crashes on boot up

> and what works that did not work previously, now that it's fixed?
> 

Now it boots up successfully!!

You gotta know when hold 'em, know when to fold 'em, know when flush your TLBs, 
know when to run...



Re: read(2) on directories

2016-07-12 Thread Chris Cappuccio
Todd C. Miller [todd.mil...@courtesan.com] wrote:
> On Tue, 12 Jul 2016 12:47:46 -0700, Chris Cappuccio wrote:
> 
> > I've personally always liked being able to cat / read() a directory
> > since it gives you a peek behind the curtain and reflects the
> > reality of how the filesystem is constructed. 
> 
> You haven't been able to do that on OpenBSD for a very long time.
> 

I've been in a deep depression ever since :)



Re: read(2) on directories

2016-07-12 Thread Chris Cappuccio
Todd C. Miller [todd.mil...@courtesan.com] wrote:
> >From source inspection, Net and Free appear to allow read(2) of
> dirs to succeed.  However, since Linux, Mac OS X and Solaris have
> the EISDIR behavior I think it is probably safe from a portability
> standpoint.
> 
> We're long past the days when opendir(3)/readdir(3) used read(2)...
> 
> HP-UX and AIX still allow reads of directories but no one cares
> about them ;-)
> 

I've personally always liked being able to cat / read() a directory
since it gives you a peek behind the curtain and reflects the
reality of how the filesystem is constructed. 



Re: [PATCH] let the mbufs use more then 4gb of memory

2016-06-23 Thread Chris Cappuccio
Mark Kettenis [mark.kette...@xs4all.nl] wrote:
> 
> We really don't want to implement bounce-buffers.  Adding IOMMU
> support is probably a better approach as it also brings some security
> benefits.  Not all amd64 hardware supports an IOMMU.  And hardware
> that does support it doesn't always have it enabled.  But for modern
> hardware an iommu is pretty much standard, except for the absolute
> low-end.  But those low-end machines tend to have only 2GB of memory
> anyway.

Is the sparc64 iommu code port usable for this purpose?

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/Attic/sg_dma.c



Re: LTE umsm

2016-05-21 Thread Chris Cappuccio
Martin Pieuchot [m...@openbsd.org] wrote:
> On 20/05/16(Fri) 09:47, Chris Cappuccio wrote:
> > So to just remove the ifaceno check, here's the diff.
> > 
> > This matches u3g behaviour for SIERRA TRUINSTALL devices. There is
> > still a bit of hardcoded stuff that needs to be reviewed in umsm
> > for other devices. I think yuo@ was trying to match some of these
> > style checks when he added support for these devices (but it
> > does not appear to be necessary to isolate based on ifaceno for
> > u3g)
> 
> Did you try this with the corresponding device?
> 

I tested the 313U and 770S. 



Re: LTE umsm

2016-05-20 Thread Chris Cappuccio
So to just remove the ifaceno check, here's the diff.

This matches u3g behaviour for SIERRA TRUINSTALL devices. There is
still a bit of hardcoded stuff that needs to be reviewed in umsm
for other devices. I think yuo@ was trying to match some of these
style checks when he added support for these devices (but it
does not appear to be necessary to isolate based on ifaceno for
u3g)

Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.104
diff -u -p -u -r1.104 umsm.c
--- umsm.c  29 Sep 2015 08:34:28 -  1.104
+++ umsm.c  20 May 2016 16:37:08 -
@@ -115,6 +115,7 @@ struct umsm_type {
 
 static const struct umsm_type umsm_devs[] = {
{{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
+   {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
 
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_A2502 }, 0},
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_ADU_500A }, 0},
@@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
+   {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
 
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
@@ -358,8 +360,7 @@ umsm_attach(struct device *parent, struc
 umsm_huawei_changemode(uaa->device);
printf("%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
-   } else if ((sc->sc_flag & DEV_TRUINSTALL) &&
-   uaa->ifaceno == 0) {
+   } else if (sc->sc_flag & DEV_TRUINSTALL) {
umsm_truinstall_changemode(uaa->device);
printf("%s: truinstall mode. need to reattach\n",
sc->sc_dev.dv_xname);



Re: LTE umsm

2016-05-20 Thread Chris Cappuccio
Martin Pieuchot [m...@openbsd.org] wrote:
> On 19/05/16(Thu) 19:27, Chris Cappuccio wrote:
> > Here is a patch to support some newer LTE umsm devices
> > 
> > Yes, the 313U actually has an SD card slot. And yes, it actually
> > changes vendor ID to Airprime after the umsm_truinstall_changemode
> > takes place.
> > 
> > Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
> > is necessary. They don't show up as 0. (It's possible that Huawei will
> > will need the same treatment in umsm_attach if they use newer umsm chips)
> 
> No.  Hardcoding interface number is not the way to go.  Interfaces
> descriptors have a class, subclass and protocol that should be looked
> at. 
> 
> In 3 months a new device will show up with different interfaces layout and
> we will have to hardcode something else?
> 

I agree in principle, however in practice, the goal is to run
umsm_truinstall_changemode to get the device to present itself in a useful
manner.

Before umsm_truinstall_changemode, the class is UICLASS_MASS, subclass
UISUBCLASS_SCSI, and protocol UIPROTO_MASS_BBB. That's a USB disk.

FreeBSD's u3g driver is similar. We could match FreeBSD behavior by simply
removing the ifnaceno check. Then we are just matching on
USB_PRODUCT_SIERRA_TRUINSTALL and UICLASS_MASS.

Chris



LTE umsm

2016-05-19 Thread Chris Cappuccio
Here is a patch to support some newer LTE umsm devices

Yes, the 313U actually has an SD card slot. And yes, it actually
changes vendor ID to Airprime after the umsm_truinstall_changemode
takes place.

Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
is necessary. They don't show up as 0. (It's possible that Huawei will
will need the same treatment in umsm_attach if they use newer umsm chips)

ok?

Aircard 313U:

umsm0 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless, 
Incorporated USB MMC Storage" rev 2.00/0.00 addr 5
umsm0: truinstall mode. need to reattach
umsm0 detached
umsm0 at uhub5 port 3 configuration 1 interface 0 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom1 at umsm0
umsm1 at uhub5 port 3 configuration 1 interface 1 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom2 at umsm1
umsm2 at uhub5 port 3 configuration 1 interface 2 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom3 at umsm2
umsm3 at uhub5 port 3 configuration 1 interface 3 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom4 at umsm3
umsm4 at uhub5 port 3 configuration 1 interface 4 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom5 at umsm4
umass1 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd5 at scsibus3 targ 1 lun 0:  SCSI2 0/direct removable 
serial.0f3d68aa615000291196
umsm5 at uhub5 port 3 configuration 1 interface 7 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom6 at umsm5

Aircard 770S:

umsm0 at uhub5 port 3 configuration 1 interface 9 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
umsm0: truinstall mode. need to reattach
umsm0 detached
umsm0 at uhub5 port 3 configuration 1 interface 3 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom1 at umsm0
umsm1 at uhub5 port 3 configuration 1 interface 8 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom2 at umsm1
umsm2 at uhub5 port 3 configuration 1 interface 0 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom3 at umsm2

Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.104
diff -u -p -u -r1.104 umsm.c
--- umsm.c  29 Sep 2015 08:34:28 -  1.104
+++ umsm.c  20 May 2016 02:05:54 -
@@ -115,6 +115,7 @@ struct umsm_type {
 
 static const struct umsm_type umsm_devs[] = {
{{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
+   {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
 
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_A2502 }, 0},
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_ADU_500A }, 0},
@@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
+   {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
 
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
@@ -359,7 +361,7 @@ umsm_attach(struct device *parent, struc
printf("%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
} else if ((sc->sc_flag & DEV_TRUINSTALL) &&
-   uaa->ifaceno == 0) {
+   (uaa->ifaceno == 0 || uaa->ifaceno == 9)) {
umsm_truinstall_changemode(uaa->device);
printf("%s: truinstall mode. need to reattach\n",
sc->sc_dev.dv_xname);



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Chris Cappuccio
RD Thrush [openbsd-t...@thrush.com] wrote:
> On 05/13/16 11:07, Theo de Raadt wrote:
> >> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> >> with read-only /usr produces something like the following message:
> >> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
> >> system
> > 
> > Look, your statement is false.  I can install a snapshot right now,
> > and I won't see what you report.
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.
> 
> > That is the result of a mis-configuration on your part.
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 

Robert, what do you suggest?

1. Say sorry, no mitigation because we want to support all possible
configurations

2. Say OK, and provide a work-around in /etc/rc that might (or might not)
work with your situation, and makes the overall situation more complicated
for everyone

3. Say sorry, the mitigation technique will not be changed. You are on your
own.

I think it comes down to this. If you want read-only /etc, you'll have to
modify /etc/rc, if you still want the mitigation.



Re: pledge: telnet should not verify if hostname is a fully qualified domain

2016-05-02 Thread Chris Cappuccio
Adam Wolk [adam.w...@tintagel.pl] wrote:
>
> I would like to just drop that part of code. Any OK's, comments?
> 

Please do. It's utterly useless. ok chris@

> Index: commands.c
> ===
> RCS file: /cvs/src/usr.bin/telnet/commands.c,v
> retrieving revision 1.83
> diff -u -p -r1.83 commands.c
> --- commands.c16 Mar 2016 15:41:11 -  1.83
> +++ commands.c3 May 2016 00:24:51 -
> @@ -1445,14 +1445,6 @@ env_init(void)
>  
>   gethostname(hbuf, sizeof hbuf);
>  
> - /* If this is not the full name, try to get it via DNS */
> - if (strchr(hbuf, '.') == 0) {
> - struct hostent *he = gethostbyname(hbuf);
> - if (he != 0)
> - strncpy(hbuf, he->h_name, sizeof hbuf-1);
> - hbuf[sizeof hbuf-1] = '\0';
> - }
> -
>   if (asprintf (, "%s%s", hbuf, cp2) == -1)
>   err(1, "asprintf");
>  



Re: dc patch

2016-04-25 Thread Chris Cappuccio
Edgar Pettijohn [ed...@pettijohn-web.com] wrote:
> nevermind just found the elusive "q"
> 

There's always the universal ^D



Re: APU1 ethernet LEDs

2016-04-12 Thread Chris Cappuccio
Did you bring this up to Pascal Dornier ? I think he would rather fix
the eeprom...

This is specific to the hardware layout, the eeprom is the right place,
not the driver!

On the other hand, I think the CSR_WRITE_1 is perfectly clear

Stuart Henderson [s...@spacehopper.org] wrote:
> The re(4) variant on the PC Engines APU1, RTL8111E, has a flexible LED
> configuration. The nic's default config seems to be intended for
> controlling 3 LEDs (or one single-colour and a bi-colour LED with
> different colours to indicate link speed) however the ethernet ports
> on the APU1 only have two LEDs (one green one amber).
> 
> Defaults can be changed in eeprom but (intentionally or not) this
> hasn't been done on the APU1 so in normal situations with a 1GB link,
> you only ever see one lit LED, and even that is normally off, only
> blinking for activity. I don't know of any APU users who like
> the default setup.
> 
> Section 6.2.6 of the RTL8111E-VB-GR / -VB-CG / -VC-CG datasheet
> tells us how to reprogramme it. Do we want to change it?
> 
> Without diff:
> 
> green: normally off, blink on for activity.
> amber: on solid for 100MB link, off for 1GB link.
> 
> With diff:
> 
> green: normally on if link at any speed. blink off for activity.
> amber: on solid for 1GB link, otherwise off.
> 
> Some other settings are possible but I think this gives the best
> combination of information under "normal" conditions given only
> 2 LEDs.
> 
> Looking at unique "RTL8168E/8111E (0x2c00)" entries from dmesglog
> back to Feb 2013, there are 7 APUs (=21 NICs), and 20 non-APUs.
> Do we care if we change led state for those others too? We could
> check the MAC vendor for 00:0d:b9, but I think this is unnecessary
> complexity (and who knows, maybe it's an improvement for some of
> those too).
> 
> Any comments/OKs? (I am not 100% happy with the clarity of the new
> CSR_WRITE_1 line, but my earlier iterations were worse ;)
> 



Re: New scheduler for OpenBSD

2016-03-19 Thread Chris Cappuccio
Michal Mazurek [akf...@jasminek.net] wrote:
> On 16:28:33, 14.03.16, Martin Pieuchot wrote:
> > > The number of calls to yield() dropped to 4,576.
> > 
> > This is really similar to what I observed with Firefox and Chrome.
> > 
> > > This is where I get stuck, I don't know how to replace the call to
> > > sched_yield(), or whether it is a good idea to do so. Any advice?
> > 
> > I'd assume the problem is not in the _spinlock() implementation itself
> > but rather on the code calling this lock.  Do you know which code is
> > triggering this?
> > 
> > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a
> > the use of a spinlock created similar symptoms.
> 
> I don't know how to fix it, but in the meanwhile here is a workaround so
> I can continue working on the scheduler. In yield():
> 
> + tmp = p->p_rrticks;
> + sched_deadline(p);
> + p->p_rrticks = tmp;
> 
> So penalise a process calling yield() by giving it the worst deadline,
> i.e. make it go to the end of the run queue.
> 
> Other than this, no changes.
> 
> Chrome still isn't smooth.
> 

On a frankenstein 5.9 kernel with bob beck's latest NOWAIT vfs_biomem buffer 
alloc and this, I'm getting very smooth action on chrome, with video, even on
an old x201. I don't remember the last time it could re-open 20 tabs without
constantly pausing most of itself, or the last time youtube videos would
play on this laptop in chrome, without random and frequenty stuttering.



Re: New scheduler for OpenBSD

2016-03-19 Thread Chris Cappuccio
Bob Beck [b...@openbsd.org] wrote:
> this is cool .. but
> 
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
> 
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern
> would be does this adversely impact how we deal with non-interactive 
> workloads.

I've been testing it on my heavily loaded Zabbix server, which regularly
get dozens of variables from over 5,000 devices. I get mixed results, the
load avg is higher, and the idle cpu time is generally higher, I regularly
see 1 second (top 's 1') CPU idle of 50-70% where I regularly saw 20-50% 
with the old scheduler. This is in top with all cpus collasped into 1 (top
'1'). I suspect if I averaged it over time, the difference could be less   
dramatic.

I'm using Postgres, there is no heavily threaded stuff, so I have
no idea why the idle CPU seems to be higher. The load avg is a bit higher,
it seems to stay up around 48 longer with the new scheduler, and also
shoots up and down more quickly. None of this is particularly well measured,
just a weird observation. With the old scheduler the load avg would fluctuate
from 32-42, and seemed to stay at a particular value for a longer period
of time (whatever that means.)

Zabbix is a horrible pig, and my polling confiuguration is not fine-tuned 
to top it off. The box is a "Xeon E2-1230 v3 @ 3.30GHz" with 16GB RAM and
two Samsung 845DC SSDs in softraid raid1. We use Postgres as a time-series
database, I'm looking at alternatives using collectd and graphite and
whatever, I really want to get away from Zabbix + Postgres.

Since this scheduler has a hack to help spinning threaded apps, that
explains why there is less CPU usage during video playback, but I don't
know how to explain my Zabbix results. It takes at least 2 minutes after
boot before the Zabbix box stabilizes to the levels I'm describing
here. 

If I set top to .1 second (top 's .1') then the new scheduler seems to
drive all CPUs to 0% idle for shorter periods of time, but more
frequently.

These are really rough observations. This box spawns lots of dirty
perl processes and also lots of fping processes for monitoring. I've
not spent the time to optimize this area at all. I was curious if this
scheduler or other OS level optmizations might take away some of the
costs here. With this rather stupid polling architecture, perhaps
copy-on-write is still the biggest win...

Chris



Re: New scheduler for OpenBSD

2016-03-18 Thread Chris Cappuccio
Alexandre Ratchov [a...@caoua.org] wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > 
> > Please test, and let me know if the performance of something else
> > degrades.
> > 
> 
> With your diff firefox consumes twice less cpu (watched the same
> video with and without the diff).  This suggests firefox spins
> somewhere and your diff makes it spin less.
> 
> When audio device is using small blocks it stutters more with your
> diff though; according to device counters the stuttering is caused
> by sndiod not getting the cpu fast enough.

there is no 'nice' functionality at the moment



Re: remove net80211 turbo mode

2016-01-11 Thread Chris Cappuccio
Stuart Henderson [st...@openbsd.org] wrote:
> 
> +1, I wondered if we should do this when reading the 11n diffs.
> 
> If people need more speed it's likely that they will get better
> performance with 20MHz channels on a newer radio/MAC than 40MHz
> on a 10-year-old one.
> 
> Free the spectrum!

i've never seen any significant improvement from the old 40mhz mode,
just much higher noise sensitivity



Re: mpsafe re(4)

2015-12-10 Thread Chris Cappuccio
Dimitris Papastamos [s...@2f30.org] wrote:
> On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote:
> > The main interesting bit here is the txeof and start loops, which previously
> > operated based on the prod/cons indices and the contents of the tx queue,
> > but now just uses the indices as that's the only way to get a consistent 
> > view
> > of the tx queue state.
> > 
> > At the moment I don't think the tx ring is big enough to use IFQ_DEQUEUE
> > instead of ifq_deq_begin/commit, but maybe I'm wrong about that.
> > 
> > can someone try this on an APU1?
> 
> I've tested this on my router and it seems to work okay.  I've also used
> tcpbench with various combinations.
> 
> re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G
> (0x4c00), msi, address 80:ee:73:9f:1d:3e
> re1 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G
> (0x4c00), msi, address 80:ee:73:9f:1d:3d

Testing fine for me on APU1 so far.



Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

2015-11-16 Thread Chris Cappuccio
Noth [nothingn...@citycable.ch] wrote:
> Hi again,
> 
>   I think I've found a bug: if I have a console session open using minicom
> or cu when rebooting, the machine hangs. This doesn't happen with either
> CentOS Linux 7 or FreeBSD 10.2 / 11. I can reproduce the problem. Anyone
> else have this issue ?
> 

The boot loader output is emulated video output until it switches to com0.
Once it reads 'stty com0 115200; set tty com0' from /etc/boot.conf, it 
switches from video output to serial output.

During the switch, some contents comes out of the boot loader that is at
the wrong baud rate (or something similar). This causes some high characters
to come out, which your terminal emulator might interpret as a terminal command
and it could even send a short reply back. If it does, this reply stops the
auto-boot process and you sit at boot> indefinitely.

The solution is to not leave a terminal emulator connected during the boot
(or fix the boot loader to not output high characters)



Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

2015-11-16 Thread Chris Cappuccio
Noth [nothingn...@citycable.ch] wrote:
> No it freezes after the "rebooting..." message appears. It isn't before the
> firmware restarts. Hopefully the next firmware release will some kind of fix
> for this.
> 

The non-ACPI kernel does this (bsd.rd). bsd should not do this



Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

2015-11-14 Thread Chris Cappuccio
Mathias Schmocker [s...@smat.ch] wrote:
> 
> First tests with a bootable OpenBSD amd64 5.8-current USB stick and
> installation on the 16GB mSata internal storage.
> After reboot, BIOS could find mSata to boot on, but defaulted to the memtest
> boot payload
> 

This is a setting you can change, although the default boot order would put 
memtest last.

I've had no problems with apu2 detecting msata so far..

> Unable to abort memtest by pressing (esc) on the serial console, or (c) for
> configure.
> 

You have to escape to the prompt before memtest starts.



Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

2015-11-09 Thread Chris Cappuccio
Brian Conway [bcon...@rcesoftware.com] wrote:
> I meant positioning the whole case bottom-up (i.e. but the hot surface
> at the top).

Oh I see!

I just got a beta unit. I was late to the party. I used some of this
ZM-STG1 thermal grease (comes with a paint applicator type brush) and
the integrated memtest goes between 46 and 47 C. With intel ethernet,
four cores and usb3, this is a pretty nice unit!

I wonder if these are four discrete cores or if AMD is playing games
(like the bulldozer lawsuit as of late.)

Chris



Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

2015-11-09 Thread Chris Cappuccio
Brian Conway [bcon...@rcesoftware.com] wrote:
> 
> Taking into account Mr. Cappuccio's advice on using thermal paste
> between the CPU and heat spreader, and also positioning it bottom-up,
> this one stabilized at 51 C at idle. I haven't had a chance to do much
> benchmarking for higher temps yet, other than a run of `openssl speed`
> to warm it up.

If you put the heat speader upside down, the sticky pad would be against
the cpu heatsink contact area?? There's only one way to put that device in.



Re: restricting DNS to port 53

2015-11-04 Thread Chris Cappuccio
gwes [g...@oat.com] wrote:
> Will unbound and nsd be restricted to port 53 only?
> 

No



Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

2015-11-04 Thread Chris Cappuccio
Noth,
I got my APU (first rev) to go from 56-58 temps down to 49-50 by using heatsink 
paste instead of the thermal pad...

Noth [nothingn...@citycable.ch] wrote:
> Thanks Stuart, that works for me!
> 
> # sysctl hw
> hw.machine=amd64
> hw.model=AMD GX-412TC SOC
> hw.ncpu=4
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:47e18331a1a8156e
> hw.diskcount=1
> hw.sensors.km0.temp0=59.38 degC
> hw.cpuspeed=998
> hw.setperf=100
> hw.vendor=PC Engines
> hw.product=apu2
> hw.version=1.0
> hw.serialno=123456789
> hw.physmem=4261081088
> hw.usermem=4261056512
> hw.ncpufound=4
> hw.allowpowerdown=1
> hw.perfpolicy=manual
> 
> On 04/11/15 18:47, Stuart Henderson wrote:
> >this will probably get you a cpu temperature sensor.
> >
> >Index: km.c
> >===
> >RCS file: /cvs/src/sys/dev/pci/km.c,v
> >retrieving revision 1.10
> >diff -u -p -r1.10 km.c
> >--- km.c 14 Mar 2015 03:38:48 -  1.10
> >+++ km.c 4 Nov 2015 17:44:25 -
> >@@ -72,7 +72,8 @@ static const struct pci_matchid km_devic
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_14_MISC },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_0x_MISC },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_1x_MISC },
> >-{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_MISC }
> >+{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_MISC },
> >+{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_3X_MISC }
> >  };
> >



Re: Purge route entries when an address is removed

2015-09-14 Thread Chris Cappuccio
Martin Pieuchot [m...@openbsd.org] wrote:
> Currently we leave RTF_STATIC route entries in the table when the
> address they are attached to is removed from a system.
> 
> That's why ifas need to be refcounted and that's why we have *a lot*
> of checks in the stack to not use cached routes attached to such ifa.
> 
> I'd like to simplify all of this by simply purging all the routes
> attached to an ifa being removed.  This behavior is coherent with
> the fact that routes *need* an ifa to be inserted in the table.
> 
> This makes the kernel simpler as it no longer try to find a new ifa
> when a route with a stale address is being used.
> 

I'm pretty sure this feature has been broken for a while. Once upon
a time in OpenBSD, this used to work:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
ping 8.8.8.8
reply!

For some years, this has been required:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8  
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
**route delete default**
**route add default 192.168.1.1**
ping 8.8.8.8
reply!

It appears, what you're proposing is:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
**route add default 192.168.1.1**
ping 8.8.8.8
reply!

As a user (only), I really like the original behavior, it seems to be
consistent with the behavior of some other systems, at least in the case
of the default router. If there was some way to do this without stupid
complexity, it might be worth considering.

In any event, what you propose seems much better than the current state
of affairs, where you end up with broken routes in the table that need
nothing more than to be removed.

Chris



Re: whois(1): fix lookup of XX.network

2015-08-19 Thread Chris Cappuccio
Stuart Henderson [st...@openbsd.org] wrote:
 When I added code to use whois.nic.XX for new TLDs I forgot to think
 about one case, where the TLD is a substring of one of the traditional
 TLDs who have to use the old whois-servers.net method. Specifically,
 trying to lookup a .network name will incorrectly try to use
 network.whois-servers.net - strncasecmp was the wrong decision,
 so this diff switches to strcasecmp instead to fix. They're all
 null-terminated strings.
 

Makes perfect sense
ok chris@



Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-07 Thread Chris Cappuccio
Maxime Villard [m...@m00nbsd.net] wrote:
 
 Now, I believe that this effort is too much for my spare time. If you
 want to say thanks to me for reporting this vulnerability, dear Sam,
 it's never too late.
 

I put here a thanks among others:

Thank you for your effort to help improve the OpenBSD operating system,
to the benefit of its users, developers, and the many others who are
using the code in their own systems. Your work is appreciated, each
commit fixing a bug that you found is perhaps the spiritual thank-you
of which you have detected the subtle presence :)

Chris



Re: softdep by default on AMD64

2015-07-28 Thread Chris Cappuccio
?? ?? [art.is...@yandex.ru] wrote:
 On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote:
  generally reliable HAHAHAHAHA
 
 Why irony? It's more or less true for ALL modern computing system.

Think of it as a selling point. OpenBSD ffs softdep: On the cutting
edge of reliability!



Re: Kill arp_ifinit()?

2015-07-15 Thread Chris Cappuccio
Martin Pieuchot [m...@openbsd.org] wrote:
 On 07/07/15(Tue) 18:02, Martin Pieuchot wrote:
  Maybe not yet but at least I'd like to do the ARP request a bit later.
  
  We create a RTF_LOCAL route entry for every configured address.  So
  use this information to emit a who-has for the configured address.
  
  This also has the advantage of *not* sending an ARP request if 
  something wrong happens between the SIOCSIFADDR ioctl and the
  RTF_LOCAL route creation.
 
 Anybody?
 

Looks ok to me!!



Re: [PATCH] fix write error handling on SR RAID1

2015-07-10 Thread Chris Cappuccio
Karel Gardas [gard...@gmail.com] wrote:
 Hello,
 
 I think I've found a bug on software RAID1 implementation of handling
 write errors. IMHO code should check if every write to every chunk
 succeed. If not, then there is an error which it needs to handle.
 Proposed patch handles such error by off-lining the problematic drive.
 The patch compiles on current, but so far it's not tested at all -- I
 send it to get some advice from developers if this is the way to go or
 not and if so, then how exactly proceed with patch send etc.
 

My first impression, offlining the drive after a single chunk failure
may be too aggressive as some errors are a result of issues other than
drive failures. 



Re: Better de(4) fix

2015-06-25 Thread Chris Cappuccio
Why do we still prefer de over dc for 211140 ?

Reyk Floeter [r...@openbsd.org] wrote:
 On Thu, Jun 25, 2015 at 09:21:11PM +0200, Mark Kettenis wrote:
  There really is no excuse for using dma_alloc(9) if you have the
  bus_dmatag_t available.
  
  This re-uses tulip_busdma_allocmem(), which simplifies the code for
  allocating the dmamap and such.
  
  Unfortunately I can't test this myself right now.
  
 
 Fixes the panic on Hyper-V, see dmesg below.
 
 Unrelated to that, no interrupts on the nic with the ioapic enabled
 (no traffic and autoneg timeouts).  
 
 Reyk
 
 OpenBSD 5.8-beta (GENERIC.MP) #7: Thu Jun 25 22:03:02 CEST 2015
 root@openbsd.hyperv:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8573091840 (8175MB)
 avail mem = 8309399552 (7924MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf8ec0 (216 entries)
 bios0: vendor American Megatrends Inc. version 090006 date 05/23/2012
 bios0: Microsoft Corporation Virtual Machine
 acpi0 at bios0: rev 0
 acpi0: sleep states S0 S5
 acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
 acpi0: wakeup devices
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 1645.76 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,RTM
 cpu0: 256KB 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 106MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 1745.46 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,RTM
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 0, package 1
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
 ioapic0: misconfigured as apic 2, remapped to apid 0
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpicpu0 at acpi0
 acpicpu1 at acpi0
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel 82443BX rev 0x03
 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x01
 pciide0 at pci0 dev 7 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: Virtual HD
 wd0: 128-sector PIO, LBA48, 10240MB, 20971520 sectors
 wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
 atapiscsi0 at pciide0 channel 1 drive 0
 scsibus1 at atapiscsi0: 2 targets
 cd0 at scsibus1 targ 0 lun 0: Msft, Virtual CD/ROM, 1.0 ATAPI 5/cdrom 
 removable
 cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
 piixpm0 at pci0 dev 7 function 3 Intel 82371AB Power rev 0x02: SMBus 
 disabled
 vga1 at pci0 dev 8 function 0 Microsoft VGA rev 0x00
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 de0 at pci0 dev 10 function 0 DEC 21140 rev 0x20, 21140A pass 2.0: apic 0 
 int 11, address 00:15:5d:01:9b:03
 isa0 at pcib0
 isadma0 at isa0
 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
 fd1 at fdc0 drive 1: density unknown
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
 pckbc0 at isa0 port 0x60/5 irq 1 irq 12
 pckbd0 at pckbc0 (kbd slot)
 wskbd0 at pckbd0: console keyboard, using wsdisplay0
 pms0 at pckbc0 (aux slot)
 wsmouse0 at pms0 mux 0
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 vscsi0 at root
 scsibus2 at vscsi0: 256 targets
 softraid0 at root
 scsibus3 at softraid0: 256 targets
 root on wd0a (02632bce06e92172.a) swap on wd0b dump on wd0b
 
 

-- 
The bums will always lose



Re: pfi_kif leaks for PBR rules

2015-04-05 Thread Chris Cappuccio
Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
 
 is missing at pfr_destroy_kentry(). We created patch against OpenBSD CURRENT.
 We have no OpenBSD boxes around, where we could verify our fix.
 

You are aware that OpenBSD supports both host and guest roles of
Sparc system virtualization ? Quite easy to install, I might add,
it's very simple to setup. As a host of virtual guests, it also
supports a bit of modern Sparc hardware, out-of-the-box.

Chris



Re: rtentry leak

2014-11-06 Thread Chris Cappuccio
Martin Pieuchot [mpieuc...@nolizard.org] wrote:
 
 Indeed!  And the ifa might also be freed so this chunk is completely
 wrong.  Here's a version of the diff without it, ok?
 

This looks ok to me

 
 Index: net/route.c
 ===
 RCS file: /home/ncvs/src/sys/net/route.c,v
 retrieving revision 1.189
 diff -u -p -r1.189 route.c
 --- net/route.c   4 Nov 2014 15:24:40 -   1.189
 +++ net/route.c   6 Nov 2014 10:24:02 -
 @@ -215,7 +215,7 @@ route_init(void)
  {
   struct domain*dom;
  
 - pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtent,
 + pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtentry,
   NULL);
   rn_init();  /* initialize all zeroes, all ones, mask table */
  
 @@ -1220,7 +1220,7 @@ rt_ifa_addloop(struct ifaddr *ifa)
   if (rt == NULL || !ISSET(rt-rt_flags, flags));
   rt_ifa_add(ifa, RTF_UP | flags, ifa-ifa_addr);
   if (rt)
 - rt-rt_refcnt--;
 + rtfree(rt);
  }
  
  /*
 @@ -1267,7 +1267,7 @@ rt_ifa_delloop(struct ifaddr *ifa)
   if (rt != NULL  ISSET(rt-rt_flags, flags))
   rt_ifa_del(ifa, flags, ifa-ifa_addr);
   if (rt)
 - rt-rt_refcnt--;
 + rtfree(rt);
  }
  
  /*

-- 
The bums will always lose



Re: LibreSSL: GOST ciphers implementation

2014-11-05 Thread Chris Cappuccio
?? ?? [art.is...@yandex.ru] wrote:
 On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote:
   Two weeks has passed. Is there anything that I can do to
   push GOST ciphers towards LibreSSL?
  
  Sorry about that. Joel and/or I need to review the diff again and push
  it. I'll try to find time for this next week-end (famous last words).
  
  Miod
 
 This is suspicious person for me (group of people?). There are lots of
 commits since about 2011 in many low-level and/or critical components
 from this person: linux kernel, android, gnupg, tcpdump, alsa, tor,
 openssl etc, etc..
 
 I'm almost certainly wrong, but not too much there competencies for one
 person?

So, you're saying, he's really dmi...@svr.gov.ru, the source of Russian
backdoors into technology worldwide!!!

I guess the open-source ecosystem has been thoroughly poisoned!

Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm
switching to Windows 8.



Re: rtentry leak

2014-11-05 Thread Chris Cappuccio
Martin Pieuchot [mpieuc...@nolizard.org] wrote:
 
 @@ -653,12 +653,12 @@ ifa_ifwithroute(int flags, struct sockad
   struct rtentry  *rt = rtalloc(gateway, 0, rtableid);
   if (rt == NULL)
   return (NULL);
 - rt-rt_refcnt--;
   /* The gateway must be local if the same address family. */
   if ((rt-rt_flags  RTF_GATEWAY) 
   rt_key(rt)-sa_family == dst-sa_family)
   return (NULL);

And
if ((rt-rt_flags  RTF_GATEWAY) 
rt_key(rt)-sa_family == dst-sa_family) {
+   rtfree(rt);
return (NULL);
}


   ifa = rt-rt_ifa;
 + rtfree(rt);
   if (ifa == NULL || ifa-ifa_ifp == NULL)
   return (NULL);



Re: need help setting an encrypted root FS on dual boot system

2014-11-05 Thread Chris Cappuccio
Matthieu Herrb [matth...@herrb.eu] wrote:
 Hi,
 
 I've a laptop with  Ubuntu 14.04/OpenBSD-current dual boot. 
 I'm trying to convert the OpenBSD FS to softraid(4) encryption with
 passphrase.
 
 I'm booting from an USB drive to access the disk to shuffle data on
 it. 
 
 After backing up my data, changing the OpenBSD disklabel in sd0 to
 have one RAID partition and one swap partition, running bioctl to
 setup an encrypted sd2 softraid and restoring my data, I'm stuck with 
 bootblocks. 
 
 What is the correct installboot incantation to setup bootblocks so
 that Ubuuntu's grub which chainloads the OpenBSD part of the disk
 loads a softraid-aware biosboot ?
 

Doesn't installboot load the first-stage at the beginning of the OpenBSD
partition according to disklabel? Grub is just replacing the MBR. I don't
understand how crypto would make grub-first-stage step any different.
(for that matter, I also don't understand how the first-stage can even
load the second-stage /boot from an encrypted partition!!)



Re: pppoe(4), add example for ipv6

2014-10-21 Thread Chris Cappuccio
Stuart Henderson [st...@openbsd.org] wrote:
 Any comments on the diff in this?
 
  +#ifdef INET6
  +   sc-sc_sppp.pp_if.if_xflags = ~IFXF_NOINET6;
  +#endif

Aside from what Stefan said, isn't this flag going to be removed
in favor of a flag that explicitly enables INET6 for interfaces?



Re: improving OpenBSD's gmac.c...

2014-10-09 Thread Chris Cappuccio
Christian Weisgerber [na...@mips.inka.de] wrote:
 John-Mark Gurney:
 
  I also have an implementation of ghash that does a 4 bit lookup table
  version with the table split between cache lines in p4 at:
  https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4
  
  This also has a version with does 4 blocks at a time getting a
  further speed up...
 
 FWIW, I did a quick  dirty merge of this into the OpenBSD tree and
 the speed of my test (net6501-50, tcpbench -u over esp aes-128-gmac)
 almost doubled.
 

That makes me horny.



Re: re(4) mtu 1500

2014-10-07 Thread Chris Cappuccio
I like MIMO/SISO better than 1x1 2x2 etc. Fix that shit :)

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/10/06 12:19, Chris Cappuccio wrote:
  Stuart Henderson [s...@spacehopper.org] wrote:
   Does anyone have an idea of what's needed for working jumbos on the
   RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled?
   These seem to account for most of the chips seen in hardware
   designs from the last couple of years (including APU and some others).
   
   if ((sc-rl_flags  RL_FLAG_JUMBOV2) == 0)
   ifp-if_hardmtu = sc-rl_max_mtu;
   
  
  I think the secrets are here :)
  
  http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461view=markup
  
 
 Ah, more specifically
 
 http://svnweb.freebsd.org/base?view=revisionrevision=217499 /
 http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498r2=217499pathrev=217499
 
 OK that's probably more than I can figure out how to port without
 hardware then..

-- 
The bums will always lose



Re: re(4) mtu 1500

2014-10-06 Thread Chris Cappuccio
Stuart Henderson [s...@spacehopper.org] wrote:
 Does anyone have an idea of what's needed for working jumbos on the
 RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled?
 These seem to account for most of the chips seen in hardware
 designs from the last couple of years (including APU and some others).
 
 if ((sc-rl_flags  RL_FLAG_JUMBOV2) == 0)
 ifp-if_hardmtu = sc-rl_max_mtu;
 

I think the secrets are here :)

http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461view=markup



Re: deprecate scsi_task usage in arc(4)

2014-09-09 Thread Chris Cappuccio
David Gwynne [da...@gwynne.id.au] wrote:
 can someone test this?
 

Running now.

arc0 at pci3 dev 14 function 0 Areca ARC-1210 rev 0x00: apic 8 int 19
arc0: 4 ports, 256MB SDRAM, firmware V1.43 2007-4-17
scsibus1 at arc0: 16 targets
sd0 at scsibus1 targ 0 lun 0: Areca, ARC-1210-VOL#00, R001 SCSI3 0/direct 
fixed eui.0004d927f800
sd0: 953674MB, 512 bytes/sector, 1953124864 sectors
...
# bioctl arc0
Volume  Status   Size Device  
 arc0 0 Online   99930368 sd0 RAID1 
  0 Online  1000204886016 0:0.0   noencl ST31000528AS CC38
  1 Online  1000204886016 0:1.0   noencl ST31000528AS CC38
# sysctl hw.sensors.arc0
hw.sensors.arc0.drive0=online (sd0), OK

Chris



Re: SSH Sourcing

2014-09-09 Thread Chris Cappuccio
Nagle, Edwin (James) [edwin.na...@austinenergy.com] wrote:
 Good morning,
 
 My problem is, I am separating users based on interface IP and radius, and 
 therefore need to force their outbound SSH sessions to bind to the IP address 
 of the interface they came in on (or at least a different IP) so I can create 
 firewall rules to restrict outbound access.  However, all outbound SSH 
 sessions are sourced through the default (bnx0) interface and therefore 
 hamper my ability to effectively firewall the outbound SSH requests since the 
 user could be in one of three firewall groups.  I may be just thinking too 
 hard about this but it seems to me there should be (and likely is) a simple 
 way to bind the outgoing connection from the source address.
 
 Any ideas, or should I just create three virtual machines and be done with it?
 
 Again, thanks in advance for any guidance!
 

If each user ID is correlated with a separate IP, you could run different sshd 
each which only allows certain users to log in, and then use pf to restrict 
each user in certain ways. 



Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

2014-08-21 Thread Chris Cappuccio
Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/08/20 17:17, Chris Cappuccio wrote:
  David Gwynne [da...@gwynne.id.au] wrote:
   sthen@ says this is likely a bit optimistic. while most of our drivers 
   unconditionally configure their max mru, there's some stupid ones that 
   still interpret the configured mtu as a what the mru should be.
   
  
  All the more reason to make this change, I'd say :)
 
 it's not just that - there are some like et(4) with obvious trade-offs visible
 in the driver source code which are only wanted in the case where jumbos are
 actually in use. and who knows what various chips will do internally when the
 command to permit jumbos or raise the valid packet size is sent.
 

I don't think this is relevant. If a chip or driver is buggy in the jumbo MTU
non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU
case as well

 that said, there is a clear use case for being able to do 1500 MTU packets
 untagged while using jumbos on a vlan...

Yeah



Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

2014-08-21 Thread Chris Cappuccio
Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/08/21 08:45, Chris Cappuccio wrote:
  Stuart Henderson [st...@openbsd.org] wrote:
   On 2014/08/20 17:17, Chris Cappuccio wrote:
David Gwynne [da...@gwynne.id.au] wrote:
 sthen@ says this is likely a bit optimistic. while most of our 
 drivers unconditionally configure their max mru, there's some stupid 
 ones that still interpret the configured mtu as a what the mru should 
 be.
 

All the more reason to make this change, I'd say :)
   
   it's not just that - there are some like et(4) with obvious trade-offs 
   visible
   in the driver source code which are only wanted in the case where jumbos 
   are
   actually in use. and who knows what various chips will do internally when 
   the
   command to permit jumbos or raise the valid packet size is sent.
   
  
  I don't think this is relevant. If a chip or driver is buggy in the jumbo 
  MTU
  non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU
  case as well
 
 Oh I was thinking of the case where we changed those drivers to fix things
 so that the 1500 MTU untagged / high MTU tagged state worked which would
 involve downsides for non-jumbo. If you don't care if the new support
 actually works on some chips then that wouldn't apply..
 

Well in the case of if_et, the change the dlg proposes in if_vlan would not
make a difference to the if_et behavior at all. My first glance at et says
hardmtu == mtu 



Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

2014-08-20 Thread Chris Cappuccio
ok chris@ 

David Gwynne [da...@gwynne.id.au] wrote:
 this lets you have networks on the native vlan on an interface
 at 1500, while setting a child vlan interfaces mtu to jumbos.
 
 ok?
 
 Index: if_vlan.c
 ===
 RCS file: /cvs/src/sys/net/if_vlan.c,v
 retrieving revision 1.108
 diff -u -p -r1.108 if_vlan.c
 --- if_vlan.c 12 Jul 2014 18:44:22 -  1.108
 +++ if_vlan.c 19 Aug 2014 23:52:15 -
 @@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
   case SIOCSIFMTU:
   if (ifv-ifv_p != NULL) {
   if (ifv-ifv_p-if_capabilities  IFCAP_VLAN_MTU)
 - p_mtu = ifv-ifv_p-if_mtu;
 + p_mtu = ifv-ifv_p-if_hardmtu;
   else
 - p_mtu = ifv-ifv_p-if_mtu - EVL_ENCAPLEN;
 + p_mtu = ifv-ifv_p-if_hardmtu - EVL_ENCAPLEN;
   
   if (ifr-ifr_mtu  p_mtu || ifr-ifr_mtu  ETHERMIN)
   error = EINVAL;



Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

2014-08-20 Thread Chris Cappuccio
David Gwynne [da...@gwynne.id.au] wrote:
 sthen@ says this is likely a bit optimistic. while most of our drivers 
 unconditionally configure their max mru, there's some stupid ones that still 
 interpret the configured mtu as a what the mru should be.
 

All the more reason to make this change, I'd say :)



Re: IEEE80211_DEBUG

2014-07-23 Thread Chris Cappuccio
Nathanael Rensen [nathan...@list.polymorpheus.com] wrote:
 The IEEE80211_DEBUG kernel option needs a little help to compile.
 
 Index: ieee80211_pae_input.c
 ===
 RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
 retrieving revision 1.19
 diff -u -p -r1.19 ieee80211_pae_input.c
 --- ieee80211_pae_input.c 22 Jul 2014 11:06:10 -  1.19
 +++ ieee80211_pae_input.c 23 Jul 2014 14:25:22 -
 @@ -978,7 +978,7 @@ ieee80211_recv_group_msg2(struct ieee802
  
   /* discard if we're not expecting this message */
   if (ni-ni_rsn_gstate != RSNA_REKEYNEGOTIATING) {
 - DPRINTF((%s: unexpected in state: %d\n, ni-ni_rsn_gstate));
 + DPRINTF((unexpected in state: %d\n, ni-ni_rsn_gstate));

probably want this:
+   DPRINTF((%s: unexpected in state: %d\n, ic-ic_if.if_xname,
+   ni-ni_rsn_gstate));



Re: diff: Fix udp_usrreq.c to compile without IPSEC.

2014-06-23 Thread Chris Cappuccio
If you really want to be pedantic, it should be if defined(PIPEX) || 
defined(IPSEC)

YASUOKA Masahiko [yasu...@yasuoka.net] wrote:
 ok?
 
 Fix compile without IPSEC.
 
 Pointed out by Ivan Solonin.
 
 Index: sys/netinet/udp_usrreq.c
 ===
 RCS file: /disk/cvs/openbsd/src/sys/netinet/udp_usrreq.c,v
 retrieving revision 1.184
 diff -u -p -r1.184 udp_usrreq.c
 --- sys/netinet/udp_usrreq.c  23 Apr 2014 12:25:35 -  1.184
 +++ sys/netinet/udp_usrreq.c  23 Jun 2014 02:17:06 -
 @@ -186,9 +186,9 @@ udp_input(struct mbuf *m, ...)
   struct m_tag *mtag;
   struct tdb_ident *tdbi;
   struct tdb *tdb;
 +#endif /* IPSEC */
   int error;
   u_int32_t ipsecflowinfo = 0;
 -#endif /* IPSEC */
  
   va_start(ap, m);
   iphlen = va_arg(ap, int);

-- 
If you see fraud and don't shout fraud, you are a fraud -- Nassim Taleb



Re: new OpenSSL flaws

2014-06-05 Thread Chris Cappuccio
Miod Vallat [m...@online.fr] wrote:
  Now you have and example of how they are unwilling to work with you next
  time someone asks why not work with OpenSSL on fixing it.  Pretty direct
  proof.
 
 The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE.
 
 We believe in peer review; they don't give a sh*t about it (as shown
 less than a month ago by the way their #3317 bug was fixed, commiting a
 different fix from the proposed one and introducing a stupid *and
 obvious* bug in the process - which got fixed the next day after otto@
 mentioned it to the OpenSSL developers).
 
 If you can't trust people to apply one-liner fixes correctly, can you
 trust them for anything serious?

I think this Networkworld article says it all... (and since when
did interesting, critical analysis come from Networkworld!?)

http://www.networkworld.com/article/2360229/microsoft-subnet/critical-flaw-in-encryption-has-been-in-openssl-code-for-over-15-years.html

If you don't think that Robin Seggelmann is a paid stooge actively
trying to sabotage OpenSSL (an idea rooted in paranoia?) then you
may at least think he is careless, unable to use critical thought,
and certainly doesn't need commit access to any source code repository.
Am I late to the party? Or is it time to re-audit every single character
of his code?

In the mean time, let Dr. Stephen N. Strangelove continue his mad
plan to support VMS and Windows 3.1. Let him play games with LibreSSL
competitors by denying advance notice. Perhaps next time Otto won't
bother to inform them about their new stupid, obvious flaws in return?
It's low class for Dr. Strangelove and his team to behave like this,
after the many repetitive attempts from @openbsd.org to bring OpenSSL
into the new century.

OpenSSH became the de-facto standard because it was the only serious
free alternative for a long time. OpenSSL has always been free. So the
culture difference is precisely what will drive people for, or away
from OpenSSL. (People from the culture of supporting ancient software
and broken standards are going to choose OpenSSL every time!)



Re: that private mailing list

2014-06-05 Thread Chris Cappuccio
Theo de Raadt [dera...@cvs.openbsd.org] wrote:
 From: Solar Designer so...@openwall.com
 To: Theo de Raadt dera...@cvs.openbsd.org
 
 Hi Theo,
 
 I can't comment about OpenSSL folks, but my own impression certainly was
 that you didn't want your project to be provided advance notification -
 not only via distros list, but at all.  Now you're saying you actually
 wanted folks on your team to be notified, just not you personally.  Hmm?

Really?

Let's see it. I'm questioning your judgment after reading the next bit.

 As you had mentioned to me in the private discussion when stu@ wanted to
 get OpenBSD onto distros, you didn't want folks on your team to accept
 any kind of embargo.  I wish we had that discussion in public, as I had
 suggested at the time.  You objected to that.  (And I understand that
 with that discussion in public you might not have been willing to blame
 some others in it, which would possibly hamper my understanding of your
 position.  So your objection did make some sense.)  Now you appear to be
 misinforming folks on your own team (I hope not intentionally) that
 those evil people on distros list and OpenSSL maintainers deliberately
 didn't want to notify you.  You might be right about OpenSSL maintainers
 (although I think you are not) - I just don't know, and can't speak for
 them - but at least for me (as someone who was notified via distros
 list) it appeared that you actually didn't want your team to be notified
 in a manner that would impose any restrictions on when you can commit a
 fix.  So, believe it or not, it didn't even occur to me to put your
 project in a position where your folks would be asked to accept an
 embargo, which you didn't want.
 

This reads like some kind of strange combination of arbitrary logic
and reasoning to justify this in your own mind.

Firstly, an embargo is crap and you know it. That implies a formal
process with contracts and legal implications. (More plainly, did YOU sign?)

A heads-up from OpenSSL to the key people is all it would have taken.
(Sorry, I guess that's only appropriate when those key people aren't aiming
at improving their shitty product.)

 Would you like me to suggest (to whoever reports an issue) that someone
 on your team (who?) be notified next time an OpenSSL issue is brought up
 on distros?  (It doesn't have to be one person on your team - it can be
 several.  This is to address Bob's comment on your lists.)  What about
 issues in other projects (not OpenSSL)?  Which other projects would you
 also like notifications about?
 
 It appears that you've made a (political) decision for your projects not
 to join distros (or possibly any such channels in general), but are now
 asking for people/projects to be notifying your folks anyway when
 appropriate (whatever that means), and this is difficult for everyone.
 
 How do you suggest we make things better (in whatever sense you like)
 going forward?
 

Seriously?

I think the situation here is PLAINLY OBVIOUS.

Here in the real world, key OpenBSD members should be trusted to
do the RIGHT THING in a typical situation like this.

This isn't the first time this has happened nor the last time it will.

Hopefully next time someone has common sense.

I think we can all agree, OpenSSH has been successful at mitigating
this same kind of problem with ALL of the other players.

Maybe you need some coffee?

Chris



Re: IPv6 by default

2014-04-28 Thread Chris Cappuccio
Kenneth Westerback [kwesterb...@gmail.com] wrote:
 
 Why is the burden on everyone to provide 'valid' objections? Should
 not the burden be on you to at least hint at a point to this change?
 Given the miniscule IPv6 usage out there, why should IPv6 come first?
 

I like how IPv6 support turns primary and secondary DNS caches from
a redundancy feature for clients to dual points of failure (for some
resolver implementations.) No response from either server for the first
AF you try? Just wait for a full time out before you try the second AF!



Re: iked + isakmpd on the same machine

2014-04-24 Thread Chris Cappuccio
Mike Belopuhov [m...@belopuhov.com] wrote:
 
 more like it's not supported and is not supposed to work.
 it's like running nginx and apache at the same time

hey, nginx and httpd run concurrently quite fine on
different IP addresses, same box :)



ahci BSY retry

2014-04-23 Thread Chris Cappuccio
Peter J. Philipp recently ran into this on his Intel AHCI+Intel SSD
system (see misc from yesterday):

ahci2 at pci0 dev 31 function 2 Intel 8 Series AHCI rev 0x05: msi, AHCI 1.3
ahci2: device on port 1 didn't come ready, TFD: 0x80BSY
ahci2: stopping the port, softreset slot 31 was still active.
ahci2: unable to communicate with device on port 1

I've seen this on boot with Intel AHCI and Transcend SSD and others
have seen it with Intel AHCI+Intel SSD on soekris net6501.

Here's a simple fix based on Dragonfly's fix for the same problem.
(Try to restablish communication one more time.)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/f2dba7003b2add226b3999a41a99fd278cc5a26f

Dragonfly will only reset here on startup, whereas OpenBSD will
call this to reset ports after startup. This symptom occurred to
me during 24 hour heavy 100% read+write utilization on softraid
RAID1 configuration, with regular SATA disks. So if we are going 
to call ahci_port_portreset during operation, this seems prudent.

Index: ahci.c
===
RCS file: /cvs/src/sys/dev/ic/ahci.c,v
retrieving revision 1.13
diff -u -r1.13 ahci.c
--- ahci.c  14 Apr 2014 04:42:22 -  1.13
+++ ahci.c  23 Apr 2014 14:11:16 -
@@ -1363,7 +1363,7 @@
 ahci_port_portreset(struct ahci_port *ap, int pmp)
 {
u_int32_t   cmd, r;
-   int rc, s;
+   int rc, s, retries = 0;
 
s = splbio();
DPRINTF(AHCI_D_VERBOSE, %s: port reset\n, PORTNAME(ap));
@@ -1378,6 +1378,10 @@
ahci_pwrite(ap, AHCI_PREG_SCTL, 0);
delay(1);
r = AHCI_PREG_SCTL_IPM_DISABLED | AHCI_PREG_SCTL_DET_INIT;
+
+   ahci_pwrite(ap, AHCI_PREG_SCTL, r);
+retry:
+   delay(1);
if ((ap-ap_sc-sc_dev.dv_cfdata-cf_flags  0x01) != 0) {
DPRINTF(AHCI_D_VERBOSE, %s: forcing GEN1\n, PORTNAME(ap));
r |= AHCI_PREG_SCTL_SPD_GEN1;
@@ -1411,6 +1415,10 @@
/* even if the device doesn't wake up, check if there's
 * a port multiplier there
 */
+   if (retries == 0) {
+   retries = 1;
+   goto retry;
+   }
rc = EBUSY;
} else {
rc = 0;



Re: OpenBSD Foundation 2014 Fundraising Campaign.

2014-04-12 Thread Chris Cappuccio
nobody [openbsd.as.a.desk...@gmail.com] wrote:
 Hi all,
 
 -
 1)
 If I search for openbsdfoundation on:
 
 - Facebook
 - Twitter
 - Youtube
 - Instagram
 - Flickr
 - Slideshare
 - etc..
 
 I get ZERO results regarding the topic.
 

I was thinking, maybe a superbowl commercial.



Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

2014-03-18 Thread Chris Cappuccio
sven falempin [sven.falem...@gmail.com] wrote:
 Some issue here, using install55.fs (today 18/3/2014 downloaded snaps)
 
 boot is ok (warn: entropy file missing)
 
 but /dev has no /dev/sd1 (is the usb key) and so i cannot look for the sets .
 
 I did MAKEDEV all so i can mount keys to get the dmesg.
 

The install script will create the devices on demand, as needed to mount
the source sets

 currently outputing dmesg on usb3 key, the machine has no plug for the
 com port, no idea how to get the boot infos (i am bad at soldering)
 
 I fdisk the key, but i cannot disklabel it ( out of inode )
 

This is because you ran MAKEDEV all, the ramdisk has only minimal inodes 
available



Re: Boot network for remote unlock of fde

2014-03-05 Thread Chris Cappuccio
Giancarlo Razzolini [grazzol...@gmail.com] wrote:
 
 One byproduct of such design would be the possibility of redirecting the
 console to the ssh connection. I know this is deranging from the initial
 idea, but make perfect sense. Anyway, I noted your concerns on this.
 Now, anyone have any design idea for implementing this?
 

Personally I think this sort-of soft-IPMI is a pretty cool idea and I found
Matthieu's reply enlightening as well.

Apparently Linux has made some progress beyond pivot_root and there are
some interesting ideas there. (Note that we have a functioning tmpfs.)

http://www.spinics.net/lists/util-linux-ng/msg08794.html

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Evolving the kernel ramdisk to extract archive to a tmpfs might be the right
thing to do if the BSD tmpfs has the same advantages (doesn't run the
backing store back through the buffer cache etc.)



Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

2014-03-03 Thread Chris Cappuccio
Loganaden Velvindron [logana...@gmail.com] wrote:
 
 That's OpenBSD -current right ? I'm going to test it in the afternoon,
 as the CDROM
 drive has issues on my OpenBSD development machine.
 

Yes. The correct .fs images for testing are now the i386 and amd64 snapshot
versions on the OpenBSD sites. 



  1   2   >