Re: res_init() and 0.0.0.0
On Tue, Sep 17, 2013 at 12:25:17AM -0400, Ted Unangst wrote:
On Mon, Sep 16, 2013 at 21:23, Kapetanakis Giannis wrote:
The following diff fixes the problem and the program works in current.
The program is bahamut ircd and I managed to make it work up to 5.3
without this.
In current it's broken due to resolver errors.
Don't know if you have a reason to not populate _res.nsaddr_list in the
new res_init() from asr interface.
I think a patch like this should go in. It's just easier to be
compatible with the stupid old _res interface for now. Maybe later we
can push programs to use the builtin async resolver.
In the mean time, some feedback on the diff.
_res.nscount = ac-ac_nscount;
+ for (i = 0; i ac-ac_nscount; i++) {
+ _res.nsaddr_list[i] = *((struct sockaddr_in *)
ac-ac_ns[i]);
+ }
+
I think this will give unexpected results if ipv6 resolvers are
configured. You'll notice the asr code is allocating possibly varying
amounts of memory. I think you're going to want to memcpy the correct
length.
memcpy(_res.nsaddr_list[i], ac-ac_ns[i], ac-ac_ns[i]-sa_len);
That's looks better indeed.
-Otto
Re: cvsync, rsync
Alexander Hall alexan...@beard.se wrote: Leaving the internals of rsync aside (of which I assume much but *know* little), if I consider two 4TB blobs to be equal just because they have the same SHA1 hash, I can easily see myself ending up in one of these conditions (but not both): This was git, not rsync. Perhaps the hash is only used as an index for a database, and if two blobs have equal hash, one will note it. It is necessary to see the details. As you see, many people do not have any problem with: A=B if hash(A)=hash(B). Perhaps it will become general programming thechnique. Rodrigo.
Re: cvsync, rsync
Marc Espie es...@nerim.net wrote: On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote: Marc Espie es...@nerim.net wrote: From a checksum I expect two things: (1) the pre-images of elements in the range have all similar sizes, Why ? This makes no sense, and is in contradiction with (2). I must correct my previous mail. The Domain is numerable, to speak about cardinality as size do not help, but perhaps you get the idea. The probability of colisions is stronly dependent on how the hash distributes the elements of the domain in the range. That's still a crypto hash. Apart from specially crafted attacks, input size is irrelevant to the chance of collision. It is not the input size, it is how the input is mapped. In the case of rsync the hash is applied to strings of a fixed lenth. In this case the input is finite and we can argue with cardinality. Just imagine the set finite strings mapped to a single element in the range. If all these sets have the same number of elements and the range n elements, then the probability of colition is n*(1/n)^2=1/nr; otherwise it is greater (simple school agebra to calculate it). The extreme case is that all strings are mapped to the same element. Rodrigo.
Re: Feedback about Desktop Environments
On Mon, Sep 16, 2013 at 06:15:50PM +0200, Marc Espie wrote: On Mon, Sep 16, 2013 at 03:18:28PM +, Stuart Henderson wrote: On 2013-09-16, Stefan Sperling s...@openbsd.org wrote: You can use hotplugd(8) to simulate an auto-mounter for known USB disks. hotplug-diskmount (in packages) saves a bit of time writing a script for this. Or there's amd(8) of course... No, don't use amd. Every time somebody uses amd, a kitten die (and we get that much farther away from being able to modernize NFS). Can you recommend an alternative automounter for network mounts? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: Ivy Bridge-EP Xeon (E5-2637v2) and Intel C602 Patsburg-A Chipset support
On 2013 Sep 16 (Mon) at 16:42:26 +0100 (+0100), Andy wrote: :I know that OpenBSD runs on any CPU which is based on the AMD64 :architecture, however someone has worried me and said that this CPU and :chipset is different somehow and might not boot with BSD!? Does Windows work with it? Does it claim it is x86 compatible? Then, yes it Just Works(tm). -- Goto, n.: A programming tool that exists to allow structured programmers to complain about unstructured programmers. -- Ray Simard
Re: Feedback about Desktop Environments
On Mon, Sep 16, 2013 at 5:18 PM, Stuart Henderson s...@spacehopper.org wrote: On 2013-09-16, Stefan Sperling s...@openbsd.org wrote: You can use hotplugd(8) to simulate an auto-mounter for known USB disks. hotplug-diskmount (in packages) saves a bit of time writing a script for this. And there's also this[1], for even better integration. [1] http://www.bsdua.org/tray-app.html#eject
Re: Ivy Bridge-EP Xeon (E5-2637v2) and Intel C602 Patsburg-A Chipset support
On Tue 17 Sep 2013 08:58:12 BST, Peter Hessler wrote: On 2013 Sep 16 (Mon) at 16:42:26 +0100 (+0100), Andy wrote: :I know that OpenBSD runs on any CPU which is based on the AMD64 :architecture, however someone has worried me and said that this CPU and :chipset is different somehow and might not boot with BSD!? Does Windows work with it? Does it claim it is x86 compatible? Then, yes it Just Works(tm). Hi, apparently Window support is not quite there yet (http://www.theregister.co.uk/2013/09/10/intel_ivy_bridge_xeon_e5_2600_v2_launch/) for OS Guard, which is an extension feature so I agree that it should work fine, just wanted to be careful before I spend a lot of cash on this new CPU and the C602 Patsburg-A Chipset. But otherwise yes its standard amd64, with the Intel AVX instruction set extensions. Thanks :)
Re: Feedback about Desktop Environments
Try E17: lightning fast, meek on requirements, user friendly. On Mon, Sep 16, 2013 at 12:18 PM, James Griffin j...@kontrol.kode5.netwrote: I need to install a Dektop Environment for my partner. I thought about KDE or xfce, i've tried neither on OpenBSD before. Which of the 3 main main DE's (gnome, KDE, XFCE) do you feel work best on OpenBSD. I would need things like removable media mounting from within the graphical environment, good sound support and multimedia applications. Any advice would be helpful from those using any of these Desktop's. I thought i'd ask on this list before installing loads of packages. Cheers, Jamie.
Re: Feedback about Desktop Environments
On Tue, Sep 17, 2013 at 10:47 AM, Paolo Aglialoro paol...@gmail.com wrote: Try E17: lightning fast, meek on requirements, user friendly. yes, it's nice. A bit buggy, but nice...
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote: Marc Espie es...@nerim.net wrote: On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote: Marc Espie es...@nerim.net wrote: From a checksum I expect two things: (1) the pre-images of elements in the range have all similar sizes, Why ? This makes no sense, and is in contradiction with (2). I must correct my previous mail. The Domain is numerable, to speak about cardinality as size do not help, but perhaps you get the idea. The probability of colisions is stronly dependent on how the hash distributes the elements of the domain in the range. That's still a crypto hash. Apart from specially crafted attacks, input size is irrelevant to the chance of collision. It is not the input size, it is how the input is mapped. In the case of rsync the hash is applied to strings of a fixed lenth. In this case the input is finite and we can argue with cardinality. Just imagine the set finite strings mapped to a single element in the range. If all these sets have the same number of elements and the range n elements, then the probability of colition is n*(1/n)^2=1/nr; otherwise it is greater (simple school agebra to calculate it). The extreme case is that all strings are mapped to the same element. I can not follow that calculation. A cryptographic hash is still designed to give a distribution of the hash value so that you can not even deliberately craft two inputs that give the same hash value, regardless of input (and thus input being e.g strings of fixed length). When you have two different real world contents the collision probability is just that; 2^-160 for SHA-1. It is when you deliberately craft a second content to match a known hash value there may be weaknesses in cryptographic hash functions, but this is not what rsync nor Git does, as Marc Espie pointed out in this thread. Rodrigo. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote: In the case of rsync the hash is applied to strings of a fixed lenth. In this case the input is finite and we can argue with cardinality. Just imagine the set finite strings mapped to a single element in the range. If all these sets have the same number of elements and the range n elements, then the probability of colition is n*(1/n)^2=1/nr; otherwise it is greater (simple school agebra to calculate it). The extreme case is that all strings are mapped to the same element. It doesn't really matter. You can go straight to the limit. If you choose a given collection of data, the chance of any other collection of data mapping to the exact same hash is 1/2^128, irregardless of its size.
Re: res_init() and 0.0.0.0
On 16/09/13 23:49, Stuart Henderson wrote: the ISC resolver is available in ports/net/libbind, this is used in some ports which fiddle with resolver internals in _res (e.g. net/mtr). Thanks for the tip. Indeed linking with libbind also fixed the problem with the program's resolver. The only problem I've found is the following warnings, which according to archive has to do with the snapshot being used(?). ./a.out:/usr/lib/libc.so.70.0: /usr/local/lib/libbind/libbind.so.3.0 : WARNING: symbol(__p_class_syms) size mismatch, relink your program ./a.out:/usr/lib/libc.so.70.0: ./a.out : WARNING: symbol(_res) size mismatch, relink your program ./a.out:/usr/lib/libc.so.70.0: /usr/local/lib/libbind/libbind.so.3.0 : WARNING: symbol(__p_type_syms) size mismatch, relink your program This is with the latest snapshot and libbind manually compiled from ports, after upgrading to latest snapshot (following the normal upgrade process). The only available libc in system is /usr/lib/libc.so.70.0 # ldd a.out a.out: StartEnd Type Open Ref GrpRef Name 1c00 3c004000 exe 10 0 a.out 01b9d000 21ba5000 rlib 01 0 /usr/local/lib/libbind/libbind.so.3.0 02f09000 22f39000 rlib 01 0 /usr/lib/libc.so.70.0 08e96000 08e96000 rtld 01 0 /usr/libexec/ld.so # ldconfig -r | grep libbind search directories: /usr/lib:/usr/X11R6/lib:/usr/local/lib:/usr/local/lib/libbind 142:-lbind.3.0 = /usr/local/lib/libbind/libbind.so.3.0 G
Re: Kernel panics on amd64 recently - do I have bad hardware?
This part: VOP_FSYNC() at VOP_FSYNC+0x2f ffs_sync_vnode() at ffs_sync_vnode+0x77 vfs_mount_foreach_vnode() at vfs_mount_foreach_vnode+0x38 ffs_sync() at ffs_sync+0x83 sys_sync() at sys_sync+0xa1 vfs_syncwait() at vfs_syncwait+0x50 vfs_shutdown() at vfs_shutdown+0x32 boot() at boot+0x17f panic() at panic+0xf6 is from the boot crash, not the original crash. Looking at the original crash: --- trap (number 8) --- ffs_update() at ffs_update+0x19f That points to the math in the ino_to_fsba() macro in this like of ffs_update() error = bread(ip-i_devvp, fsbtodb(fs, ino_to_fsba(fs, ip-i_number)), (int)fs-fs_bsize, bp); It's trying to calculate the block address of the inode so that it can update the timestamps in it and divided by zero. That means the in-memory copy of the superblock had zeros in on other another member. If the on-disk superblock had zeros there, I would expected fsck to catch it, or for it to crash earlier, but maybe a forced fsck is in order. Otherwise, something's writing through a bogus pointer in the kernel... Thank you so much, Philip. I ran each filesystem through a 'fsck -n' just to see what it thought, and it identified three filesystems that seemed to have issues. So, I dropped it down to single user and ran fsck on each one. It didn't say it fixed anything - kinda surprised me - but I ran fsck on every filesystem, and then did a 'fsck -p' for good measure. Everything came up clean? I booted it back and and I guess we'll see how things go... Thank you for your help! Benny -- No matter how tempted I am with the prospect of unlimited power, I will not consume any energy field bigger than my head. -- #22 on Peter Anspach's Evil Overlord list
Re: res_init() and 0.0.0.0
On 17/09/13 10:13, Otto Moerbeek wrote: On Tue, Sep 17, 2013 at 12:25:17AM -0400, Ted Unangst wrote: I think this will give unexpected results if ipv6 resolvers are configured. You'll notice the asr code is allocating possibly varying amounts of memory. I think you're going to want to memcpy the correct length. memcpy(_res.nsaddr_list[i], ac-ac_ns[i], ac-ac_ns[i]-sa_len); That's looks better indeed. -Otto Yes and of course it works. G
Re: cvsync, rsync
Alexander Hall alexan...@beard.se wrote: Leaving the internals of rsync aside (of which I assume much but *know* little), if I consider two 4TB blobs to be equal just because they have the same SHA1 hash, I can easily see myself ending up in one of these conditions (but not both): This was git, not rsync. The specific implementation was not the point. Perhaps the hash is only used as an index for a database, and if two blobs have equal hash, one will note it. It is necessary to see the details. Of course. As you see, many people do not have any problem with: A=B if hash(A)=hash(B). This was the point. Perhaps it will become general programming thechnique. I'd say it is already.
Re: pms0: not in sync yet, discard input (state 3)
as it seems like this is a legit regression, could this backed out please? -f -- between two evils, always pick the one you never tried before.
Re: Feedback about Desktop Environments
Regarding samba... there's no need to automount samba folders because you always can browse them via file browser (konqueror, thunar or nautilus), but if you want you can mount them in /etc/fstab. Simply read the documentation about permissions and syntax. It's very easy. For NFS the best way is mount them in /etc/fstab too. For external disks/pen drive, hotplug-diskmount, as Marc said, it's the best option. This pretty tool automount the drives when inserted and unmount when the drive is plugged off. If the drive is FAT you can extract it before unmount it. For other systems different from FAT you must unmount before extract. BR Jes On Tue, Sep 17, 2013 at 9:50 AM, Raimo Niskanen raimo+open...@erix.ericsson.se wrote: On Mon, Sep 16, 2013 at 06:15:50PM +0200, Marc Espie wrote: On Mon, Sep 16, 2013 at 03:18:28PM +, Stuart Henderson wrote: On 2013-09-16, Stefan Sperling s...@openbsd.org wrote: You can use hotplugd(8) to simulate an auto-mounter for known USB disks. hotplug-diskmount (in packages) saves a bit of time writing a script for this. Or there's amd(8) of course... No, don't use amd. Every time somebody uses amd, a kitten die (and we get that much farther away from being able to modernize NFS). Can you recommend an alternative automounter for network mounts? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
OpenBSD not forwarding SSL, strange.
I am having trouble accessing anything which uses SSL behind my NAT,
though I can access the same services from the firewall itself. There
is nothing unusual in /var/log/messages, dmesg, etc. I don't know why
this is happening. The system has been running fine for months, and
nothing I am aware of has changed.
# cat /etc/pf.conf
#Firewall ruleset for KintaroABODE router.
int_if=fxp0
wifi_if = athn0
tcp_services={ 22, 113 }
icmp_types=echoreq
fekete=192.168.0.3
fekete_tcp={ 17001, 8333 }
fekete_udp={ 8333 }
mises=192.168.0.4
mises_tcp={ 25565 }
#options
set block-policy drop
set loginterface egress
set skip on lo
anchor ftp-proxy/*
pass in on $int_if inet proto tcp to any port ftp \
divert-to 127.0.0.1 port 8021
table sshguard persist
#match rules
match out on egress inet from !(egress:network) to any nat-to (egress:0)
#filter rules
block in log
pass out quick
antispoof quick for { lo $int_if $wifi_if }
pass in on egress inet proto tcp from any to (egress) \
port $tcp_services
block in quick on egress proto tcp from sshguard \
to any port ssh label ssh bruteforce
pass in on egress inet proto tcp from any to (egress) port $fekete_tcp
rdr-to $fekete
pass in on egress inet proto tcp from any to (egress) port $fekete_udp
rdr-to $fekete
pass in on egress inet proto tcp from any to (egress) port $mises_tcp
rdr-to $mises
pass in inet proto icmp all icmp-type $icmp_types
pass in on $int_if
pass in on $wifi_if
If anyone could help and tell me where to start looking that would be
good. Some SSL services appear to work fine, such as gmail which I'm
using to send this.
--
www.johntate.org
Re: Feedback about Desktop Environments
On 2013-09-17, David Coppa dco...@gmail.com wrote: On Mon, Sep 16, 2013 at 5:18 PM, Stuart Henderson s...@spacehopper.org wrote: On 2013-09-16, Stefan Sperling s...@openbsd.org wrote: You can use hotplugd(8) to simulate an auto-mounter for known USB disks. hotplug-diskmount (in packages) saves a bit of time writing a script for this. And there's also this[1], for even better integration. [1] http://www.bsdua.org/tray-app.html#eject Now in ports. :)
Re: Ivy Bridge-EP Xeon (E5-2637v2) and Intel C602 Patsburg-A Chipset support
On 2013-09-16, Andy a...@brandwatch.com wrote: Planning to test Hennings new ALTQ subsystem diff on OpenBSD 5.4 with this hardware :D pardon the pedantry, but it's not altq..
Re: res_init() and 0.0.0.0
On 2013-09-17, Kapetanakis Giannis bil...@edu.physics.uoc.gr wrote: On 16/09/13 23:49, Stuart Henderson wrote: the ISC resolver is available in ports/net/libbind, this is used in some ports which fiddle with resolver internals in _res (e.g. net/mtr). Thanks for the tip. Indeed linking with libbind also fixed the problem with the program's resolver. The only problem I've found is the following warnings, which according to archive has to do with the snapshot being used(?). ./a.out:/usr/lib/libc.so.70.0: /usr/local/lib/libbind/libbind.so.3.0 : WARNING: symbol(__p_class_syms) size mismatch, relink your program ./a.out:/usr/lib/libc.so.70.0: ./a.out : WARNING: symbol(_res) size mismatch, relink your program ./a.out:/usr/lib/libc.so.70.0: /usr/local/lib/libbind/libbind.so.3.0 : WARNING: symbol(__p_type_syms) size mismatch, relink your program This is with the latest snapshot and libbind manually compiled from ports, after upgrading to latest snapshot (following the normal upgrade process). The only available libc in system is /usr/lib/libc.so.70.0 # ldd a.out a.out: StartEnd Type Open Ref GrpRef Name 1c00 3c004000 exe 10 0 a.out 01b9d000 21ba5000 rlib 01 0 /usr/local/lib/libbind/libbind.so.3.0 02f09000 22f39000 rlib 01 0 /usr/lib/libc.so.70.0 08e96000 08e96000 rtld 01 0 /usr/libexec/ld.so # ldconfig -r | grep libbind search directories: /usr/lib:/usr/X11R6/lib:/usr/local/lib:/usr/local/lib/libbind 142:-lbind.3.0 = /usr/local/lib/libbind/libbind.so.3.0 G yes, current resolvers have a few more resource types and classes than the old arrays in libc, we should update them sometime.
Re: pms0: not in sync yet, discard input (state 3)
On Tue, Sep 17, 2013 at 02:36:25PM +0200, frantisek holop wrote: as it seems like this is a legit regression, could this backed out please? Which commit exactly needs to be backed out?
Re: pms0: not in sync yet, discard input (state 3)
hmm, on Tue, Sep 17, 2013 at 02:56:30PM +0200, Stefan Sperling said that On Tue, Sep 17, 2013 at 02:36:25PM +0200, frantisek holop wrote: as it seems like this is a legit regression, could this backed out please? Which commit exactly needs to be backed out? my guess would be the ones done after aug 19.. that one was working. -f -- anarchy is better than no government at all.
Re: cvsync, rsync
Raimo Niskanen raimo+open...@erix.ericsson.se wrote: When you have two different real world contents the collision probability is just that; 2^-160 for SHA-1. It is when you deliberately craft a second content to match a known hash value there may be weaknesses in cryptographic hash functions, but this is not what rsync nor Git does, as Marc Espie pointed out in this thread. You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? Rodrigo.
Re: OpenBSD not forwarding SSL, strange.
On Tue, Sep 17, 2013 at 10:42:55PM +1000, John Tate wrote:
I am having trouble accessing anything which uses SSL behind my NAT,
though I can access the same services from the firewall itself. There
is nothing unusual in /var/log/messages, dmesg, etc. I don't know why
this is happening. The system has been running fine for months, and
nothing I am aware of has changed.
# cat /etc/pf.conf
#Firewall ruleset for KintaroABODE router.
int_if=fxp0
wifi_if = athn0
tcp_services={ 22, 113 }
icmp_types=echoreq
fekete=192.168.0.3
fekete_tcp={ 17001, 8333 }
fekete_udp={ 8333 }
mises=192.168.0.4
mises_tcp={ 25565 }
#options
set block-policy drop
set loginterface egress
set skip on lo
anchor ftp-proxy/*
pass in on $int_if inet proto tcp to any port ftp \
divert-to 127.0.0.1 port 8021
table sshguard persist
#match rules
match out on egress inet from !(egress:network) to any nat-to (egress:0)
#filter rules
block in log
pass out quick
antispoof quick for { lo $int_if $wifi_if }
pass in on egress inet proto tcp from any to (egress) \
port $tcp_services
block in quick on egress proto tcp from sshguard \
to any port ssh label ssh bruteforce
pass in on egress inet proto tcp from any to (egress) port $fekete_tcp
rdr-to $fekete
pass in on egress inet proto tcp from any to (egress) port $fekete_udp
rdr-to $fekete
pass in on egress inet proto tcp from any to (egress) port $mises_tcp
rdr-to $mises
pass in inet proto icmp all icmp-type $icmp_types
pass in on $int_if
pass in on $wifi_if
If anyone could help and tell me where to start looking that would be
good. Some SSL services appear to work fine, such as gmail which I'm
using to send this.
sysctl -a ?
j.
Re: cvsync, rsync
Marc Espie es...@nerim.net wrote: On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote: In the case of rsync the hash is applied to strings of a fixed lenth. In this case the input is finite and we can argue with cardinality. Just imagine the set finite strings mapped to a single element in the range. If all these sets have the same number of elements and the range n elements, then the probability of colition is n*(1/n)^2=1/nr; otherwise it is greater (simple school agebra to calculate it). The extreme case is that all strings are mapped to the same element. It doesn't really matter. You can go straight to the limit. If you choose a given collection of data, the chance of any other collection of data mapping to the exact same hash is 1/2^128, irregardless of its size. I state you the same question that I stated Raimo Niskanen in my previous mail. I think you misunderstand me: I am not speaking about the size of the input strings, but about the size of sets of input strings. Rodrigo.
Re: Ivy Bridge-EP Xeon (E5-2637v2) and Intel C602 Patsburg-A Chipset support
On Tue 17 Sep 2013 13:48:45 BST, Stuart Henderson wrote: On 2013-09-16, Andy a...@brandwatch.com wrote: Planning to test Hennings new ALTQ subsystem diff on OpenBSD 5.4 with this hardware :D pardon the pedantry, but it's not altq.. Lol, yes sorry ;) *ALTQ's replacement.. Does it have a name yet, or are you sticking with; new super duper simple prio queuer?
Re: OpenBSD not forwarding SSL, strange.
# sysctl -a kern.ostype=OpenBSD kern.osrelease=5.3 kern.osrevision=201305 kern.version=OpenBSD 5.3 (GENERIC) #50: Tue Mar 12 18:35:23 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC kern.maxvnodes=5926 kern.maxproc=1310 kern.maxfiles=7030 kern.argmax=262144 kern.securelevel=1 kern.hostname=menger.kab.loc kern.hostid=0 kern.clockrate=tick = 1, tickadj = 40, hz = 100, profhz = 1024, stathz = 128 kern.posix1version=199009 kern.ngroups=16 kern.job_control=1 kern.saved_ids=1 kern.boottime=Tue Sep 17 21:58:10 2013 kern.domainname= kern.maxpartitions=16 kern.rawpartition=2 kern.maxthread=1950 kern.nthreads=35 kern.osversion=GENERIC#50 kern.somaxconn=128 kern.sominconn=80 kern.usermount=0 kern.random=2434 3584 0 469612 7 0 0 0 0 0 0 0 355 29 849846 2 30 0 3 5 12 26 40 45 34 48 21 25 28 18 6 5 3 1 1 0 1 2 0 0 0 0 0 0 0 1 0 0 0 29 0 0 130 196 0 0 0 0 0 0 1395 1451 0 0 kern.nosuidcoredump=1 kern.fsync=1 kern.sysvmsg=1 kern.sysvsem=1 kern.sysvshm=1 kern.arandom=1443230486 kern.msgbufsize=16364 kern.malloc.buckets=16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288 kern.malloc.bucket.16=(calls = 14449 total_allocated = 1024 total_free = 236 elements = 256 high watermark = 1280 could_free = 0) kern.malloc.bucket.32=(calls = 1876 total_allocated = 640 total_free = 338 elements = 128 high watermark = 640 could_free = 0) kern.malloc.bucket.64=(calls = 2674 total_allocated = 1920 total_free = 304 elements = 64 high watermark = 320 could_free = 0) kern.malloc.bucket.128=(calls = 2689 total_allocated = 320 total_free = 50 elements = 32 high watermark = 160 could_free = 0) kern.malloc.bucket.256=(calls = 3729 total_allocated = 144 total_free = 33 elements = 16 high watermark = 80 could_free = 0) kern.malloc.bucket.512=(calls = 5249 total_allocated = 408 total_free = 10 elements = 8 high watermark = 40 could_free = 0) kern.malloc.bucket.1024=(calls = 491 total_allocated = 264 total_free = 3 elements = 4 high watermark = 20 could_free = 0) kern.malloc.bucket.2048=(calls = 111 total_allocated = 12 total_free = 1 elements = 2 high watermark = 10 could_free = 0) kern.malloc.bucket.4096=(calls = 93 total_allocated = 31 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.8192=(calls = 15 total_allocated = 11 total_free = 1 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.16384=(calls = 6 total_allocated = 6 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.32768=(calls = 7 total_allocated = 6 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.65536=(calls = 3 total_allocated = 2 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.131072=(calls = 0 total_allocated = 0 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.262144=(calls = 0 total_allocated = 0 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.bucket.524288=(calls = 0 total_allocated = 0 total_free = 0 elements = 1 high watermark = 5 could_free = 0) kern.malloc.kmemnames=free,,devbuf,debug,pcb,routetbl,,fragtbl,,ifaddr,soopts,sysctl,,,ioctlops,iov,mount,,NFS_req,NFS_mount,,vnodes,namecache,UFS_quota,UFS_mount,shm,VM_map,sem,dirhash,ACPI,VM_pmapfile,file_desc,,proc,subproc,VFS_cluster,,,MFS_node,,,Export_Host,NFS_srvsock,,NFS_daemon,ip_moptions,in_multi,ether_multi,mrt,ISOFS_mount,ISOFS_node,MSDOSFS_mount,MSDOSFS_fat,MSDOSFS_node,ttys,exec,miscfs_mount,,pfkey_data,tdb,xform_data,,pagedep,inodedep,newblk,,,indirdep,VM_swap,,UVM_amap,UVM_aobj,,USB,USB_device,USB_HC,,memdesc,,,crypto_data,,IPsec_credsemuldata,ip6_options,NDP,,,temp,NTFS_mount,NTFS_node,NTFS_fnode,NTFS_dir,NTFS_hash,NTFS_attr,NTFS_data,NTFS_decomp,NTFS_vrun,kqueue,bluetooth,bwmeter,UDF_mount,UDF_file_entry,UDF_file_id,Bluetooth_HID,AGP_Memory,DRM kern.malloc.kmemstat.free=(inuse = 0, calls = 0, memuse = 0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0, sizes = (none)) kern.malloc.kmemstat.devbuf=(inuse = 828, calls = 1511, memuse = 571K, limblocks = 0, mapblocks = 0, maxused = 571K, limit = 39322K, spare = 0, sizes = (16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536)) kern.malloc.kmemstat.debug=(inuse = 0, calls = 0, memuse = 0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0, sizes = (none)) kern.malloc.kmemstat.pcb=(inuse = 31, calls = 57, memuse = 6K, limblocks = 0, mapblocks = 0, maxused = 6K, limit = 39322K, spare = 0, sizes = (16,64,512)) kern.malloc.kmemstat.routetbl=(inuse = 105, calls = 811, memuse = 8K, limblocks = 0, mapblocks = 0, maxused = 32K, limit = 39322K, spare = 0, sizes = (16,32,64,128,256,512)) kern.malloc.kmemstat.fragtbl=(inuse = 0, calls = 0, memuse = 0K, limblocks = 0, mapblocks = 0, maxused = 0K, limit = 39322K, spare = 0, sizes = (none)) kern.malloc.kmemstat.ifaddr=(inuse = 159, calls = 159, memuse = 20K, limblocks = 0, mapblocks = 0,
Re: Ivy Bridge-EP Xeon (E5-2637v2) and Intel C602 Patsburg-A Chipset support
On Tue, Sep 17, 2013 at 02:35:48PM +0100, Andy wrote: On Tue 17 Sep 2013 13:48:45 BST, Stuart Henderson wrote: On 2013-09-16, Andy a...@brandwatch.com wrote: Planning to test Hennings new ALTQ subsystem diff on OpenBSD 5.4 with this hardware :D pardon the pedantry, but it's not altq.. Lol, yes sorry ;) *ALTQ's replacement.. Does it have a name yet, or are you sticking with; new super duper simple prio queuer? IIRC simple prio emulates/uses just 'prio' in VLAN header. The new queueing is called in henning@'s paper new OpenBSD queueing subsystem :) j.
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 01:21:04PM +, hru...@gmail.com wrote: Raimo Niskanen raimo+open...@erix.ericsson.se wrote: When you have two different real world contents the collision probability is just that; 2^-160 for SHA-1. It is when you deliberately craft a second content to match a known hash value there may be weaknesses in cryptographic hash functions, but this is not what rsync nor Git does, as Marc Espie pointed out in this thread. You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? You have to mean what is the probability that A != B, and it is 2 ^ (-160). If you actually mean what you wrote, the probability of A = B is 1 - (2 ^ (-160)), which is as said earlier in this thread higher than what you get when storing the string on disk and then reading it back. Rodrigo. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: pms0: not in sync yet, discard input (state 3)
On Tue, Sep 17, 2013 at 02:59:19PM +0200, frantisek holop wrote:
hmm, on Tue, Sep 17, 2013 at 02:56:30PM +0200, Stefan Sperling said that
On Tue, Sep 17, 2013 at 02:36:25PM +0200, frantisek holop wrote:
as it seems like this is a legit regression,
could this backed out please?
Which commit exactly needs to be backed out?
my guess would be the ones done after aug 19..
that one was working.
Guesses won't help much. We need facts to figure out what's wrong.
This diff backs out r1.46. Does it help?
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.47
diff -u -p -r1.47 pms.c
--- pms.c 3 Sep 2013 09:29:35 - 1.47
+++ pms.c 17 Sep 2013 14:06:03 -
@@ -910,11 +910,6 @@ synaptics_get_hwinfo(struct pms_softc *s
if (SYNAPTICS_EXT_MODEL_BUTTONS(syn-ext_model) 8)
syn-ext_model = ~0xf000;
- if ((syn-model SYNAPTICS_MODEL_NEWABS) == 0) {
- printf(%s: don't support Synaptics OLDABS\n, DEVNAME(sc));
- return (-1);
- }
-
return (0);
}
@@ -990,9 +985,12 @@ pms_enable_synaptics(struct pms_softc *s
goto err;
}
- if (synaptics_get_hwinfo(sc)) {
- free(sc-synaptics, M_DEVBUF);
- sc-synaptics = NULL;
+ if (synaptics_get_hwinfo(sc))
+ goto err;
+
+ if ((syn-model SYNAPTICS_MODEL_NEWABS) == 0) {
+ printf(%s: don't support Synaptics OLDABS\n,
+ DEVNAME(sc));
goto err;
}
@@ -1030,6 +1028,11 @@ pms_enable_synaptics(struct pms_softc *s
return (1);
err:
+ if (sc-synaptics) {
+ free(sc-synaptics, M_DEVBUF);
+ sc-synaptics = NULL;
+ }
+
pms_reset(sc);
return (0);
@@ -1272,11 +1275,8 @@ pms_enable_alps(struct pms_softc *sc)
goto err;
}
- if (alps_get_hwinfo(sc)) {
- free(sc-alps, M_DEVBUF);
- sc-alps = NULL;
+ if (alps_get_hwinfo(sc))
goto err;
- }
printf(%s: ALPS %s, version 0x%04x\n, DEVNAME(sc),
(alps-model ALPS_DUALPOINT ? Dualpoint : Glidepoint),
@@ -1339,6 +1339,11 @@ pms_enable_alps(struct pms_softc *sc)
return (1);
err:
+ if (sc-alps) {
+ free(sc-alps, M_DEVBUF);
+ sc-alps = NULL;
+ }
+
pms_reset(sc);
return (0);
@@ -1829,11 +1834,8 @@ pms_enable_elantech_v1(struct pms_softc
goto err;
}
- if (elantech_get_hwinfo_v1(sc)) {
- free(sc-elantech, M_DEVBUF);
- sc-elantech = NULL;
+ if (elantech_get_hwinfo_v1(sc))
goto err;
- }
printf(%s: Elantech Touchpad, version %d\n, DEVNAME(sc), 1);
} else if (elantech_set_absolute_mode_v1(sc))
@@ -1845,6 +1847,11 @@ pms_enable_elantech_v1(struct pms_softc
return (1);
err:
+ if (sc-elantech) {
+ free(sc-elantech, M_DEVBUF);
+ sc-elantech = NULL;
+ }
+
pms_reset(sc);
return (0);
@@ -1867,11 +1874,8 @@ pms_enable_elantech_v2(struct pms_softc
goto err;
}
- if (elantech_get_hwinfo_v2(sc)) {
- free(sc-elantech, M_DEVBUF);
- sc-elantech = NULL;
+ if (elantech_get_hwinfo_v2(sc))
goto err;
- }
printf(%s: Elantech Touchpad, version %d\n, DEVNAME(sc), 2);
} else if (elantech_set_absolute_mode_v2(sc))
@@ -1880,6 +1884,11 @@ pms_enable_elantech_v2(struct pms_softc
return (1);
err:
+ if (sc-elantech) {
+ free(sc-elantech, M_DEVBUF);
+ sc-elantech = NULL;
+ }
+
pms_reset(sc);
return (0);
@@ -1902,11 +1911,8 @@ pms_enable_elantech_v3(struct pms_softc
goto err;
}
- if (elantech_get_hwinfo_v3(sc)) {
- free(sc-elantech, M_DEVBUF);
- sc-elantech = NULL;
+ if (elantech_get_hwinfo_v3(sc))
goto err;
- }
printf(%s: Elantech Touchpad, version %d\n, DEVNAME(sc), 3);
} else if (elantech_set_absolute_mode_v3(sc))
@@ -1915,6 +1921,11 @@ pms_enable_elantech_v3(struct pms_softc
return (1);
err:
+ if (sc-elantech) {
+ free(sc-elantech, M_DEVBUF);
+ sc-elantech = NULL;
+ }
+
pms_reset(sc);
return (0);
@@ -1937,11 +1948,8 @@
Re: pms0: not in sync yet, discard input (state 3)
On 17/09/13(Tue) 14:59, frantisek holop wrote: hmm, on Tue, Sep 17, 2013 at 02:56:30PM +0200, Stefan Sperling said that On Tue, Sep 17, 2013 at 02:36:25PM +0200, frantisek holop wrote: as it seems like this is a legit regression, could this backed out please? Which commit exactly needs to be backed out? my guess would be the ones done after aug 19.. that one was working. Could you try to commenting out all the protocol definitions in the pms_protocols[] table but the Elantech v2 one and tell me if it works? If that's working could you reiterate the manipulation by enabling one by one the protocols defined before this one and find out which addition breaks your mouse? Thanks, Martin
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 01:21:04PM +, hru...@gmail.com wrote: Raimo Niskanen raimo+open...@erix.ericsson.se wrote: When you have two different real world contents the collision probability is just that; 2^-160 for SHA-1. It is when you deliberately craft a second content to match a known hash value there may be weaknesses in cryptographic hash functions, but this is not what rsync nor Git does, as Marc Espie pointed out in this thread. You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No, that's never the problem. You have a *given* string A, and another string B. The problem you are describing is a different problem that leads straight to the birthday paradox... I don't know if the issue lies with your mastery of the english language, or with your understanding of the issue. But you still sound very much confused.
Re: Ivy Bridge-EP Xeon (E5-2637v2) and Intel C602 Patsburg-A Chipset support
Oh yea, just look at the slides.. Dohh ;) On Tue 17 Sep 2013 14:54:12 BST, Jiri B wrote: On Tue, Sep 17, 2013 at 02:35:48PM +0100, Andy wrote: On Tue 17 Sep 2013 13:48:45 BST, Stuart Henderson wrote: On 2013-09-16, Andy a...@brandwatch.com wrote: Planning to test Hennings new ALTQ subsystem diff on OpenBSD 5.4 with this hardware :D pardon the pedantry, but it's not altq.. Lol, yes sorry ;) *ALTQ's replacement.. Does it have a name yet, or are you sticking with; new super duper simple prio queuer? IIRC simple prio emulates/uses just 'prio' in VLAN header. The new queueing is called in henning@'s paper new OpenBSD queueing subsystem :) j.
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 01:27:06PM +, hru...@gmail.com wrote: Marc Espie es...@nerim.net wrote: On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote: In the case of rsync the hash is applied to strings of a fixed lenth. In this case the input is finite and we can argue with cardinality. Just imagine the set finite strings mapped to a single element in the range. If all these sets have the same number of elements and the range n elements, then the probability of colition is n*(1/n)^2=1/nr; otherwise it is greater (simple school agebra to calculate it). The extreme case is that all strings are mapped to the same element. It doesn't really matter. You can go straight to the limit. If you choose a given collection of data, the chance of any other collection of data mapping to the exact same hash is 1/2^128, irregardless of its size. I state you the same question that I stated Raimo Niskanen in my previous mail. I think you misunderstand me: I am not speaking about the size of the input strings, but about the size of sets of input strings. At least I can not follow your line of reasoning here. Suppose you are limited to length 1 strings of [a-z], then you have 29 possible strings. Still. If you select one of those strings and calculates its SHA-1 hash value. When you try any of the other 28 strings (or any other string of any lenght) and calculates this other strings SHA-1 hash value, the probability that it has the same hash value is 2 ^ (-160). Rodrigo. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: cvsync, rsync
I wrote to the list. If you have something to say about the thema, then please to the list. Your impolite mails are not welcome in my mailbox. Rodrigo. Jan Stary h...@stare.cz wrote: On Sep 17 13:21:04, hru...@gmail.com wrote: Raimo Niskanen raimo+open...@erix.ericsson.se wrote: When you have two different real world contents the collision probability is just that; 2^-160 for SHA-1. It is when you deliberately craft a second content to match a known hash value there may be weaknesses in cryptographic hash functions, but this is not what rsync nor Git does, as Marc Espie pointed out in this thread. You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No. The probability that A!= B is 2^-160. However, this is irrelevant to the problem you are describing. Please don't enbarass yourself any further and take this silly issue somewhere else; preferably to your English teacher.
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 03:28:11PM +, hru...@gmail.com wrote: Marc Espie es...@nerim.net wrote: You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No, that's never the problem. You have a *given* string A, and another string B. O.K. You have string A in the client with hash(A)=n. You find string B in the server also with hash(B)=n. What is the probability that A=B? 1-1/2^n (with n the size of the crypto hash, so 128 or 160 for the hashes being discussed). ... unless someone is out to get you, of course. In such a case, forget about normal probability rules. Your B is not uniformously random. But in general, in case of foul play, you have ways ways more to worry about than whether your hash is going to match! (and the attacks we know about for md5 and sha1 are of the choose preimage variety, so it's for files A and B that *the attacker* can choose, not your own A file, and a B file chosen by the attacker).
Re: cvsync, rsync
Intentionally I left the problem generic. Is the probability near to 1? You can suppose that A is 500 bytes long, that the server knows the hash value of A (but not A), that it searchs only strings of this length with the same hash value, that it found such a string B, that the hash function is the concatenation of the rolling hash of rsync with md4. You can also suppose that A and B are 4 TB long and the hash sha1. Rodrigo. Tony Abernethy t...@servasoftware.com wrote: INSUFFICIENT DATA -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of hru...@gmail.com Sent: Tuesday, September 17, 2013 10:28 AM To: misc@openbsd.org Subject: Re: cvsync, rsync Marc Espie es...@nerim.net wrote: You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No, that's never the problem. You have a *given* string A, and another string B. O.K. You have string A in the client with hash(A)=n. You find string B in the server also with hash(B)=n. What is the probability that A=B? Rodrigo.
Re: responding to buttonpress ACPI event sent by KVM/Qemu (same behavior in v5.2)
Resurrecting this thread, since I also got a total freeze in Qemu/KVM after sending ACPI shutdown using OpenBSD 5.3. Testing, I also tried 5.3 in VirtualBox and VMWare, both gave clean shutdown. This makes me suspect KVM is at fault... QEMU/KVM (echo system_powerdown | nc -U /tmp/test1.monitor ) --- total freeze VirtualBox (ACPI shutdown) -- clean shutdown VMWare Fusion (Shutdown) -- clean shutdown FWIW, I'm using an illumos/omnios host on AMD hardware. Probably not purely a KVM problem; I'm running OpenBSD 5.3-RELEASE inside KVM (ProxmoxVE 3.1 platform) on Intel CPUs, and ACPI handling works correctly. I also recall testing OpenBSD 5.2-RELEASE inside RedHat Enterprise Virtualization (also KVM-based) and it worked fine there on AMD chips. The only HVM-related issues I've been able to find are a) speed [no surprise there], and b) the long-standing red-console-background effect when switching VTs. This implies that you're seeing a bizarre interaction between your guest, your host, and the VM software. It's remotely possible your hardware has something to do with it, but unlikely. I haven't tested anything illumos-based. -Adam Thompson athom...@athompso.net
Re: cvsync, rsync
Marc Espie es...@nerim.net wrote: You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No, that's never the problem. You have a *given* string A, and another string B. O.K. You have string A in the client with hash(A)=n. You find string B in the server also with hash(B)=n. What is the probability that A=B? Rodrigo.
This 48 core box...
I'm considering bidding on this 48-core box: http://www.ebay.com/itm/Supermicro-A-Server-1042G-TF-1U-H8QG6-4-CPUS-48-cores-2-2Ghz-128GB-RAM-/151119828428?pt=COMP_EN_Servershash=item232f7195cc Does anyone have experience with it and can I use all the cores? Thanks!
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 04:16:47PM +, hru...@gmail.com wrote: Intentionally I left the problem generic. Is the probability near to 1? YES it is near to 1. Your way to phrase mathematical problems is BOGUS. You can't do probability without formulating a set of complete hypothesis. Your way to reason about this is BOGUS. We've been telling you THE EXACT SAME THING about those hash properties for MESSAGES by now. It seems it doesn't get through. This is either indicative of a very poor grasp of english, or of mathematical concepts, or both. So I'm going to finally stop answering your stupid stupid questions. I've got a feeling you don't trust those programs because you really don't understand numbers in an intuitive way. Like I said, FUD. Just because you feel insecure about numbers doesn't mean you have to try to communicate your insecurity about it to other people.
pf.conf for OpenVPN
Dear All, I am still working on OpenVPN gateway for my Lab. As of now I have everything fully functional and I am trying now to tide up PF rules. My network topology roughly looks like this Internet (128.xxx) OpenVPN clients (VPN network 10.8.0.xxx) | Also Public 128.xxx addresses || || -- | ext_if/tun0 (128.0.0.1/10.8.0.1) | Firewall/VPN Gateway (OpenBSD 5.4) | | int_if (192.168.2.1) | - Switch --- DNS/LDAP/FileServer (192.168.2.32/8) || || |- other desktops (192.168.2.64/8) | | SSH Gateway (192.168.2.200)HPC machines on (192.168.2.128/8) Following PF FAQ, Peter's book of PF and Absolute OpenBSD 2nd edition I had no troubles writing rules which filter trafic on ext_if as well as int_if. Clients behind Firewall can access selected internet services (ssh, SMTP,www). A random machine which tries to reach my internal network via SSH gets redirected to SSH gateway machine. Since I have no experience managing OpenVPNs I have questions about VPN network (10.8.0.xxx) 1. Right now I pass UDP packets on ext_if port 1194 to allow VPN clients to connect to server. Is that correct? Is there more restricitve way of doing this. 2. I would like to filter traffic coming and going from 10.8.0.xxx. Do I write separate rules for tun0 interface? 3. Do I use rdr to allow OpenVPN clients from VPN network 10.8.0.xxx to reach my internal network (192.168.2.xxx)? I would like VPN clients to have the same access to my HPC clusters, DNS etc as my desktops behind PF. Thank you so much for you help. Predrag
Re: cvsync, rsync
INSUFFICIENT DATA -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of hru...@gmail.com Sent: Tuesday, September 17, 2013 10:28 AM To: misc@openbsd.org Subject: Re: cvsync, rsync Marc Espie es...@nerim.net wrote: You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No, that's never the problem. You have a *given* string A, and another string B. O.K. You have string A in the client with hash(A)=n. You find string B in the server also with hash(B)=n. What is the probability that A=B? Rodrigo.
Re: cvsync, rsync
Kenneth R Westerback kwesterb...@rogers.com wrote: And your endless meanderings around the pointless questions you pose are not welcome on the list. They certainly have NOTHING to do with OpenBSD. What you say in the last sentence is exactly what I hope. One of my questions was: This is a conjecture. Do you have a proof that the probability is so small? For me it is difficult to accept it. Is this conjecture used elsewhere? Rodrigo.
Re: cvsync, rsync
But in general, in case of foul play, you have ways ways more to worry about than whether your hash is going to match! (and the attacks we know about for md5 and sha1 are of the choose preimage variety, so it's for files A and B that *the attacker* can choose, not your own A file, and a B file chosen by the attacker). In git case, you have also to think the damage due to the attack is also limited due to the distributed behaviour of it. Maybe someone can create a git object with the same hash value of one previous, but this change will not be propagated in the net, so all the others copies of the original object will be conserved in the network. And of course, the probability of creating a new git object with the same hash than other previous and correct linked is zero. -- Roberto E. Vargas Caballero k...@shike2.com http://www.shike2.com
Re: pf set prio
* Andy a...@brandwatch.com [2013-09-10 11:38]: PS; Thanks for your great work Henning (and others of course). Hoping and keeping fingers crossed the new subsystem will make it into 5.4 :) queueing? no, looks like 5.5 -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: pflow packets before state expires
* Matt Hamilton ma...@netsight.co.uk [2013-09-10 12:30]: sven falempin sven.falempin at gmail.com writes: [nonsense deleted] The problem is that (I believe) that the pflow packet is not generated until the state expires from pf. In the case of the scp transfer I saw that was not for several days. Meaning I had no accounting/reporting of this data transfer until it ended and the state expired. correct. At which point the entire data transferred during that state's life was counted as if it happened now. This I'd call a visualization bug; but that doesn't change too much here. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 03:22:16PM +, hru...@gmail.com wrote: I wrote to the list. If you have something to say about the thema, then please to the list. Your impolite mails are not welcome in my mailbox. Rodrigo. And your endless meanderings around the pointless questions you pose are not welcome on the list. They certainly have NOTHING to do with OpenBSD. Ken Jan Stary h...@stare.cz wrote: On Sep 17 13:21:04, hru...@gmail.com wrote: Raimo Niskanen raimo+open...@erix.ericsson.se wrote: When you have two different real world contents the collision probability is just that; 2^-160 for SHA-1. It is when you deliberately craft a second content to match a known hash value there may be weaknesses in cryptographic hash functions, but this is not what rsync nor Git does, as Marc Espie pointed out in this thread. You have strings A and B, and you know only that hash(A)=hash(B): what is the probability that A=B? 2^-160? No. The probability that A!= B is 2^-160. However, this is irrelevant to the problem you are describing. Please don't enbarass yourself any further and take this silly issue somewhere else; preferably to your English teacher.
Re: cvsync, rsync
On Tue, Sep 17, 2013 at 06:18:48PM +, hru...@gmail.com wrote: Kenneth R Westerback kwesterb...@rogers.com wrote: And your endless meanderings around the pointless questions you pose are not welcome on the list. They certainly have NOTHING to do with OpenBSD. What you say in the last sentence is exactly what I hope. One of my questions was: This is a conjecture. Do you have a proof that the probability is so small? For me it is difficult to accept it. Is this conjecture used elsewhere? Rodrigo. Wow. Missing the point again. Please go away. Bother some non-OpenBSD list. As with others I am torn between recommending an english-as-a-second language list, or a math-for-idiots list. OpenBSD lists provide neither service. In any case. PLEASE GO AWAY. Ken
Re: This 48 core box...
On Tue 17 Sep 2013 18:09:15 BST, Michael Chen wrote: I'm considering bidding on this 48-core box: http://www.ebay.com/itm/Supermicro-A-Server-1042G-TF-1U-H8QG6-4-CPUS-48-cores-2-2Ghz-128GB-RAM-/151119828428?pt=COMP_EN_Servershash=item232f7195cc Does anyone have experience with it and can I use all the cores? Thanks! We use loads of Supermicro from Transtec and they work great. This is second hand though..
Re: This 48 core box...
On 17/09/13 2:12 PM, Nick Holland wrote: On 09/17/2013 01:41 PM, Andy wrote: On Tue 17 Sep 2013 18:09:15 BST, Michael Chen wrote: I'm considering bidding on this 48-core box: http://www.ebay.com/itm/Supermicro-A-Server-1042G-TF-1U-H8QG6-4-CPUS-48-cores-2-2Ghz-128GB-RAM-/151119828428?pt=COMP_EN_Servershash=item232f7195cc Does anyone have experience with it and can I use all the cores? Thanks! We use loads of Supermicro from Transtec and they work great. This is second hand though.. never used one of those machines, but I did play with a mighty machine recently. 1.5TB RAM, 4x8 HT'd cores (that's 64 sorta-cores...). Unfortunately, it seemed that only 512G of RAM was usable, more than that caused it to panic early in the boot process. So, I used boot(8) to restrict memory that the kernel saw. CVSROOT:/cvs Module name:src Changes by: a...@cvs.openbsd.org2004/07/19 09:09:06 Modified files: sys/arch/amd64/amd64: cpu.c machdep.c mptramp.S pmap.c sys/arch/amd64/include: pmap.h Log message: Implement __HAVE_PMAP_DIRECT on amd64 using large pages. At this moment it's limited to 512GB (one L4 page table entry) physical memory. Only used carefully at this moment, but more improvements are in the pipeline. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
tftpd Receives incomplete incoming transfers over a firewall
Hi, I'm trying to do some configuration backups from a piece of equipment over tftp (only option for this equipment) to a new-ish OBSD 5.3 file server running tftpd. Historically, this equipment has done its backups to a tftpd server running on OpenBSD 4.4 and its been working fine for several years. But as it's rather old we're switching over to the 5.3 server. The device and the servers (both old and new) reside on separate rfc 1918 networks (equip - lets say 10.1.0.60, servers - 10.5.0.[13 5]) connected with an OpenBSD firewall/router. However the 5.3 box doesn't seem to allow for complete transfers over the firewall. Only about 10-30K of the ~50K transfer completes. The equipment reports TFTP Error: Server Timeout. Running tftpd manaully with #tftpd -c -d -v /tftproot/ prints the following: tftpd: 10.1.0.60: write request for 'mybackup.cfg' tftpd: tftp_wrq recv: Connection refused Running tcpdump while the transfer is happening shows the following: nas1 #tcpdump -i em1 net 10.1.0.60 tcpdump: listening on em1, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 12:12:02.790735 10.1.0.60.2164 10.5.0.13.tftp: 27 WRQ mybackup.cfg 12:12:02.828113 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:02.852699 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:02.852757 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:02.952641 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:02.952677 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:03.059579 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:03.059614 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:03.072072 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:03.072106 10.5.0.13.7048 10.1.0.60.2164: udp 4 [.. .] 12:12:11.048977 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:11.049010 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:11.148920 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:11.148954 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:11.276346 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:11.276380 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:15.293532 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:19.311719 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:23.329904 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:27.348589 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:31.366275 10.1.0.60.2164 10.5.0.13.7048: udp 516 12:12:36.375321 10.5.0.13.7048 10.1.0.60.2164: udp 4 12:12:36.384384 10.1.0.60 10.5.0.13: icmp: 10.1.0.60 udp port 2164 unreachable On the old OBSD 4.4 file server the tcpdump of the successful transfer looks like this: filestore # tcpdump -i em1 net 10.1.0.60 tcpdump: listening on em1, link-type EN10MB 12:32:47.946560 10.1.0.60.2165 10.5.0.5.tftp: 27 WRQ ta4303-1.bend1.cfg 12:32:47.956856 10.5.0.5.10436 10.1.0.60.2165: udp 4 12:32:48.026514 10.1.0.60.2165 10.5.0.5.10436: udp 516 12:32:48.026562 10.5.0.5.10436 10.1.0.60.2165: udp 4 12:32:48.126455 10.1.0.60.2165 10.5.0.5.10436: udp 516 12:32:48.126487 10.5.0.5.10436 10.1.0.60.2165: udp 4 [.. .] 12:33:00.820607 10.1.0.60.2165 10.5.0.5.10436: udp 516 12:33:00.820633 10.5.0.5.10436 10.1.0.60.2165: udp 4 12:33:00.920549 10.1.0.60.2165 10.5.0.5.10436: udp 516 12:33:00.920575 10.5.0.5.10436 10.1.0.60.2165: udp 4 12:33:01.020491 10.1.0.60.2165 10.5.0.5.10436: udp 420 12:33:01.020549 10.5.0.5.10436 10.1.0.60.2165: udp 4 12:33:22.597501 10.1.0.60 10.5.0.5: icmp: 10.1.0.60 udp port 2165 unreachable Attempting a tftp transfer from my linux workstation (within the 10.5.0.0/24 net) to the 5.3 box works fine. Doing a tftp transfer over the firewall from the equipment to my workstation with atftpd running, works fine. For giggles, I loaded up the 9/14 snapshot of OpenBSD 5.4 in a virtual machine, tested, and got the same result as with 5.3. Should I be taking a closer look at the firewall (seems unlikely as the transfers work on the old box and my workstation) or are the other debugging steps I should be looking at? Thanks! -- Joe Kowalski
Re: Feedback about Desktop Environments
On 17 September 2013 20:37, Jes jjje...@gmail.com wrote: but if you want you can mount them in /etc/fstab. Simply read the documentation about permissions and syntax. It's very easy. For NFS the best way is mount them in /etc/fstab too. /Why/ is it the best way, though? Unlike automounters, static fstab entries don't address the problem of network filesystems being unreachable during boot. They will eventually time out and fail, requiring manual intervention. Fine if you have only a small group of systems... Failures may also rather substantially lengthen the boot process. Perhaps there are nasty side-effects of using automounters, but I've never encountered any. If there are I'd love to hear about them! John
