Re: Prepping to install: a digression
w...@hiwaay.net (William A. Mahaffey III) writes: P.S. As mentioned elsewhere, I have had trouble w/ raidctl -A root before, so I haven't gone there yet. Is that actually required for boot from root on RAID (man pages seem ambiguous on that point) ? Currently it is necessary. The bootloader understands enough about RAID to read /boot and /netbsd. But the kernel just gets data about the boot device (wd0) which has no root partition. The raidctl -A magic overrides the bootloader information, so that the kernel will see and mount raidNa as the root partition. The magic should go away and the kernel should just learn how to handle raid partitions (and LVM partitions and ...). But for now that's how it works. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
IPsec over GRE slow performances
Hi,
I have set up an IPsec over GRE connection with a remote host, both are NetBSD
6.1 based. The client is connected to the Internet through a 400Mbps fiber
connection. The server is located on a 10Gbps network. Both machines have
1Gbps NICs which behave perfectly, meaning they both reach the link speed limit
when transferring data outside the IPsec tunnel.
When doing a transfer through the tunnel, speed drops at a factor 5 to 10:
direct connection:
/dev/null27%[ ] 503.19M 45.3MB/s eta 83s
IPsec connection:
/dev/null 2%[ ] 47.76M 6.05MB/s eta 5m 3s
The tunnel is setup this way:
On the server, which is a NetBSD domU running on a debian/amd64 dom0:
$ cat /etc/ifconfig.xennet0
# server interface
up
inet 192.168.1.2 netmask 255.255.255.0
inet 172.16.1.1 netmask 0xfffc alias
$ cat /etc/ifconfig.gre0
create
tunnel 172.16.1.1 172.16.1.2 up
inet 172.16.1.5 172.16.1.6 netmask 255.255.255.252
IPsec traffic is forwarded from dom0's public IP to the domU's xennet0 interface
through an iptables NAT rule:
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.1.2:500
-A PREROUTING -i eth0 -p esp -j DNAT --to-destination 192.168.1.2
-A PREROUTING -i eth0 -p ah -j DNAT --to-destination 192.168.1.2
On the client:
$ cat /etc/ifconfig.vlan8
# client public interface
create
vlan 8 vlanif re0
!dhcpcd -i $int
inet 172.16.1.2 netmask 0xfffc alias
$ cat /etc/ifconfig.gre1
create
tunnel 172.16.1.2 172.16.1.1 up
inet 172.16.1.6 172.16.1.5 netmask 255.255.255.252
On racoon side, I tried various hash / encryption algorithms combinations, even
enc_null, but nothing changes really, transfer is still stuck at a 6MB/s max.
Here's the racoon setup:
On the server:
remote office.public.ip {
exchange_mode main;
lifetime time 28800 seconds;
proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
generate_policy off;
}
sainfo address 172.16.1.1/30 any address 172.16.1.2/30 any {
pfs_group 2;
encryption_algorithm blowfish;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
lifetime time 3600 seconds;
}
On the client:
remote node.public.ip {
exchange_mode main;
lifetime time 28800 seconds;
proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
generate_policy off;
}
sainfo address 172.16.1.2/30 any address 172.16.1.1/30 any {
pfs_group 2;
encryption_algorithm blowfish;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
lifetime time 3600 seconds;
}
The tunnel establishes with no issue, the only problem here is transfer drop.
Again, when transferring from / to the server from / to the client without
tunnel, speed is optimal, drop occurs _only_ through IPsec.
Both machines are intel-based CPUs running at 2+GHz, plenty of memory and very
little CPU time consumed by anything else than forwarding / NAT.
Has anyone witnessed such a behaviour? Any idea on where to look further?
Thanks,
Emile `iMil' Heitor * imil@{home.imil.net,NetBSD.org,gcu.info}
_
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org | - against HTML email X
| http://gcu.info| vCards / \
Re: Prepping to install: a digression
On Tue, Jul 14, 2015 at 12:43:57AM +, Christos Zoulas wrote: In article 55a43d0b.6030...@hiwaay.net, William A. Mahaffey III w...@hiwaay.net wrote: [...] Thanks for the reply. I tried the 'boot -a'. It got down to the following: boot device: wd0 root device (default wd0a): When I tried to type in 'raid0a', it added 'pckbport_start: command error' hung. [...] [...] I am wondering why the keyboard is not functional for you. Try raidctl -A softroot device I have not followed the thread from the start so this has perhaps been asked before: is the keyboard USB attached and not PS2? In this case, from usb(4) add the flags 1 to the USB protocols in the kernel config: usb* at ehci? flags 1 usb* at ohci? flags 1 usb* at uhci? flags 1 (I guess this could be limited to the USB 1.0 protocols but who knows...) because : Sometimes it is desirable to have a device detected early in the boot process, e.g., the console keyboard. To achieve this use a flags value of 1. FWIW, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Prepping to install: a digression
On 07/14/15 02:15, tlaro...@polynum.com wrote: On Tue, Jul 14, 2015 at 12:43:57AM +, Christos Zoulas wrote: In article 55a43d0b.6030...@hiwaay.net, William A. Mahaffey III w...@hiwaay.net wrote: [...] Thanks for the reply. I tried the 'boot -a'. It got down to the following: boot device: wd0 root device (default wd0a): When I tried to type in 'raid0a', it added 'pckbport_start: command error' hung. [...] [...] I am wondering why the keyboard is not functional for you. Try raidctl -A softroot device I have not followed the thread from the start so this has perhaps been asked before: is the keyboard USB attached and not PS2? In this case, from usb(4) add the flags 1 to the USB protocols in the kernel config: usb* at ehci? flags 1 usb* at ohci? flags 1 usb* at uhci? flags 1 (I guess this could be limited to the USB 1.0 protocols but who knows...) because : Sometimes it is desirable to have a device detected early in the boot process, e.g., the console keyboard. To achieve this use a flags value of 1. FWIW, Good thought, however it is a PS2 kbd mouse. Thanks for your reply TIA for any new clues. -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: Prepping to install: a digression
On 07/13/15 20:46, Robert Elz wrote: Date:Tue, 14 Jul 2015 00:43:57 + (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: mo1m0c$64o$1...@ger.gmane.org | Yes, this is required for booting from raid. It is required to make the root on raid work automatically, not for booting. | I am wondering why the keyboard is not functional for you. I suspect (well, really, I'm sure) that's an entirely unrelated problem, one which has been reported several times before - there must be something about some systems that NetBSD's initial keyboard access stuff (before wekbd gets a chance to get involved) isn't doing properly. If he can get booting working properly, it shouldn't matter normally. | Try raidctl -A softroot device I'd suggest not. It won't make the boot work - cannot possibly help with that, and will only make it difficult to recover (again - though now it has been done once, at least a working method is known), whereas now it is easy to simply start again. As I said a week or two ago - you need to get to the state where the kernel boots, autoconfigures devices, and then fails to find the root filesystem (booting from the wd discs, not the USB plugin) - when you have that much working, then is the time to reboot from the USB, and do that raidctl to allow the root raid to appear. kre I had a thought last evening. Is it possible that dmesg info (or something similar) is still stored somewhere on the filesystem from the failed HDD boot ? If so, is it possible to boot from the USB drive recover it somehow ? I powered off using the power button it 'unbooted' cleanly. That dmesg info would provide more accurate detailed info on the state of the boot process than me trying to type it in from memory or hand-written notes. Just a thought -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: Prepping to install: a digression
On 07/14/15 02:45, Michael van Elst wrote: w...@hiwaay.net (William A. Mahaffey III) writes: P.S. As mentioned elsewhere, I have had trouble w/ raidctl -A root before, so I haven't gone there yet. Is that actually required for boot from root on RAID (man pages seem ambiguous on that point) ? Currently it is necessary. The bootloader understands enough about RAID to read /boot and /netbsd. But the kernel just gets data about the boot device (wd0) which has no root partition. The raidctl -A magic overrides the bootloader information, so that the kernel will see and mount raidNa as the root partition. The magic should go away and the kernel should just learn how to handle raid partitions (and LVM partitions and ...). But for now that's how it works. Maybe 6.1.6 :-) ? -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: Prepping to install: a digression
On 07/14/15 13:46, Michael van Elst wrote: w...@hiwaay.net (William A. Mahaffey III) writes: Good thought, however it is a PS2 kbd mouse. Thanks for your reply TIA for any new clues. If PS2 hardware is detected (even when not really functional), it prevents an USB keyboard from becoming the console keyboard. H I do have a spare USB kbd laying around, might that get past some of the problems so far ? Mind you, when up running, it will have no kbd/mouse/monitor attached by default -- William A. Mahaffey III -- The M1 Garand is without doubt the finest implement of war ever devised by man. -- Gen. George S. Patton Jr.
Re: Prepping to install: a digression
On Tue, Jul 14, 2015 at 06:39:51PM +, Michael van Elst wrote: w...@hiwaay.net (William A. Mahaffey III) writes: Good thought, however it is a PS2 kbd mouse. Thanks for your reply TIA for any new clues. If PS2 hardware is detected (even when not really functional), it prevents an USB keyboard from becoming the console keyboard. Does this mean that if a MB has a PS2 combo (one slot for whether a keyboard or a mouse) and that a mouse is connected to it, one has no keyboard at least on console? That may explain some queer behaviors I had. But, in general, I had queer behavior with USB devices with NetBSD (not to mention that on a dual boot node---Windows being the other one---it is impossible to have a sane boot after running Windows without cold booting; I don't know what Windows does with the BIOS and the hardware settings, but it results in havoc). -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Prepping to install: a digression
Date:Mon, 13 Jul 2015 21:57:46 -0453 From:William A. Mahaffey III w...@hiwaay.net Message-ID: 55a47933.1020...@hiwaay.net | Hm I *think* that's where I am now, from earlier today a few | days ago (from boot attempt from disks, *not* USB): Sorry, have not been looking at mail for (almost) 24 hours... And yes, you are there now. The last I saw you reported you were failing to boot at all, obviously that has been fixed, and I missed it. | Am I looking for the word 'autoconfigure' explicitly ? No, just the messages where all the hardware is listed. The boot device (etc) lines you showed appear right at (or near) the end of the autoconfig process. Since you're at that stage, do what Christos suggested, boot from the USB, and do the raidctl -A softroot raid0 (or if the system you're using is old enough that it doesn't recognise softroot then use just root) You already tested that what's on the root partition seems to be all OK, so with this, at the very least, you should get to the state where you can get to single user mode, even if there's still something not configured correctly that prevents multi-user mode working correctly. Also, to answer a later message ... the boot time messages do get saved to a file - but for that to happen, the filesystem needs to exist first, and for you that hasn't happened (as far as the kernel is concerned) yet. Until after you have a mounted root filesystem there is nowhere available to put a file, so all that data is just buffered in RAM, waiting for later to get written out - that happens as part of the later boot process. But it doesn't matter, aside from the boot time keyboard problem, I suspect everything will work now, or be very close to it. kre
Re: Prepping to install: a digression
w...@hiwaay.net (William A. Mahaffey III) writes: Good thought, however it is a PS2 kbd mouse. Thanks for your reply TIA for any new clues. If PS2 hardware is detected (even when not really functional), it prevents an USB keyboard from becoming the console keyboard. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
