Re: ix(4): enable checksum offload

Not sure what is wrong, if it is driver or chipset, but in freebsd I had to '-rxcsum6 -txcsum6 -tso -vlanhwtso’ in order to make it function. > On 16 apr. 2016, at 18:23, Hrvoje Popovski wrote: > > On 9.9.2013. 22:07, Mike Belopuhov wrote: >> On 9 September 2013 21:48, Brad

Re: mpsafe aesni

Not sure how much I can test here, but my tunnels are up. As well as my bgp sessions (this is "ART box” now) on top. I use aes-128-gcm. This is vmware. //mxb > On 26 mars 2016, at 16:25, Mike Belopuhov <m...@belopuhov.com> wrote: > > On Fri, Mar 25, 2016 at 22:43 +0100,

Re: ARP input path without KERNEL_LOCK

Even with updated diff, I see no breakage. //mxb > On 22 dec. 2015, at 13:48, Martin Pieuchot <m...@openbsd.org> wrote: > > On 04/12/15(Fri) 11:54, Martin Pieuchot wrote: >> Now that in_arpinput() only uses the routing table, if_get()/if_put() >> and carp_iamatch

Re: ARP input path without KERNEL_LOCK

No regression here. > On 4 dec. 2015, at 11:54, Martin Pieuchot wrote: > > Now that in_arpinput() only uses the routing table, if_get()/if_put() > and carp_iamatch being already mpsafe we can kill the ARP input queue. > > This moves the ARP input path processing from the

Re: vmx(4) incorrect m_pulldown usage

No regression so far. //mxb > On 15 dec. 2015, at 14:18, Mike Belopuhov <m...@belopuhov.com> wrote: > > Hi, > > This has been in my tree for a while and I believe Yasuoka-san has > tested it in the scenario where it was crashing. > > m_pulldown is done here

relayd HTTP PATCH not handled.

Hey, HTTP_METHOD_PATCH is not handled by relayd at all. Well, actually in fals under default in switch(). PATCH is like PUT, eg. data is expected. One-liner below fixes this. Tested in production. --- relay_http.cMon Dec 14 16:16:07 2015 +++ relay_http.c.my Mon Dec 14 21:18:50 2015

Re: Unable to install bootblocks

Is you disk is thick os thin provisioned? In should be thick and eager zeroed. There are ways to move from thin to thick. Google for it. //mxb > On 29 sep. 2015, at 22:52, Pedro Caetano <pedrocaet...@binaryflows.com> wrote: > > Hi, > > While installing openbsd on

Re: gif(4) cleanup

My tunnels are working as well. //mxb > On 25 sep. 2015, at 11:38, Martin Pieuchot <m...@openbsd.org> wrote: > > As discussed in Calgary I don't think we need 6 different files for > gif(4). None of them are standalone. Since all our other pseudo- > drivers are sel

Re: PF SMP: mutex for fragcache

Applied. > On 12 sep. 2015, at 19:20, Alexandr Nedvedicky > wrote: > > Hello, > > very small first step towards MP(i) friendly PF. Patch adds mutex around > fragment cache. > > Patch adds a lock around fragment cache. Unlike other parts of PF the fragment >

Re: mpsafe vmx(4)

This one in the tree, so it’s live on my side. > On 14 sep. 2015, at 13:09, David Gwynne wrote: > > this is an attempt to make the interrupt path in vmx mpsafe. > > seems to hold up under load here, but more testing would be > appreciated. > > Index: if_vmx.c >

Re: mpsafe ip_carp

s I modified hostname.carp1 to remove both dual VHID (VHID 1 is what left) and balancing arp and done ‘sh /etc/netstart carp1’ after on both machines. node2 survived. //mxb > On 13 sep. 2015, at 10:34, David Gwynne <da...@gwynne.id.au> wrote: > > i did this yesterday, but

Re: error:0906D064:PEM routines:PEM_read_bio:bad base64

Sure On 4 jul 2015, at 01:44, Brent Cook bust...@gmail.com wrote: Would you be comfortable adding some extra output to the various failure points in EVP_DecodeUpdate to see where we are bailing out?

Re: error:0906D064:PEM routines:PEM_read_bio:bad base64

OpenSSL 1.0.1o on OpenBSD-current does not have problem with this key as well. On 30 jun 2015, at 08:52, mxb m...@alumni.chalmers.se wrote: I’m sorry but I can’t provide private key. It is basically production and not self-signed. Comes from Thawte. I’m able to produce output from

Re: error:0906D064:PEM routines:PEM_read_bio:bad base64

. Those are OK both on FC20 and OpenBSD-current. Question how do I debug this? I’m happy to apply any patches for testing. Br //mxb On 30 jun 2015, at 05:25, Brent Cook bust...@gmail.com wrote: On Mon, Jun 29, 2015 at 1:22 AM, mxb m...@alumni.chalmers.se wrote: Hey, getting following

error:0906D064:PEM routines:PEM_read_bio:bad base64

-in key’ ‘openssl version’: LibreSSL 2.2 This key is OK with openssl on Linux Br //mxb

Re: SMP steroids for PF

And the rest of us is watching and waiting for diffs to apply :) It is like exiting movie - I have popcorn in front. Culmination must be soon, I guess :) //mxb On 2015-06-26 19:09, Martin Pieuchot wrote: On 26/06/15(Fri) 17:19, Alexandr Nedvedicky wrote: On Fri, Jun 26, 2015 at 04:34:06PM

