athn0 Ifail on an old ALIX
This is 6.5-current on an old ALIX 2D3 (full dmesg below) using
athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:01:d6:86
It is my home router. I am seeing a lot of Ifails on the athn0.
For example, this is after scp'ing a big file from a macbook
(connected to the gw through the athn wifi) to another box
(connected to the gw by ethernet):
$ netstat -I athn0 -finet
NameMtu Network Address Ipkts IfailOpkts Ofail Colls
athn0 150004:f0:21:01:d6:86 2095294 84058 1912273 1519 0
athn0 1500 192.168.33/ gw.stare.cz2095294 84058 1912273 1519 0
The interface is configured as follows:
$ cat /etc/hostname.athn0
inet 192.168.33.1 255.255.255.0 NONE
media autoselect mediaopt hostap mode 11g chan 11
nwid stare.cz wpakey SECRET
Is 84058 / 2095294 =~ 4% Ifail to be expected?
How can I debug this?
More generally, what is the "best" supported wifi hw/driver nowadays?
(Used to be athn when I assembled this machine years ago).
Jan
OpenBSD 6.5-current (GENERIC) #6: Sat May 4 19:43:01 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 267931648 (255MB)
avail mem = 247394304 (235MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/05/08, BIOS32 rev. 0 @ 0xfd088
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address
00:0d:b9:1a:a4:10
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:0d:b9:1a:a4:11
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 15, address
00:0d:b9:1a:a4:12
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:01:d6:86
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
maxtmp0 at iic0 addr 0x4c: lm86
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 12, version 1.0,
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 12
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
addr 1
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (9cd0e5ba033bd225.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout
Re: Firefox bug: 66.0.3 disables all extensions
On Sun, May 05, 2019 at 08:57:11AM +0100, Anthony Campbell wrote: > On 04 May 2019, Juan Francisco Cantero Hurtado wrote: > > On Sat, May 04, 2019 at 07:01:55PM +0100, Anthony Campbell wrote: > > > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > > > were inactivated. A quick search showed that this is a widespread > > > problem, apparently due to a bug in FF. I was able to fix it > > > temporarily by means of a suggestion on ghacks.net to change > > > > > > xpinstall.signatures.required > > > > > > in about.config to "false". > > > > > > Presumably it will be fixed soon upstream. > > > > Disabling signature checks is almost always a bad idea. > > > > Open this url with firefox and install the extension. > > > > https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi > > > > > > Thanks; that certainly fixes the problem though I'm not clear how it > does so or who is supplying the extension, which is a bit worrying. > And it's not showing up in the list of extensions. Is any further > information available? That's the same extension installed by Firefox when you enable Studies. The extension is signed by Mozilla. On Android, I can see the extension in "Addons" with a button to uninstall it. The desktop version hides it and doesn't have the option to uninstall. We have Studies disabled on OpenBSD because Mozilla did a bad use of the feature in the past. Search "firefox studies mrrobot". With Studies enabled, they can change anything in your browser remotely without notifying you. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Activating second crypted (or other raid) device
On Sun, May 5, 2019 3:57 pm, cho...@jtan.com wrote: > Thomas Frohwein writes: >> On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote: >> [...] >> > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev >> > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the >> > additional filesystems are checked or mounted. >> >> > The problem with rc.local is that it's not executed until after fsck and > mount have parsed /etc/fstab (or /etc/fstab has been parsed for them; > whatever). If they do this before sd3 exists they at worst abort and at > best don't perform their desired function on the previously-encrypted > block device (ie. the plaintext block device is not scanned and mounted > automagically and my computer boots without a /srv). > > > My goals are: > > * /etc/rc already handles fsck of plaintext devices mentioned in > /etc/fstab. > * /etc/rc already handles mount of plaintext devices mentioned in > /etc/fstab. > * I would like to activate an encrypted/RAIDed device before /etc/rc > performs > either of those (so that code somebody else has written can do them > for me). > * /etc/rc.local is called too late. > It's really not that big of a deal to call 'fsck' and 'mount' yourself in rc.local. Unless you have system data on /srv (which would be it's own inconsistency with a standard system) needed during rc. In fstab, I set the RAID partition to noauto and disable automatic fsck. Then in rc.local call 'bioctl blah && fsck UUID.partition && mount /srv' I use a password so it's interative for me and I see if anything goes wrong. Log a message with 'logger' or send an email or whatever if something fails for your situation. Then you're done dealing with this.
Re: Activating second crypted (or other raid) device
Thomas Frohwein writes: > On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote: > [...] > > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev > > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the > > additional filesystems are checked or mounted. > > The order of sdX may change if e.g. a USB drive is plugged in during boot. You > know you _can_ use the device UUID which AFAIK should be much more robust than > using sdX. I used the following line at some point in an rc.local: > > bioctl -c C -l b3914b7ba0818788.a softraid0 I was unaware I could supply UUIDs to bioctl. Thanks. I'm know of the danger of USB (and SD, etc.) insanity wrt device node names. I simply make sure to never turn my laptop on with weird shit plugged in to it. Seems like a safe bet. > > Before I resign myself to patching /etc/rc in perpetuity, is there a > > better or more canonical way to activate a second encrypted disc using a > > key file in /etc before filesystems defined in /etc/fstab are checked or > > mounted (it becomes /srv)? > > That would be rc.local. From rc(8): > > Normally, rc.local contains commands and daemons that are not part of > the stock installation. The problem with rc.local is that it's not executed until after fsck and mount have parsed /etc/fstab (or /etc/fstab has been parsed for them; whatever). If they do this before sd3 exists they at worst abort and at best don't perform their desired function on the previously-encrypted block device (ie. the plaintext block device is not scanned and mounted automagically and my computer boots without a /srv). > > The patch I use is below. Ignore the date; I've been using this since > > around 6.2 at least. I feel rather silly saying that you're welcome to > > use this tiny patch if it's useful, but there it is and you are. > > I empathize with your drive to get hands-on with the code to find a solution > to > a problem and the desire to share it, but the solution you are proposing > should > be discouraged. You are proposing a trivial 1-line patch to a file that isn't > meant to be patched; ignoring the man page that contains a valid place for > local customizations. I completely understand why such a non-standard patch is capital-W-Wrong. Developers and manglers believing otherwise are the bane of my existance which is why I'm in NO wise suggesting this should be immediately incorporated (perhaps I should have made that clearer in the previous email - if you don't know how OpenBSD boots from init to rc to getty then this patch is Not For You; it was included mainly so that those who understood it would be able to skip my waffle and zoom in on the actual question). My goals are: * /etc/rc already handles fsck of plaintext devices mentioned in /etc/fstab. * /etc/rc already handles mount of plaintext devices mentioned in /etc/fstab. * I would like to activate an encrypted/RAIDed device before /etc/rc performs either of those (so that code somebody else has written can do them for me). * /etc/rc.local is called too late. Currently I achieve these goals with a simple (for me) patch on a single machine's /etc/rc. I would love to hear of a better way or, if there isn't one, try to come up with one that everybody can be happy with. > For yourself, the closer you stay to the default install especially in regards > to infrastructure like rc(8), the less likely you will run into bugs that are > not reproducible by others. I have no problem with deviating from the standard. I know what I'm getting myself into and I know how to forge the pieces back together again :) I should probably come clean and point out that, having read /install.sub and /etc/rc et al. inside, outwards and sideways, I'm pretty sure that no such mechanism to mount RAID volumes prior to fstab-parsing exists but if I'm wrong then please tell me. Alternatively if there's any other interest than mine in creating one then I have opinions and am happy to do the legwork, I only need a bit of a leg up to make sure I remain within OpenBSD's coding guidelines etc.. Cheers, 'm not you're average noob, Matthew
Re: Activating second crypted (or other raid) device
On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote: [...] > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the > additional filesystems are checked or mounted. The order of sdX may change if e.g. a USB drive is plugged in during boot. You know you _can_ use the device UUID which AFAIK should be much more robust than using sdX. I used the following line at some point in an rc.local: bioctl -c C -l b3914b7ba0818788.a softraid0 > Before I resign myself to patching /etc/rc in perpetuity, is there a > better or more canonical way to activate a second encrypted disc using a > key file in /etc before filesystems defined in /etc/fstab are checked or > mounted (it becomes /srv)? That would be rc.local. From rc(8): Normally, rc.local contains commands and daemons that are not part of the stock installation. > The patch I use is below. Ignore the date; I've been using this since > around 6.2 at least. I feel rather silly saying that you're welcome to > use this tiny patch if it's useful, but there it is and you are. I empathize with your drive to get hands-on with the code to find a solution to a problem and the desire to share it, but the solution you are proposing should be discouraged. You are proposing a trivial 1-line patch to a file that isn't meant to be patched; ignoring the man page that contains a valid place for local customizations. For yourself, the closer you stay to the default install especially in regards to infrastructure like rc(8), the less likely you will run into bugs that are not reproducible by others.
Activating second crypted (or other raid) device
I have a laptop with two hard drives, a small fast ssd and a large slow hdd (since replaced with a larger fast ssd). Both drives are encrypted using bioctl. sd1 is the smaller boot device which becomes sd2, sd0 is the larger device which becomes sd3. sd2 is activated before the kernel by the bootloader after I successfully type in the password. sd3 is activated during the boot phase using (only) a key in /etc/sd0.key. Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the additional filesystems are checked or mounted. Before I resign myself to patching /etc/rc in perpetuity, is there a better or more canonical way to activate a second encrypted disc using a key file in /etc before filesystems defined in /etc/fstab are checked or mounted (it becomes /srv)? The patch I use is below. Ignore the date; I've been using this since around 6.2 at least. I feel rather silly saying that you're welcome to use this tiny patch if it's useful, but there it is and you are. Incidentally the real patch also also runs /etc/rc.early immediately after rm -f /fastboot in order to move X to vt12 and open up vts 5 to 11 because I couldn't find any other way to hook into the boot process early enough but I suspect I'm on my own with that one. (The command to do that, if anyone's interested, is for c in 6 7 8 9 10 11; do wsconscfg $c; done and you also need to update Xservers and ttys). Matthew --- rc.orig Sun Jan 6 10:49:26 2019 +++ rc.mine Sun Jan 6 10:52:03 2019 @@ -353,6 +353,8 @@ exit 0 fi +[[ -f /etc/rc.blockdev ]] && sh /etc/rc.blockdev + # Add swap block-devices. swapctl -A -t blk
Re: Firefox bug: 66.0.3 disables all extensions
On 05/05/2019, Anthony Campbell wrote: > > The second link offers a solution: > > > To provide this fix on short notice, we are using the Studies > system. This system is enabled by default, and no action is > needed unless Studies have been disabled. Firefox users can > check if they have Studies enabled by going to: > > Firefox Options/Preferences -> Privacy & Security -> Allow > Firefox to install and run studies (scroll down to find the > setting) > > This can't be done on my FF - it's greyed out and cannot be enabled. I think it's fundamentally wrong to tie even temporary security fixes or workarounds to people opting in to, or not opting out of mechanisms people may have very good reasons not to opt in to. It's basically putting a gun to their heads saying, "Consent -- or else!" That's especially true if a supposed stopgap measure leads to a sense of decreased urgency for a real solution.
Re: Upgrade procedure (6.4 -> 6.5)
Hi, Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: > Maybe it's a good idea to note this on the upgrade page? Something like > "the upgrade procedure may leave some files behing; you can manually > clean them up using sysclean package"? We have worse problems with the upgrade page right now, Specifically, we lack a maintainer for the file faq/upgrade66.html. Besides, the sentence you are proposing is misleading. Whether or not removing left-behind files provides benefit or rather causes pointless risk depends on the specific files and on the specific situation. For example, it is definitely useful to remove stale Perl libraries. It is also useful for stale header files if you compile software from source. It is useful (but not terribly important) for stale manual pages. It is usually detrimental for old versions of shared libraries, unless you are *really* short on disk space (which is getting less common nowadays) *and* you are very careful. For most use cases, we do not recommend using sysclean. I was specifically considering the (admittedly minor, but none the less slightly annoying) issue of stale manual pages. Yours, Ingo
Re: Upgrade procedure (6.4 -> 6.5)
On Sat, May 04, 2019 at 10:33:26AM +0300, Strahil Nikolov wrote: > On May 4, 2019 10:11:07 AM GMT+03:00, Nick Holland > wrote: > >On 5/3/19 2:32 PM, Strahil Nikolov wrote: > >> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland > >> wrote: > >>> On 5/2/19 1:52 AM, Consus wrote: > Hi, > > I've upgraded my systems from 6.4 to 6.5 without a glitch, but I > see that /etc/networks and some other files (like malloc.conf.5) > are > >>> still > present, although there is no use for them in the new release. > > Is there a reason why these files are not listed in "FIles to > >>> remove"? > Is there a way to track them? It's not like something gonna > break, > >>> but > old configuration files (and manual pages) lying around can make > someone's life harder during the debug session. > >>> > >>> There is no promise that an upgraded machine will be file-for-file > >>> identical to a fresh install. Here is the list of problems this > >>> might cause you, as you can see, it's a long list and quite > >>> horrible: > >>> > >>> * If you use the same hw for 20 years, you might run out of disk > >>> space? > >>> > >>> Ok, not very long and not very horrible. > >>> > >>> You are trying to solve a non-problem. And sometimes, 'specially > >>> on an upgraded machine, it's great to see how things WERE when the > >>> machine was set up. If you really care, go ahead, delete stuff. > >>> > >>> Nick. > >> > >> Hi All, > >> > >> As I linux guy (my experience in openBSD can be easily measured in > >> days) I can share the view of less experienced user that was planing > >> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall. > >> > >> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to > >> 6.5 and thus it seemed that booting from the 6.5 DVD will do the > >> trick. Sadly the installer never checked the avalable space , but > >> just started to do it's stuff until reporting that not enough space > >> is available. > > > >The installer didn't check. Neither did you. Let's blame the > >installer. > > Well, O can't presict how big are the new tars's size -yet the updater > shoulddo that. > If my /usr is too small - it should make the calculation for me and refuse to > update. > > How do you estinate how much space do you need for the update ? Get the iso > and extract each archive to predict that ? > Nah let's blame the newbie. > > >Ok, sure, might be nice, but when there are a snootload of different > >platforms with radically different size binaries, it's not trivial. > Well, if it's done in linux , its doable in openBSD. Of course it is doable. But nobody has done it. Probably because nobody (developer or otherwise) thought it a priority. I'd say that even while it is not a priority, the install/upgrade proces already does the right thing in many, many circumstances. A even more foolproof install/upgrade is nice to have, but given the resources available, there are more pressing things to do. -Otto
Re: Upgrade procedure (6.4 -> 6.5)
Hi Wolfgang, Wolfgang Pfeiffer wrote on Sat, May 04, 2019 at 06:34:04PM +0200: > On Sat, May 04, 2019 at 01:07:34AM -0400, Nick Holland wrote: >> Spend a little time learning OpenBSD, > Yes: time needed, I think: Took me a while until I got that ... :) While i don't doubt it may feel like that for some, your mileage may wary even in that respect. Before 2001, i had mostly used DEC/OSF-1 and bit of HP-UX and AIX, as well as lots of Linux, a bit of Redhat but mostly SuSE and Debian. When a colleague made me set up and run an OpenBSD server with that background, i immediately noticed that for typical sysadmin tasks, it took me about three times less time to get them done with OpenBSD than with Debian. Even though i was experienced with Debian and totally new to OpenBSD. Around the same time, it happened to me that a friend wanted a home firewall installed with Debian. After another friend had wrestled with the installation for more than an hour before finally giving up, i quickly and smoothly installed OpenBSD on that box and we were done with it. The guy who failed with Debian was far from stupid, even more experienced then i was with either of the systems at the time. Bottom line, chances are that the time you need for learning is vastly outweighted by the time you save because the system is so much simpler to use. So likely, you will save time starting on day one. Yours, Ingo
Tcpdump on enc0 how to filter port 443
Hello, Does anyone know how can I capture flows to port 443 on an enc0 interface # tcpdump -ni enc0tcpdump: listening on enc0, link-type ENC 12:29:52.626065 (authentic,confidential): SPI 0x63b38934: 192.168.2.1.18413 > 192.168.1.1.443: S 3266713948:3266713948(0) win 16384 (DF) (encap) But tcpdump -ni enc0 port 443 gives nothing. I understand that it's encapsulated so in the second command the filter 443 don't match however there should be a way to use a filter since in the first capture we can see tcpdump is aware about port 443 Thank you
Re: Firefox bug: 66.0.3 disables all extensions
On 04 May 2019, Juan Francisco Cantero Hurtado wrote: > On Sat, May 04, 2019 at 07:01:55PM +0100, Anthony Campbell wrote: > > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > > were inactivated. A quick search showed that this is a widespread > > problem, apparently due to a bug in FF. I was able to fix it > > temporarily by means of a suggestion on ghacks.net to change > > > > xpinstall.signatures.required > > > > in about.config to "false". > > > > Presumably it will be fixed soon upstream. > > Disabling signature checks is almost always a bad idea. > > Open this url with firefox and install the extension. > > https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi > > Thanks; that certainly fixes the problem though I'm not clear how it does so or who is supplying the extension, which is a bit worrying. And it's not showing up in the list of extensions. Is any further information available? -- Anthony Campbellhttp://www.acampbell.uk
Re: Firefox bug: 66.0.3 disables all extensions
On 04 May 2019, Stefan Pietsch wrote: > On 04.05.19 20:01, Anthony Campbell wrote: > > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > > were inactivated. A quick search showed that this is a widespread > > problem, apparently due to a bug in FF. I was able to fix it > > temporarily by means of a suggestion on ghacks.net to change > > > > xpinstall.signatures.required > > > > in about.config to "false". > > > > Presumably it will be fixed soon upstream. > > More information can be found here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 > https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ > > Citing the blog: > > There are a number of work-arounds being discussed in the community. > These are not recommended as they may conflict with fixes we are deploying. > > The second link offers a solution: To provide this fix on short notice, we are using the Studies system. This system is enabled by default, and no action is needed unless Studies have been disabled. Firefox users can check if they have Studies enabled by going to: Firefox Options/Preferences -> Privacy & Security -> Allow Firefox to install and run studies (scroll down to find the setting) This can't be done on my FF - it's greyed out and cannot be enabled. -- Anthony Campbellhttp://www.acampbell.uk
Re: low bandwidth results with IPSEC enabled between two PC Engines APU2C2
> There is a longstanding bug there that causes the ikeds to lose > synchronization. Is this bug fixed or not in 6.5? On Wed, 9 Nov 2016 15:19:49 + (UTC) Christian Weisgerber wrote: > On 2016-11-09, "Comète" wrote: > > > I've made some bandwidth tests (on 6.0 stable - amd64) between two APU2C > > boxes connected with an Ethernet cable and an IPSEC VPN using IKEDv2. I get > > a > > maximum bandwidth of 66 Avg Mbps when IPSEC is enable which is, I think, > > very > > low for an AES-NI enabled processor. > > Well, it still is a slow processor. For best performance, I'd add > "childsa enc aes-128-gcm" to the iked configuration. The default > cipher is aes-256-cbc with hmac-sha2-256, and the latter has a > noticeable performance impact. > > > And about 30 seconds after the test is > > started, I don't know why, the connection is lost and I have restart IKED > > daemon on the "passive" host. > > Every half gigabyte of transferred data, iked rekeys. There is a > longstanding bug there that causes the ikeds to lose synchronization. > They will eventually resync on their own, but it takes several > minutes. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > -- Radek
