Todd C. Miller [mill...@openbsd.org] wrote:
> On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:
>
> > Presumably 465 should be treated the same, though the hardcoded ports
> > don't feel entirely right here - this is presumably something that would
> > want adding for any connection whic
Can you try compiling without this:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_wg.c.diff?r1=1.29&r2=1.30
Kirill Miazine [k...@krot.org] wrote:
> Recently on snapshots I have noticed that ifconfig wgN destroy would just
> hang there, without any way to get back the control. Power res
Jan Klemkow [j.klem...@wemelug.de] wrote:
> +#if NVLAN > 0
> + if (ext.evh)
> + hdrlen += ETHER_VLAN_ENCAP_LEN;
> +#endif
> if (ext.ip4)
> hdrlen += ext.ip4->ip_hl <<
Jan Klemkow [j.klem...@wemelug.de] wrote:
> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
> > On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
> > > I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe
> > > it's just because I had to type that lo
Klemens Nanni [k...@openbsd.org] wrote:
> On Sun, May 07, 2023 at 06:22:55PM +0200, Mark Kettenis wrote:
> > > Date: Sat, 6 May 2023 22:47:55 +
> > > From: Klemens Nanni
> > >
> > > On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote:
> > > > Installing to a wiped disk on EFI machi
Paul de Weerd [we...@weirdnet.nl] wrote:
> My new motherboard has a 10GB/s interface that doesn't work with
> -current. It's this thing:
>
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=bf2320a60e687760400cf964ec3e60ceccb90f93
i...@tutanota.com [i...@tutanota.com] wrote:
>
> Is it a condition for code to go into the OpenBSD source tree (not
> talking about ports) that at least one other developer has reviewed the
> code?
>
Yes
> Is there a process in place to guarantee this?
>
Yes, manual review all the way down.
I
Klemens Nanni [k...@openbsd.org] wrote:
> Reading "at boot time" may come off as "in the bootloader"
> -Do not automatically assemble this volume at boot time.
> +Do not automatically assemble this volume at system startup time.
I don't think this reads any different. If you want to be very
clear
Klemens Nanni [k...@openbsd.org] wrote:
> veb(4) works just fine in this setup, so don't give the impression only
> bridge(4) would work.
>
In related items, is it time to tedu bridge(4) and vether(4) ? Is there
anything veb(4) and vport(4) can't do?
David Gwynne [da...@gwynne.id.au] wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for too long.
>
I've be
Demi Marie Obenour [d...@invisiblethingslab.com] wrote:
> Linux???s netfront and blkfront drivers recently had a security
> vulnerability (XSA-396) that allowed a malicious backend to potentially
> compromise them. In follow-up audits, I found that OpenBSD???s xnf(4)
> currently trusts the backend
Christopher Zimmermann [chr...@openbsd.org] wrote:
> On Mon, Dec 20, 2021 at 04:41:07PM -0700, Theo de Raadt wrote:
> > You say it twice. But my eyes still glazed over it, not seeing what was
> > going on the first two times.
> >
> > Maybe something more like
> >
> > prio 0 and 1 are mapped
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 :)
>
>
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
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?
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.
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->p_dtask);
>
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 fou
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
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
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
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 regressi
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
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, an
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_
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 e
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
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 pur
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 i
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.
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
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
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_VL
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.
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
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
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
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
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 disab
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,
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
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/a
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 userlan
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,
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-grap
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
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.
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 ar
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...
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..b956ec
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.c
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
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 eve
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
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
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.
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
> > rea
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 w
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
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 t
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 d
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
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 sh
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:
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
>
Edgar Pettijohn [ed...@pettijohn-web.com] wrote:
> nevermind just found the elusive "q"
>
There's always the universal ^D
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)
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 t
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
> w
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 th
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'
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 ind
David Gwynne [da...@gwynne.id.au] wrote:
> IFF_OACTIVE means the hardware ring is full, not if it is busy.
>
> perhaps a better check is to see whether there are pending packets
> on the send queue?
>
> i could also argue we dont need the check at all, but this is less
> of a semantic change.
>
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
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 i
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, alt
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
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,
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
gwes [g...@oat.com] wrote:
> Will unbound and nsd be restricted to port 53 only?
>
No
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
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 wil
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 Op
?? ?? [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 cuttin
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 con
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
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(), whi
Okembe Mbwambo [okembe.mbwa...@yandex.com] wrote:
> On 25/05/15 02:50:50 PM, Douglas Ray wrote:
>
> > 2. The "FOSS exception" clause above won't help with existing
> > OpenBSD policy, insofar as I understand it here:
> > http://www.openbsd.org/policy.html
> > [note section towards end on GPL u
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 virtuali
Henning Brauer [hb-openbsdt...@ml.bsws.de] wrote:
> now that we have an uncontaminated, err, inet6-free system by default,
> IFXF_NOINET6 just doesn't make sense any more.
> fully go for no inet6 by default, get rid of the IFXF_NOINET6 guarded
> attachments etc.
> introduce IFAFATTACH and IFAFDETAC
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
> ===
> R
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
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--;
>
?? ?? [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 p
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?
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/opencrypt
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 th
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 (includin
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
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: SCSI3 0/direct
fixed eui.0004
1 - 100 of 170 matches
Mail list logo