Re: RTF_LOCAL and permanent ARP

Yes, incomplete is gone as well as arpresolve: unresolved and rt_expire == 0. //mxb On 2015-06-04 12:19, Martin Pieuchot wrote: I'd like to put the link-layer address back into the gateway field of RTF_LOCAL addresses. The problem is that RTF_LOCAL routes are also marked as RTF_LLINFO

Re: vmxnet3 panic

Any chance to get this committed? Stepped on it once more without this patch. //mxb On 2015-05-22 19:53, Mike Belopuhov wrote: On Fri, May 22, 2015 at 19:35 +0200, mxb wrote: Hey, got a panic as of todays ‘cvs up’ trace below panic: vmxnet3_rxintr: NULL ring-m[44] Stopped at Debugger

Re: arpresolve: unresolved and rt_expire == 0

I had an old kernel from 'Apr 28' laying around, as well as from 'May 15' . Both are OK. On 2015-06-01 23:04, mxb wrote: Well, this is a vmware setup, thus I have vmx(4). I just made a clean 'cvs co -P src' from anoncvs.eu.openbsd.org and still have the same result. //mxb On 2015-06-01 10

Re: arpresolve: unresolved and rt_expire == 0

Well, this is a vmware setup, thus I have vmx(4). I just made a clean 'cvs co -P src' from anoncvs.eu.openbsd.org and still have the same result. //mxb On 2015-06-01 10:55, Martin Pieuchot wrote: Any idea about how to reproduce it?

Re: arpresolve: unresolved and rt_expire == 0

1.152 not fixed this, thus reversion far back to 1.150 On 31 maj 2015, at 22:33, mxb m...@alumni.chalmers.se wrote: Reverting if_ether.c from 1.153 to 1.150 fixes my problem. //mxb On 31 maj 2015, at 22:05, mxb m...@alumni.chalmers.se wrote: Hello, any ideas regarding subject

Re: arpresolve: unresolved and rt_expire == 0

Reverting if_ether.c from 1.153 to 1.150 fixes my problem. //mxb On 31 maj 2015, at 22:05, mxb m...@alumni.chalmers.se wrote: Hello, any ideas regarding subject ? I see this in ‘dmesg’. Also all local (on machine itself) arp entries are incomplete: Host

arpresolve: unresolved and rt_expire == 0

(incomplete)vmx3 permanent l //mxb

Re: tun(4) and if_input()

Don’t have tun(4), but applied. As well as latest carp and bridge patches. So far no problems, except that I see following in dmesg : arpresolve: unresolved and rt_expire == 0 but this is probably not related to new diffs. //mxb On 28 maj 2015, at 11:28, Martin Pieuchot m...@openbsd.org

Re: carp(4) is out

