Re: ehci_idone message with HP printer
If you see it only once, you can ignore it. Ok, this is the case for me. But do you still need to restart your printer? No, this problem seem actually to be fixed, thank you. :)
Running RESTORE(8) from standard in.
I'm using dump for backups to take advantage of the dump levels. I'd like to be able to run restore interactively, using the standard in as an input. Here's what I have in mind: # cd /tmp # ssh backup@10.0.0.10 cat /home/backup/0-var.dmp | restore -i -f - restore When I try it, it hangs on the first command I run, even the what command. top reports the wait for restore is ttyin. I'm running OpenBSD 5.5-stable, patch 8, compiled from source. The host is running on rootbsd.net's infrastructure, Xen running my host as a HVM I believe. This is how I'm creating the backups: /sbin/dump -9 -au -f - /var | ssh -l backup 10.0.0.10 cat /home/backup/9-var.dmp I'm not using gzip or bzip2 on the remote side, because I don't own the backup server. rootbsd.net owns that and I want to be a good neighbor. Am I getting the redirection wrong, or have I hit some kind of bug with the restore command? By the way, I'm just testing. I'm not in the heat of the moment, with a production recovery. Thanks in advance, --Bruce Robert Bruce Carleton r...@rbcarleton.com
Re: Running RESTORE(8) from standard in.
On Sun, Jul 20, 2014 at 2:06 PM, Robert Carleton r...@rbcarleton.com wrote: I'm using dump for backups to take advantage of the dump levels. I'd like to be able to run restore interactively, using the standard in as an input. Here's what I have in mind: # cd /tmp # ssh backup@10.0.0.10 cat /home/backup/0-var.dmp | restore -i -f - restore When I try it, it hangs on the first command I run, even the what command. top reports the wait for restore is ttyin. I'm running OpenBSD 5.5-stable, patch 8, compiled from source. The host is running on rootbsd.net's infrastructure, Xen running my host as a HVM I believe. First, if the remote machine is another openbsd box or has a compatible /etc/rmt command, then you may be able to just use restore -i -f backup@10.0.0.10:/home/backup/0-var.dmp If that works, it'll probably be the most efficient method. And yes, that will use ssh internally. Otherwise, the problem is probably just that ssh is reading your stdin as well. You can suppress that with its -n option. But do try the above method using rmt first Philip Guenther
Re: Running RESTORE(8) from standard in.
On Jul 20, 2014, at 2:24 PM, Philip Guenther guent...@gmail.com wrote: On Sun, Jul 20, 2014 at 2:06 PM, Robert Carleton r...@rbcarleton.com wrote: I'm using dump for backups to take advantage of the dump levels. I'd like to be able to run restore interactively, using the standard in as an input. Here's what I have in mind: # cd /tmp # ssh backup@10.0.0.10 cat /home/backup/0-var.dmp | restore -i -f - restore When I try it, it hangs on the first command I run, even the what command. top reports the wait for restore is ttyin. I'm running OpenBSD 5.5-stable, patch 8, compiled from source. The host is running on rootbsd.net's infrastructure, Xen running my host as a HVM I believe. First, if the remote machine is another openbsd box or has a compatible /etc/rmt command, then you may be able to just use restore -i -f backup@10.0.0.10:/home/backup/0-var.dmp The backup server is FreeBSD 9.2-RELEASE. I'll give that a try. If that works, it'll probably be the most efficient method. And yes, that will use ssh internally. Otherwise, the problem is probably just that ssh is reading your stdin as well. You can suppress that with its -n option. But do try the above method using rmt first Philip Guenther
Re: zzz, /dev/wsmouse
On 2014-07-19 16.43.30 +0200, Martin Pieuchot wrote: On 13/07/14(Sun) 18:22, Mike Burns wrote: Thinkpad X1 Carbon with a touchscreen, running 5.5-stable. When I resume from suspend my Xorg.0.log is flooded with: (EE) ws: /dev/wsmouse1: read error Input/output error In my dmesg: wsmouse1: can't attach mux (error=5) I did a lot of work after 5.5 to prevent races like this one. Could you try a snapshot and tell me if you still see this error during suspend- resume? This race is indeed fixed in the snapshot from 18 July. Thanks! In this snapshot, the touchscreen no longer works at all. The only mention of wsmouse in dmesg is now: wsmouse0 at pms0 mux 0 That is, no mention of wsmouse1. After resume, my normal mouse no longer works. Suspend/resume is much more erratic now, too: sometimes zzz(1) will immediately suspend and then pressing the power button will cause it to immediately resume - this is typically what happens the first time I suspend after booting. Other times it will blank the screen and spin the fans loudly instead of suspending. Once it seemed to suspend just fine, but instead of resuming it just spun the fans loudly. Just now the system suspended then immediately resumed by itself - interestingly, the mouse works fine when that happens. Here's an Xorg.0.log from a successful suspend: [57.954] (--) checkDevMem: using aperture driver /dev/xf86 [57.974] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [58.022] X.Org X Server 1.15.2 Release Date: 2014-06-27 [58.022] X Protocol Version 11, Revision 0 [58.022] Build Operating System: OpenBSD 5.6 amd64 [58.022] Current Operating System: OpenBSD bellifortis.my.domain 5.6 GENERIC.MP#288 amd64 [58.023] Build Date: 17 July 2014 06:16:39PM [58.023] [58.024] Current version of pixman: 0.32.4 [58.024]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [58.024] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [58.024] (==) Log file: /var/log/Xorg.0.log, Time: Sun Jul 20 23:02:59 2014 [58.028] (==) Using system config directory /usr/X11R6/share/X11/xorg.conf.d [58.029] (==) No Layout section. Using the first Screen section. [58.030] (==) No screen section available. Using defaults. [58.030] (**) |--Screen Default Screen Section (0) [58.030] (**) | |--Monitor default monitor [58.031] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [58.031] (==) Disabling SIGIO handlers for input devices [58.032] (==) Automatically adding devices [58.032] (==) Automatically enabling devices [58.032] (==) Not automatically adding GPU devices [58.042] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [58.042] (==) ModulePath set to /usr/X11R6/lib/modules [58.042] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [58.043] (II) Loader magic: 0x1c01a8e07520 [58.043] (II) Module ABI versions: [58.043]X.Org ANSI C Emulation: 0.4 [58.043]X.Org Video Driver: 15.0 [58.043]X.Org XInput driver : 20.0 [58.043]X.Org Server Extension : 8.0 [58.044] (--) PCI:*(0:0:2:0) 8086:0166:17aa:21f9 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x4000/64 [58.044] Initializing built-in extension Generic Event Extension [58.044] Initializing built-in extension SHAPE [58.044] Initializing built-in extension MIT-SHM [58.044] Initializing built-in extension XInputExtension [58.044] Initializing built-in extension XTEST [58.044] Initializing built-in extension BIG-REQUESTS [58.044] Initializing built-in extension SYNC [58.044] Initializing built-in extension XKEYBOARD [58.044] Initializing built-in extension XC-MISC [58.044] Initializing built-in extension SECURITY [58.045] Initializing built-in extension XINERAMA [58.045] Initializing built-in extension XFIXES [58.045] Initializing built-in extension RENDER [58.045] Initializing built-in extension RANDR [58.045] Initializing built-in extension COMPOSITE [58.045] Initializing built-in extension DAMAGE [58.045] Initializing built-in extension MIT-SCREEN-SAVER [58.045] Initializing built-in extension DOUBLE-BUFFER [58.045] Initializing built-in extension RECORD [58.045] Initializing built-in extension DPMS [58.045] Initializing built-in extension Present [
Re: Running RESTORE(8) from standard in.
Robert Bruce Carleton r...@rbcarleton.com On Jul 20, 2014, at 2:27 PM, Robert Carleton r...@rbcarleton.com wrote: On Jul 20, 2014, at 2:24 PM, Philip Guenther guent...@gmail.com wrote: On Sun, Jul 20, 2014 at 2:06 PM, Robert Carleton r...@rbcarleton.com wrote: I'm using dump for backups to take advantage of the dump levels. I'd like to be able to run restore interactively, using the standard in as an input. Here's what I have in mind: # cd /tmp # ssh backup@10.0.0.10 cat /home/backup/0-var.dmp | restore -i -f - restore When I try it, it hangs on the first command I run, even the what command. top reports the wait for restore is ttyin. I'm running OpenBSD 5.5-stable, patch 8, compiled from source. The host is running on rootbsd.net's infrastructure, Xen running my host as a HVM I believe. First, if the remote machine is another openbsd box or has a compatible /etc/rmt command, then you may be able to just use restore -i -f backup@10.0.0.10:/home/backup/0-var.dmp The backup server is FreeBSD 9.2-RELEASE. I'll give that a try. If that works, it'll probably be the most efficient method. And yes, that will use ssh internally. Otherwise, the problem is probably just that ssh is reading your stdin as well. You can suppress that with its -n option. But do try the above method using rmt first Philip Guenther So rmt didn't work, but using -n with ssh did. Thanks! --Bruce
Re: During install MacBookAir5,2 screen goes blank, need external monitor
On 16 July 2014 00:49, Vasily Mikhaylichenko vas...@lxmx.com.au wrote: You'll need USB 2.0 emulation for the USB ports to work. There is a way to enable it on a MacBook: https://gist.github.com/jcs/5573685#openbsd-booting. Thanks for that Vasily, I tried with the AMD64 snapshot from 15/07/2014 todays, with legacy mode set the screen blanking returned but neither USB port was functional. Sevan / Venture37
Re: Are nc -lu /dev/zero /dev/null a good throughput test?
On 19 July 2014 21:22, Sean Kamath kam...@moltingpenguin.com wrote: Are you counting all those zeros to make sure they all came through? 'cause TCP is guaranteed delivery, in order. UDP guarantees nothing. Hello Sean! Why counting? My guess, and therefore the start of my reasoning and later questioning here, is that all those zeroes inside and UDP could flood the virtual network structure. May be you are confusing nc(1) with wc(1).
Re: Are nc -lu /dev/zero /dev/null a good throughput test?
On 19 July 2014 21:28, Philip Guenther guent...@gmail.com wrote: tcpbench(1) - TCP/UDP benchmarking and measurement tool Oh, just beneath my eyes, in the base install. Thank you, Philip. May I loose time comparing tcpbench(1) with iperf?
Re: Are nc -lu /dev/zero /dev/null a good throughput test?
On 14-07-20 04:57 PM, Raimundo Santos wrote: On 19 July 2014 21:22, Sean Kamath kam...@moltingpenguin.com wrote: Are you counting all those zeros to make sure they all came through? 'cause TCP is guaranteed delivery, in order. UDP guarantees nothing. Hello Sean! Why counting? My guess, and therefore the start of my reasoning and later questioning here, is that all those zeroes inside and UDP could flood the virtual network structure. May be you are confusing nc(1) with wc(1). No, what he meant was that using nc -u can produce false results. The sender can send as many packets as its CPU can possibly send, even if 99.9% of those packets are getting dropped by the receiver; the sender still thinks it successfully send a bazillion bytes per second even though it's a meaningless number. t I didn't know tcpbench(1) was in base, either... I always install and use iperf. I would expect both tcpbench and iperf to return very similar results. (Note that the results probably won't be perfectly identical, that's normal.) Using the -u flag to tcpbench(1) over a ~20Mbps radio link, the client reports throghput of 181Mbps, which is impossible. The server reports, simultaneously, 26Mbps. Both of these cannot be simultaneously true, right? Except they can - the client really is sending 181Mbps of traffic, the server really is receiving 26Mbps of traffic. What happened to the other 155Mbps of traffic? Dropped on the floor, probably by the radio. That's why you should run TCP benchmarks, or else be very careful with UDP benchmarks... Remember, too, that any out-of-order packets will kill real-world performance, and UDP has no guarantees about those, either. FWIW, you're almost certainly going to be CPU-bound. I can't get more than ~200Mbps on an emulated em(4) interface under ProxmoxVE (KVM 1.7.1) between two VMs running on the same host. Granted, the CPUs are slowish (2.2GHz Xeon L5520). I get better throughput using vio(4) but then I have to reboot the VMs once every 2 or 3 days to prevent them from locking up hard. Previous testing with VMware produced similar results circa OpenBSD v5.0. Some other guests were able to get ~2Gbps on the same VM stack, at the time. It is - almost by definition - impossible to flood the virtual network infrastructure without running out of CPU cycles in the guests first. It might be possible if the vSwitch is single-threaded, and you're running on a many-core CPU with each VM pegging its core(s) doing network I/O... but even then, remember that the vSwitch doesn't have to do any layer-3 processing, so it has much less work to do than the guest network stack. Where you do have to worry about running out of bandwidth is the switch handling traffic between your hypervisors, or more realistically, the network interface(s) leading from your host to said switch. Load-balancing (VMware ESXi v5.1) and LAGs (everywhere/everything else) are your friends here, unless you have the budget to install 10Gbps switches... -- -Adam Thompson athom...@athompso.net
Re: DVD how to overcome mkisofs
acording to https://wiki.archlinux.org/index.php/Optical_Disc_Drive_ , -use-the-force-luke=spare:none may be good for growisofs. ---tuyosi
l2tp / ipsec issue
Hey List,
I am trying to use OpenBSD 5.5 as an VPN end point for iOS 7.0 and OSX
10.9 native VPN clients, using L2TP / IPsec.
At the moment I am running the VPN end point on an internal server and
forwarding appropriate ports from the router:
- UDP 500 - Internet Key Exchange (IKE)
- UDP 1701 - L2TP traffic
- UDP 4500 - IPSec Network Address Translation (NAT-T)
(Long term plan is to replace the router with an OpenBSD box and
terminate the VPN there.)
It would seem that I am close, but can't over come this last issue.
When I attempt to connect from an iOS device, in /var/log/messages I see
this error message repeated several times:
--
Jul 20 17:51:52 access isakmpd[2979]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 25.1.65.61, responder id
XXX.XXX.XXX.XXX
Jul 20 17:51:52 access isakmpd[2979]: dropped message from
YYY.YYY.YYY.YYY port 16659 due to notification type
INVALID_ID_INFORMATION
--
Where XXX.XXX.XXX.XXX is the public ip address (in my case the cable
modem's external ip) and YYY.YYY.YYY.YYY is the iOS device attempting to
establish the vpn connection.
(The 25.1.65.61 address I don't recognize and appears to be UK Ministry
of Defence, so ah, wat? Assuming this is some weird
misconfiguration...)
The network topo looks like:
Internet - Cable Modem (XXX.XXX.XXX.XXX public ip) - Router Firewall
(forwarding ports) - OpenBSD
Any suggestions, even You can't do that, would be appreciated.
Gord.
Details:
Internal network is 192.168.2.x
/etc/rc.conf.local
--
isakmpd_flags=-K
ipsec=YES
--
/etc/npppd/npppd.conf
--
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 0.0.0.0
}
ipcp IPCP {
pool-address 192.168.2.150-192.168.2.199
dns-servers 8.8.8.8
}
interface pppx0 address 192.168.2.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
--
/etc/npppd/npppd-users
--
juser:\
:password=SEEKRIT:\
:framed-ip-address=192.168.2.150:
--
/etc/ipsec.conf
--
public_ip = 192.168.2.232
ike passive esp transport \
proto udp from $public_ip to any port 1701 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes \
psk SEEKRIT
--
/etc/pf.conf
--
pass quick proto { esp, ah } from any to any
pass in quick on egress proto udp from any to any port {500, 4500, 1701}
keep state
pass on enc0 from any to any keep state (if-bound)
--
/etc/sysctl.conf
--
net.inet.ip.forwarding=1
net.pipex.enable=1
--
--
$ dmesg
OpenBSD 5.5 (GENERIC) #271: Wed Mar 5 09:31:16 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 520081408 (495MB)
avail mem = 497725440 (474MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd9c0 (10 entries)
bios0: vendor Bochs version Bochs date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: QEMU Virtual CPU version 1.0, 3210.36 MHz
cpu0:
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,VMX,CX16,POPCNT,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 1.0 ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11
piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 10
iic0 at piixpm0
iic0: addr 0x4c 48=00 words 00= 01= 02= 03= 04=
05= 06= 07=
iic0: addr 0x4e 48=00 words 00= 01= 02= 03= 04=
05= 06= 07=
vga1 at pci0 dev 2 function 0 Cirrus Logic CL-GD5446 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio0 at virtio0: address 52:54:00:9b:3b:bc
virtio0: irq 11
virtio1 at pci0 dev 4 function 0 Qumranet Virtio Storage rev
Re: Dropping UDP Packets
On Fri, Jul 18, 2014 at 09:36:23AM +, Stuart Henderson wrote: On 2014-07-17, Darryl Wisneski s...@commwebworks.com wrote: netstat -s -p udp |grep dropped due to full socket 345197 dropped due to full socket buffers We're assuming this relates to openvpn packets but you can check which sockets have queues: (the sendq/recvq counters). netstat -an | grep -v ' 0 0' Sometimes now, sockets will display a queue and netstat -s will show a counter increase dropped due to full socket buffers. We usually have a SIP drop then. The two are not always coordinated, but mostly are. udp 8846 0 xxx.100.173.xxx.1195*.* udp 1448 0 xxx.100.173.xxx.1195*.* udp129 0 xxx.100.173.xxx.1194*.* udp177 0 xxx.100.173.xxx.1195*.* udp354 0 xxx.100.173.xxx.1195*.* udp 21115 0 xxx.100.173.xxx.1194*.* udp241 0 10.0.0.254.1195 *.* udp 2988 0 10.0.0.254.1195 *.* udp193 0 xxx.100.173.xxx.1195*.* udp 19591 0 xxx.100.173.xxx.1195*.* udp241 0 10.0.0.254.1195 *.* udp 20043 0 xxx.100.173.xxx.1195*.* udp 11878 0 xxx.100.173.xxx.1195*.* udp177 0 xxx.100.173.xxx.1195*.* udp193 0 xxx.100.173.xxx.1195*.* udp129 0 xxx.100.173.xxx.1194*.* So if things are building up here rather than on the interface queue, there ought to be a reason why it's slow to drain. Are you doing queueing? We are now doing queueing as a of very recently, but the same symptoms were occuring before when we had no queueing. We were at 50Mbit before very recently as well. The extra B/W did not help. How is fragmentation being handled? In OpenVPN or relying on the kernel to do it? Or are you using small mtu anyway to avoid frags? We are not tuning for fragmentation, nor are we setting mtu on the endpoint. How does pfctl -si look? sudo pfctl -si Status: Enabled for 1 days 15:58:58 Debug: err State Table Total Rate current entries 2694 searches 636512596 4422.1/s inserts 2978926 20.7/s removals 2977267 20.7/s Counters match3349507 23.3/s [snip] everything else 0.0/s I'm not sure how to proceed on tuning as I read tuning via sysctl is becoming pointless. It's preferred if things can auto-tune without touching sysctl, but not everything is done that way. net.inet.udp.sendspace=131028 # udp send buffer This may possibly need increasing though is already quite large. (while researching this mail it seems FreeBSD doesn't have this, does anyone here know what they do instead?) We have toggled net.inet.udp.sendspace and net.inet.udp.recvspace between 131028 and 262144 with no improvements. Anything higher and we get a hosed system... ifconfig ifconfig: socket: No buffer space available net.inet.ip.ifq.maxlen=1536 Monitor net.inet.ip.ifq.drops, is there an increase? No increases in net.inet.ip.ifq.drops through time. This is already a fairly large buffer though (especially as I think you mentioned 100Mb). How did you choose 1536? google and trial and error. kern.bufcachepercent=90 # kernel buffer cache memory percentage This won't help OpenVPN. Is this box also doing other things? This box is running IPSEC It's got four openvpn tunnels terminated on it. We are running collectd, symon, dhcpd. The load lives between 2 - 4. 2 usersLoad 3.09 3.07 2.91 Fri Jul 18 12:34:19 2014 PID USER NAME CPU10\ 20\ 30\ 40\ 50\ 60\ 70\ 80\ 90\ 100\ 8941 root acpi0 83.79 # idle 66.65 ### 22 root openvpn 2.49 # 23727 root openvpn 1.37 5473 root openvpn 1.27 load averages: 3.82, 3.08, 2.77fw0.xxx.xxx 12:00:21 86 processes: 85 idle, 1 on processor CPU0 states: 0.0% user, 0.0% nice, 86.6% system, 8.8% interrupt, 4.6% idle CPU1 states: 0.4% user, 0.0% nice, 7.8% system, 0.2% interrupt, 91.6% idle CPU2 states: 0.0% user, 0.0% nice, 5.2% system, 0.2% interrupt, 94.6% idle CPU3 states: 0.6% user, 0.0% nice, 5.0% system,
Re: Are nc -lu /dev/zero /dev/null a good throughput test?
On 20 July 2014 19:44, Adam Thompson athom...@athompso.net wrote: No, what he meant was that using nc -u can produce false results. Thank you Adam to point out my misinterpretation. Now I understand that Sean asked about how am I sure that all those zeroes generated in one host are really going to the other. The sender can send as many packets as its CPU can possibly send, even if 99.9% of those packets are getting dropped by the receiver; the sender still thinks it successfully send a bazillion bytes per second even though it's a meaningless number. Good point, as this: FWIW, you're almost certainly going to be CPU-bound. I can't get more than ~200Mbps on an emulated em(4) interface under ProxmoxVE (KVM 1.7.1) between two VMs running on the same host. Granted, the CPUs are slowish (2.2GHz Xeon L5520). I get better throughput using vio(4) but then I have to reboot the VMs once every 2 or 3 days to prevent them from locking up hard. What version of ProxmoxVE? I am considering this as a counterpart to XenServer, but I have some kind of faith in hypervisors in Xen and VMWare style, but in this project I can not afford VMWare prices. Thank you again, Adam!
Re: Are nc -lu /dev/zero /dev/null a good throughput test?
On Sun 20 Jul 2014 09:58:03 PM CDT, Raimundo Santos wrote: What version of ProxmoxVE? I am considering this as a counterpart to XenServer, but I have some kind of faith in hypervisors in Xen and VMWare style, but in this project I can not afford VMWare prices. I'm paying for the basic level of PVE subscription right now, which isn't very much (€30/host/year or something like that). I'm running their version of -CURRENT, that is to say, the testing repository. It hasn't burned me very many times so far :-/. The $/year entitles me to run the Enterprise version, and automatically get updates. That's a sensible thing to do when running in production. I'm not really in commercial production yet. OpenBSD runs... well, acceptably, I guess. If you use CEPH, make sure you mount your filesystems sync and set cache to writeback or you WILL encounter filesystem corruption each and every time your VM doesn't shut down cleanly. In my system, that reduces disk write performance to ~0.5MBytes/sec. I just remount async whenever I'm doing a large amount of disk I/O, then immediately remount sync when I'm done. And that's using the virtio driver! Running PVE (as opposed to VMware ESXi, say) makes crystal clear why Theo has misgivings about hypervisors in general... PVE exposes a lot more of the underlying OS than I'd like, or perhaps I should say I have to pay a lot more attention to the underlying OS than I'd like. Hardware zone/partition support like some of the high-end sun4v(??) machines looks better and better all the time. (Not too sure of the terminology right now.) -- -Adam Thompson athom...@athompso.net
Re: DVD how to overcome mkisofs
Hi al . xine is good , but big . i hear and see DVD by sudo mplayer dvd://1 -dvd-device /dev/rcd0c -aid 129 i owe http://sakamoto.fam.cx/index.cgi?p=Video%2FMPlayer . in my case ,i do ' sudo mplayer -v dvd://1 -dvd-device /dev/rcd0c ' then i get audio stream: 0 format: ac3 (5.1) language: en aid: 128. audio stream: 1 format: ac3 (5.1) language: ja aid: 129. number of audio channels on disk: 2. subtitle ( sid ): 1 language: ja subtitle ( sid ): 3 language: en and so . --- tuyosi
Re: l2tp / ipsec issue
the public_ip in your ipsec.conf should be the external ip of your router,
not the openbsd box.
other setup checks can be referred to the following article.
http://undeadly.org/cgi?action=articlesid=20120427125048
2014/7/21 ä¸å10:19 æ¼ Gordon Turner tur...@ftn.net 寫éï¼
Hey List,
I am trying to use OpenBSD 5.5 as an VPN end point for iOS 7.0 and OSX
10.9 native VPN clients, using L2TP / IPsec.
At the moment I am running the VPN end point on an internal server and
forwarding appropriate ports from the router:
- UDP 500 - Internet Key Exchange (IKE)
- UDP 1701 - L2TP traffic
- UDP 4500 - IPSec Network Address Translation (NAT-T)
(Long term plan is to replace the router with an OpenBSD box and terminate
the VPN there.)
It would seem that I am close, but can't over come this last issue.
When I attempt to connect from an iOS device, in /var/log/messages I see
this error message repeated several times:
--
Jul 20 17:51:52 access isakmpd[2979]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 25.1.65.61, responder id
XXX.XXX.XXX.XXX
Jul 20 17:51:52 access isakmpd[2979]: dropped message from YYY.YYY.YYY.YYY
port 16659 due to notification type INVALID_ID_INFORMATION
--
Where XXX.XXX.XXX.XXX is the public ip address (in my case the cable
modem's external ip) and YYY.YYY.YYY.YYY is the iOS device attempting to
establish the vpn connection.
(The 25.1.65.61 address I don't recognize and appears to be UK Ministry of
Defence, so ah, wat? Assuming this is some weird misconfiguration...)
The network topo looks like:
Internet - Cable Modem (XXX.XXX.XXX.XXX public ip) - Router Firewall
(forwarding ports) - OpenBSD
Any suggestions, even You can't do that, would be appreciated.
Gord.
Details:
Internal network is 192.168.2.x
/etc/rc.conf.local
--
isakmpd_flags=-K
ipsec=YES
--
/etc/npppd/npppd.conf
--
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 0.0.0.0
}
ipcp IPCP {
pool-address 192.168.2.150-192.168.2.199
dns-servers 8.8.8.8
}
interface pppx0 address 192.168.2.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
--
/etc/npppd/npppd-users
--
juser:\
:password=SEEKRIT:\
:framed-ip-address=192.168.2.150:
--
/etc/ipsec.conf
--
public_ip = 192.168.2.232
ike passive esp transport \
proto udp from $public_ip to any port 1701 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes \
psk SEEKRIT
--
/etc/pf.conf
--
pass quick proto { esp, ah } from any to any
pass in quick on egress proto udp from any to any port {500, 4500, 1701}
keep state
pass on enc0 from any to any keep state (if-bound)
--
/etc/sysctl.conf
--
net.inet.ip.forwarding=1
net.pipex.enable=1
--
--
$ dmesg
OpenBSD 5.5 (GENERIC) #271: Wed Mar 5 09:31:16 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 520081408 (495MB)
avail mem = 497725440 (474MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd9c0 (10 entries)
bios0: vendor Bochs version Bochs date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: QEMU Virtual CPU version 1.0, 3210.36 MHz
cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,VMX,CX16,POPCNT,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 1.0 ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11
piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 10
iic0 at piixpm0
iic0: addr 0x4c 48=00 words 00= 01= 02= 03= 04=
05= 06= 07=
iic0: addr 0x4e 48=00 words 00= 01= 02= 03= 04=
05= 06= 07=
vga1 at