Hey, so far no problems. //mxb On 22 maj 2015, at 16:05, Martin Pieuchot m...@openbsd.org wrote: Let's take carp(4) out of ether_input(). This is quite similar to what happened to trunk(4) and vlan(4). I appreciate tests of any kind, reviews and oks. Index: net/if_ethersubr.c

vmxnet3 panic

(GENERIC.MP) #0: Fri May 22 16:30:54 CEST 2015 //mxb

Re: vmxnet3 panic

Not sure if I’ll be able to reproduce this at all. Never seen this before. But diff is applied. //mxb On 22 maj 2015, at 19:53, Mike Belopuhov m...@belopuhov.com wrote: On Fri, May 22, 2015 at 19:35 +0200, mxb wrote: Hey, got a panic as of todays ‘cvs up’ trace below panic

Re: vlan+bridge fix

Diff is applied. So far no problems. Unfortunately I can’t test this fully - no vlans on my side. //mxb On 15 maj 2015, at 13:14, Martin Pieuchot m...@openbsd.org wrote: I have one setup with multiple interfaces in a bridge and on some of these interfaces some vlan(4)s. But there's

Re: Small bridge(4) fix

No regression on my side. //mxb On 15 maj 2015, at 12:54, Martin Pieuchot m...@openbsd.org wrote: If we change the rcvif pointer of a packet we need to run if_input() again otherwise we might skip the handlers on the new interface. Ultimately it would be nice to only assign rcvif

Re: bridge(4) and ether_input_mbuf()

Applied. I don’t see any regressions so far. I use bridge+vether. //mxb On 28 apr 2015, at 23:06, Martin Pieuchot m...@openbsd.org wrote: On 21/04/15(Tue) 12:35, Martin Pieuchot wrote: This diff adds the necessary glue to bridge(4) to be able to convert other pseudo-drivers to if_input

Re: Dell R630 high interrupts on acpi0

On 16 dec 2014, at 06:40, David Gwynne da...@gwynne.id.au wrote: others have hit this on r620s as well I don’t see it on mine. interrupt total rate irq0/clock 9587998940 1599 irq0/ipi136166514 22 irq144/acpi0

Re: idea to block some scanners

Could you please, post updated version to the list? //mxb On 27 jun 2014, at 20:09, Leclerc, Sebastien sebastien.lecl...@saint-georges.ca wrote: Stuart Henderson st...@openbsd.org, 2014-06-27 11:00 +/* Stolen from ftp-proxy */ Old version of ftp-proxy I guess. It hasn't used

Re: bnx(4): enable checksum offload

This is bnx0 at pci3 dev 4 function 0 Broadcom BCM5706 rev 0x02 On 8 okt 2013, at 22:34, mxb m...@alumni.chalmers.se wrote: I have it spinning now. bnx0: flags=28b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST,NOINET6 mtu 1500 hwfeatures=36CSUM_TCPv4,CSUM_UDPv4

Re: memset.S for amd64

This file is already in base. /usr/src/sys/lib/libkern/arch/amd64/memset.S On 18 sep 2013, at 20:28, Edd Barrett vex...@gmail.com wrote: On Wed, Sep 18, 2013 at 07:08:31PM +0100, Edd Barrett wrote: In short, each experiment warms up by setting and checking a load of buffers before setting

Re: memset.S for amd64

On 19 sep 2013, at 19:23, Brad Smith b...@comstyle.com wrote: That is in the kernel not libc. Yes, I know. Can't it be re-used instead of maintaining same file in two places? //mxb

rc.d/dhcpd

Then running dhcpd with pf-support (-A tbl -C tbl). dhcpd spawns child process which is not handled by rc-script then stop/restart. Here is a diff to fix it. Yes, I know, normally one might want to flush PF-tables as well and this is not handled by the diff. But at least I don't have to kill

Re: X540T: link is not detected

with the device attached there is no problem to detect it. The device does not seem to authenticate properly if it is not in USB port to begin with. Luke 2012/11/27 mxb m...@alumni.chalmers.se There is however, no problem then: plugged - boot - wait - unplug - wait - plug in. On 27 nov 2012

X540T: link is not detected

Hi tech@, ix(4) does not detects link then cable is plugged in into already running machine. ix0: flags=28b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr bc:30:5b:f3:60:10 description: HW_EXT priority: 0 media: Ethernet

Re: X540T: link is not detected

There is however, no problem then: plugged - boot - wait - unplug - wait - plug in. On 27 nov 2012, at 13:50, mxb m...@alumni.chalmers.se wrote: Hi tech@, ix(4) does not detects link then cable is plugged in into already running machine. ix0: flags=28b43UP,BROADCAST,RUNNING,PROMISC

TX_/RX_CSUM on Intel I350/X540T

Hey tech@, I'll more than gladly test any diffs for subject. Regards, Maxim

Re: em(4): enable TCP/UDP checksum offload

In my case, it is a CARP backup(master will be upgraded soon) rolling ospf on top of gre on top of ipsec, running npppd, and daily NAT/RDR for about 100 clients. On 6 nov 2012, at 21:31, Stuart Henderson s...@spacehopper.org wrote: For people who are testing checksum-offload-enabling diffs, it

Re: bge(4): enable TCP/UDP checksum offload

Can someone, please, point me to the right cvs URL for those changes. Thanks. On 3 nov 2012, at 22:41, Christian Weisgerber na...@mips.inka.de wrote: Henning's epic rewrite of the checksum handling has fixed

Re: PF: match dir ... tag tag; pass tagged { tag, tag } keep state

at 5:03 PM, Henning Brauer henn...@openbsd.org wrote: * mxb m...@alumni.chalmers.se [2012-09-10 17:51]: is there any plans to expand 'tagged' keyword in PF into list? not that I am aware of, but it would make sense to have list expansion there as well. would it mean tagged foo AND bar or tagged

PF: match dir ... tag tag; pass tagged { tag, tag } keep state

Hi list@, is there any plans to expand 'tagged' keyword in PF into list? Example of usage: match in ... tag ABC match in ... tag BCD pass in on egress tagged { ABC, BCD } If yes, is anyone already working on that? Any diff for testing? Yes, I started to look at this, but it will take time for

add vmxnet3 to pcidevs

Diff below adds vmxnet3 to pcidevs. vmxnet and vmxnet2 have the same PCI ID and thus catched by the same macro - VMWARE NET. While there, remove \t with space for MACHINE_2 //maxim Index: sys/dev/pci/pcidevs === RCS file:

Re: add vmxnet3 to pcidevs

On 04/23/2012 10:39 AM, Brad Smith wrote: On 23/04/12 4:32 AM, mxb wrote: Diff below adds vmxnet3 to pcidevs. vmxnet and vmxnet2 have the same PCI ID and thus catched by the same macro - VMWARE NET. While there, remove \t with space for MACHINE_2 The PCI id entries are sorted so this new

Re: diff: fix bpf problem of pipex

On Apr 4, 2012, at 7:36 PM, YASUOKA Masahiko wrote: Hi, On Wed, 4 Apr 2012 13:19:06 +0200 Claudio Jeker cje...@diehard.n-r-g.com wrote: On Wed, Apr 04, 2012 at 02:34:46PM +0900, Yasuoka Masahiko wrote: On Tue, 31 Jan 2012 13:59:17 +0100 Sebastian Reitenbach sebas...@l00-bugdead-prods.de

Re: diff: fix bpf problem of pipex (was Re: diff: fix LCP keepalive failures on L2TP.)

On 04/04/2012 07:34 AM, YASUOKA Masahiko wrote: On Tue, 31 Jan 2012 13:59:17 +0100 Sebastian Reitenbachsebas...@l00-bugdead-prods.de wrote: However, I noted with tcpdump, listening on tun0: # tcpdump -n -i tun0 tcpdump: listening on tun0, link-type LOOP 13:51:15.354776 tcpdump: WARNING:

npppd_arp.h missing in the tree

Hi, looks like npppd_arp.h is missing in the tree. Is it in purpose or just a miss? npppd.c: snip #ifdef USE_NPPPD_ARP #include npppd_arp.h #endif /snip Regards, Maxim