Re: Old cd57.iso in snapshots for i386
This issue of having a cd57.iso, with an ancient bsd.rd from Jan 12, is still not resolved. The latest i386 snapshot still has a cd57.iso which has not been updated for about 6 weeks. From ftp.openbsd.org : 47367 Feb 22 03:30 INSTALL.i386 1725 Feb 23 02:26 SHA256 1888 Feb 23 02:26 SHA256.sig 52892964 Feb 22 03:24 base57.tgz 10596435 Feb 22 03:24 bsd 10628609 Feb 22 03:24 bsd.mp 6966469 Feb 22 03:30 bsd.rd 7081984 Jan 12 00:28 cd57.iso When booted with this cd57.iso the installer shows: OpenBSD 5.7-beta (RAMDISK_CD) #622: Mon Jan 12 00:24:58 MST 2015 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD The install proceeds without further issues. From the first boot: OpenBSD 5.7-beta (GENERIC) #718: Sun Feb 22 03:18:56 MST 2015 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC When I reboot this freshly installed system and select its ./bsd.rd to reinstall: OpenBSD 5.7-beta (RAMDISK_CD) #695: Sun Feb 22 03:29:08 MST 2015 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD Is todd@ building these snapshots? On Mon, Feb 16, 2015 at 6:02 AM, Adriaan misc.adri...@gmail.com wrote: Somehow an old cd57.iso file is listed in the latest snapshot(s) for i386. The following is from a rsync with the Dutch nluug.org mirror/ $ ls -l /home/www/snapshots/i386 total 438508 -rw-r--r-- 1 root wheel 47367 Feb 13 20:31 INSTALL.i386 -rw-r--r-- 1 root wheel 1725 Feb 13 20:39 SHA256 -rw-r--r-- 1 root wheel 1888 Feb 13 20:39 SHA256.sig -rw-r--r-- 1 root wheel 52880665 Feb 13 20:26 base57.tgz -rwxr-xr-x 1 root wheel 10596320 Feb 13 20:25 bsd -rwxr-xr-x 1 root wheel 10628494 Feb 13 20:25 bsd.mp -rwxr-xr-x 1 root wheel 6966477 Feb 13 20:31 bsd.rd -rw-r--r-- 1 root wheel 7081984 Jan 12 08:28 cd57.iso ^ -rw-r--r-- 1 root wheel 46082227 Feb 13 20:26 comp57.tgz -rw-r--r-- 1 root wheel 1474560 Feb 13 20:31 floppy57.fs -rw-r--r-- 1 root wheel 1489 Feb 13 20:39 index.txt -rw-r--r-- 1 root wheel 8983090 Feb 13 20:26 man57.tgz -r-xr-xr-x 1 root wheel 81076 Feb 13 20:14 pxeboot -rw-r--r-- 1 root wheel 15287238 Feb 13 20:11 xbase57.tgz -rw-r--r-- 1 root wheel 39929920 Feb 13 20:12 xfont57.tgz -rw-r--r-- 1 root wheel 19779738 Feb 13 20:12 xserv57.tgz -rw-r--r-- 1 root wheel 4519829 Feb 13 20:12 xshare57.tgz On ftp.openbsd.org/pub/OpenBSD/snapshots/i386/ the time for cd57.iso 00:28 hr This mounted cd57.iso using a vnode disk shows: /mnt/5.7/i386 $ ls -l total 13695 -r--r--r-- 1 root wheel 180 Jan 12 08:28 TRANS.TBL -rwxr--r-- 1 root wsrc 2048 Jan 12 08:28 boot.catalog -rwxr-xr-x 1 root wsrc 6935407 Jan 12 08:28 bsd.rd -rw-r--r-- 1 root wsrc 72852 Jan 12 08:28 cdboot -rw-r--r-- 1 root wsrc 2048 Jan 12 08:28 cdbr The checksum of this bsd.rd does not match with the one in SHA256: $ sha256 /mnt/5.7/i386/bsd.rd SHA256 (/mnt/5.7/i386/bsd.rd) = e826881e54c8b966321e68ba9c7d3f280fbc041d4c94f528eb62e5799cb8130 /home/www/snapshots/i386 $ grep cd57 SHA256 SHA256 (cd57.iso) = feff2dd5d5ab2f4eb23d79b61f5ab261f1d31be51d2247ef1dc416ee6f5ef437 Adriaan
Re: touchpad slight regression (snap: 20141121-20150217)
Hi Patrick, hi Henrik,
this is good news, thanks for your help. I hope a fix will be
available soon, be it in this form or another (it might be better
to implement it in wsconscomm).
@Patrick: For a PS/2 mouse the Z value describes the rotation
of the scrolling wheel; for a touchpad that operates in native
mode - which means it isn't emulating a mouse - Z represents the
finger pressure. The W value is a bit weird: Synaptics touchpads
encode a hint to the width of a contact in W, which ranges from 0
to 15: 4 and 5 are for normal contacts, the values from 6 to 15
represent wide - and usually accidental - touches, e.g., with a
palm. The other values don't indicate finger width: 2 and 3 have
special technical meanings, and 0 and 1 indicate a two-finger touch
or a three-finger touch. However, W == 0 can also mean that a touch
has ended, because the hardware sends a packet with all four
coordinates set to zero in this case, and this is what the patches
are about.
On 02/27/2015 08:40 PM, patrick keshishian wrote:
Hi,
On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote:
On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
...
It might be that the following patch to wsmouse.c solves the problem
with the new version of wsconscomm. Tests would be welcome (I could
only verify that the patch does no harm to other touchpad types, i.e.,
Elantech-v4 and Alps Glidepoint).
[...]
Sorry, the change was in the wrong place and would only do a half of
the work. It should look like:
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 02:50:06 -
@@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
}
}
+ if (sc-sc_z == 0)
+ sc-sc_w = INVALID_W;
+
mb = sc-sc_mb;
while ((d = mb ^ ub) != 0) {
/*
I can confirm this change alone causes no adverse, observable
change on my x120e's touchpad.
With -r1.11 of xenocara/driver/xf86-input-synaptics/wsconscomm.c,
in combination with above patch, I no longer seem to notice the
issue for which this message thread was originated.
However, I would appreciate it if someone could enlighten me
as to what the Z and W axis refer.
Thanks,
--patrick
Re: pf to read protocol information from /etc/services ?
On Feb 27, 2015, at 7:08 PM, Maxim Khitrov m...@mxcrypt.com wrote: On Fri, Feb 27, 2015 at 3:40 PM, Research resea...@nativemethods.com wrote: UDP is meaningless in the context of HTTP. Well, actually... https://en.wikipedia.org/wiki/QUIC Not really standard, but still. I now allow UDP on ports 80 and 443 to make Google Chrome happy. Thank you for posting that! I see in the Wikipedia article that this was implemented in 2013, so I am a little behind the curve. Good to learn new things.
Re: Old cd57.iso in snapshots for i386
Snapshots built after the 23rd should include it: http://marc.info/?l=openbsd-cvsm=142468403609853w=2 On Sat, Feb 28, 2015 at 02:49:59AM +0100, Adriaan wrote: This issue of having a cd57.iso, with an ancient bsd.rd from Jan 12, is still not resolved. The latest i386 snapshot still has a cd57.iso which has not been updated for about 6 weeks. From ftp.openbsd.org : 47367 Feb 22 03:30 INSTALL.i386 1725 Feb 23 02:26 SHA256 1888 Feb 23 02:26 SHA256.sig 52892964 Feb 22 03:24 base57.tgz 10596435 Feb 22 03:24 bsd 10628609 Feb 22 03:24 bsd.mp 6966469 Feb 22 03:30 bsd.rd 7081984 Jan 12 00:28 cd57.iso When booted with this cd57.iso the installer shows: OpenBSD 5.7-beta (RAMDISK_CD) #622: Mon Jan 12 00:24:58 MST 2015 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD The install proceeds without further issues. From the first boot: OpenBSD 5.7-beta (GENERIC) #718: Sun Feb 22 03:18:56 MST 2015 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC When I reboot this freshly installed system and select its ./bsd.rd to reinstall: OpenBSD 5.7-beta (RAMDISK_CD) #695: Sun Feb 22 03:29:08 MST 2015 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD Is todd@ building these snapshots? On Mon, Feb 16, 2015 at 6:02 AM, Adriaan misc.adri...@gmail.com wrote: Somehow an old cd57.iso file is listed in the latest snapshot(s) for i386. The following is from a rsync with the Dutch nluug.org mirror/ $ ls -l /home/www/snapshots/i386 total 438508 -rw-r--r-- 1 root wheel 47367 Feb 13 20:31 INSTALL.i386 -rw-r--r-- 1 root wheel 1725 Feb 13 20:39 SHA256 -rw-r--r-- 1 root wheel 1888 Feb 13 20:39 SHA256.sig -rw-r--r-- 1 root wheel 52880665 Feb 13 20:26 base57.tgz -rwxr-xr-x 1 root wheel 10596320 Feb 13 20:25 bsd -rwxr-xr-x 1 root wheel 10628494 Feb 13 20:25 bsd.mp -rwxr-xr-x 1 root wheel 6966477 Feb 13 20:31 bsd.rd -rw-r--r-- 1 root wheel 7081984 Jan 12 08:28 cd57.iso ^ -rw-r--r-- 1 root wheel 46082227 Feb 13 20:26 comp57.tgz -rw-r--r-- 1 root wheel 1474560 Feb 13 20:31 floppy57.fs -rw-r--r-- 1 root wheel 1489 Feb 13 20:39 index.txt -rw-r--r-- 1 root wheel 8983090 Feb 13 20:26 man57.tgz -r-xr-xr-x 1 root wheel 81076 Feb 13 20:14 pxeboot -rw-r--r-- 1 root wheel 15287238 Feb 13 20:11 xbase57.tgz -rw-r--r-- 1 root wheel 39929920 Feb 13 20:12 xfont57.tgz -rw-r--r-- 1 root wheel 19779738 Feb 13 20:12 xserv57.tgz -rw-r--r-- 1 root wheel 4519829 Feb 13 20:12 xshare57.tgz On ftp.openbsd.org/pub/OpenBSD/snapshots/i386/ the time for cd57.iso 00:28 hr This mounted cd57.iso using a vnode disk shows: /mnt/5.7/i386 $ ls -l total 13695 -r--r--r-- 1 root wheel 180 Jan 12 08:28 TRANS.TBL -rwxr--r-- 1 root wsrc 2048 Jan 12 08:28 boot.catalog -rwxr-xr-x 1 root wsrc 6935407 Jan 12 08:28 bsd.rd -rw-r--r-- 1 root wsrc 72852 Jan 12 08:28 cdboot -rw-r--r-- 1 root wsrc 2048 Jan 12 08:28 cdbr The checksum of this bsd.rd does not match with the one in SHA256: $ sha256 /mnt/5.7/i386/bsd.rd SHA256 (/mnt/5.7/i386/bsd.rd) = e826881e54c8b966321e68ba9c7d3f280fbc041d4c94f528eb62e5799cb8130 /home/www/snapshots/i386 $ grep cd57 SHA256 SHA256 (cd57.iso) = feff2dd5d5ab2f4eb23d79b61f5ab261f1d31be51d2247ef1dc416ee6f5ef437 Adriaan
Re: pf to read protocol information from /etc/services ?
On 2015-02-27 Fri 10:30 AM |, Harald Dunkel wrote:
On Fri, 27 Feb 2015 09:22:21 +
Lo??c Blot loic.b...@unix-experience.fr wrote:
in the first example you don't specify proto tcp.
Thats the point. /etc/services says
telnet 23/tcp
so pf could figure this out on its own.
$ awk '/^domain/ { print $2 }' /etc/services
53/tcp
53/udp
Now what? Both? Either? First? Last? Random?
--
Nothing is better than Sex.
Masturbation is better than nothing.
Therefore, Masturbation is better than Sex.
Re: usb ehci errors in 5.6-stable
On Fri, Feb 27, 2015 at 11:42:32AM -0430, Halim Srama wrote: With the previous -current athn0 used to trigger the ehci_idone. It's a TP-LINK TL-WN722N. Thanks, those are easy to find and cheap. I'll pick one up ASAP.
Re: man pages ending in .1x from ports
Hi Patrick, patrick keshishian wrote on Wed, Feb 25, 2015 at 06:39:58PM -0800: Just noticed this, I imagine this may be known already, No, this glitch wasn't known, thanks for reporting. but here it is just in case it isn't. Don't assume mandoc(1) problems are known unless listed on http://mdocml.bsd.lv/cgi-bin/cvsweb/TODO?rev=HEAD . Duplicate reports are much better than missing ones. $ man xsel man: /usr/local/man/man1/xsel.1: ERROR: No such file or directory Fixed in -current, see my two recent commits. [...] This used to work fine with 20141121 snapshot, last one before 20150217 upgrade. The last weeks right before lock are a perfect time for testing and reporting regressions, so thank you, Patrick, for updating and testing. If anybody else didn't test their favourite base system software on -current yet, now is the last chance before the lock for 5.7. If you find regressions next week, it may already be too late. In ports, we are already in a stage where only show-stoppers can be fixed before release, but show stoppers still *can* be fixed, so please help find them *now*. Yours, Ingo
Re: usb ehci errors in 5.6-stable
On Fri, Feb 27, 2015 at 05:25:49PM +0100, Stefan Sperling wrote: On Fri, Feb 27, 2015 at 11:42:32AM -0430, Halim Srama wrote: With the previous -current athn0 used to trigger the ehci_idone. It's a TP-LINK TL-WN722N. Thanks, those are easy to find and cheap. I'll pick one up ASAP. As I said, I have this problem, and I use the same card. -- Regards Henrique Lengler
Re: usb ehci errors in 5.6-stable
Thank you for your work on this. If you need any more information or testing I'll be happy to do it. On Feb 27, 2015 11:55 AM, Stefan Sperling s...@stsp.name wrote: On Fri, Feb 27, 2015 at 11:42:32AM -0430, Halim Srama wrote: With the previous -current athn0 used to trigger the ehci_idone. It's a TP-LINK TL-WN722N. Thanks, those are easy to find and cheap. I'll pick one up ASAP.
.c and .h files in OpenBSD - cvsweb src/bin/...
Hello, I did in the past some small C programms using self defined header .h files. Usually, I was using a .h file for #define and function prototypes together with a same name but .c extension file where I was putting my functions' bodies (inline implemention). The main program included the previous .h file and that was it. Of course, the standard headers were included, I don't remember in which of the two .c files, but I did include them only once. As some folks recommand on the list, I was looking on cvsweb for code, starting with bin utilities. I was confused about splitting source code in .c and .h files. For src/bin/cat, there is one .c file, no .h file, and the functions are in .c file, prototypes and bodies; For src/bin/dd, there are multiple .c and .h files. Of course, dd.c has the main() function, the rest of the .c files are containing functions used in dd.c. The only hint those files are related is in the Makefile. I read in style(9) about splitting code in files, and I did some google search. I was amased to see that the choice of splitting code in files is very wide, some talking even about #include .c files (not a good practice). From the most advanced ones, is there a paper or a link where I can find details about OpenBSD style of splitting C code in .c and .h files? I mean, where to put what? OR maybe some rules of thumb. If one is using multiple .c files with no associated .h headers, is Makefile (and compiler's options) the only way to relate them? I'm sorry if it is a little bit offtopic and I thank you.
dump and duid
This is current/amd64. After cleaning my machine I reconnected two of my disks in reverse; what was sd0 is sd1 now, and vice versa. I do nightly dumps of the filesystems, starting with level 0 on early Monday morning, continuing with incremental 1, 2 etc through the week. Usually this means that the Monday dump -0 is big, and the subsequent incrementals are relatively small: -rw--- 1 hans wheel 299G Feb 23 03:26 dump.biblio.0 -rw--- 1 hans wheel 19.7M Feb 24 01:32 dump.biblio.1 -rw--- 1 hans wheel 1.4G Feb 25 01:32 dump.biblio.2 -rw--- 1 hans wheel 674M Feb 26 01:32 dump.biblio.3 -rw--- 1 hans wheel 240G Feb 27 02:55 dump.biblio.4 -rw--- 1 hans wheel 16.7G Feb 23 01:40 dump.home.0 -rw--- 1 hans wheel 326M Feb 24 01:32 dump.home.1 -rw--- 1 hans wheel 54.5M Feb 25 01:32 dump.home.2 -rw--- 1 hans wheel 59.4M Feb 26 01:32 dump.home.3 -rw--- 1 hans wheel 52.3M Feb 27 01:32 dump.home.4 -rw--- 1 hans wheel 93.9M Feb 23 01:30 dump.root.0 -rw--- 1 hans wheel 100K Feb 24 01:30 dump.root.1 -rw--- 1 hans wheel 80.0K Feb 25 01:30 dump.root.2 -rw--- 1 hans wheel 80.0K Feb 26 01:30 dump.root.3 -rw--- 1 hans wheel 7.4M Feb 27 01:30 dump.root.4 [...] Now, on the night after I interchanged the disks, the dump -4 of sd1a (/biblio) is huge again; apparently, dump -4 is dumping everything again. Is this simply because /etc/dumpdates deals with device names, as opposed to duids? Jan
Re: touchpad slight regression (snap: 20141121-20150217)
That does seem to fix it in my case.
Re: pf to read protocol information from /etc/services ?
On Fri, 27 Feb 2015 12:46:19 +
skin...@britvault.co.uk (Craig Skinner) wrote:
$ awk '/^domain/ { print $2 }' /etc/services
53/tcp
53/udp
Now what? Both? Either? First? Last? Random?
Both.
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: pf add not working
On Fri, 27 Feb 2015 11:46:33 + (UTC) Stuart Henderson s...@spacehopper.org wrote: On 2015-02-26, D'Arcy J.M. Cain da...@vex.net wrote: On Thu, 26 Feb 2015 21:49:15 +0100 Otto Moerbeek o...@drijf.net wrote: What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. Well, from what you describe it is likely there is a rule creating state. It could very well be that one of the rules you left out is the culprit. OK, here is everything: http://www.vex.net/~darcy/pf.conf Use pfctl -ss -v to identify the rule number that created state. Use pfctl -sr -R number to display how that rule was added to the kernel. I have done that and I am pretty sure of which rules are being called. This morning I dumped the pf log and extracted info on an attack. I have added pfctl -k $ip to my script when I add an IP to the AUTOBLOCK table that I created. It did block in a timely fashion this morning suggesting that it is keeping state even though I told it not to. Lines trimmed to avoid email wraparound but the rest of the line is minor variations of 192.186.133.60.5071 98.158.139.74.5060: SIP, length: 777 00:00:51.568629 rule 14/0(match): pass in on bge0:... 00:01:38.128375 rule 14/0(match): pass in on bge0:... 00:03:09.457203 rule 14/0(match): pass in on bge0:... 00:00:01.571262 rule 14/0(match): pass in on bge0:... 00:00:09.944745 rule 14/0(match): pass in on bge0:... 00:00:03.561522 rule 14/0(match): pass in on bge0:... 00:00:07.233853 rule 14/0(match): pass in on bge0:... 00:00:09.424476 rule 14/0(match): pass in on bge0:... 00:00:01.180593 rule 14/0(match): pass in on bge0:... 00:02:19.325087 rule 9/0(match): block in on bge0:... Here are the two rules mentioned: @9 block drop in log quick on bge0 from AUTOBLOCK:32 to any @14 pass in log on bge0 proto udp from any to any port = sip no state Past experience suggests that if I had not added pfctl -k $ip that the attack would have continued for a much longer time. Few of us here know what level of PF that NetBSD are using and how it interprets rulesets. There doesn't seem to be a version flag. I couldn't find anything relevant with strings. Additionally: why don't you want to create state? A state check is very much faster than a rule traversal, that's something you probably want on at least the voip media. I didn't want to create state on incoming UDP specifically so that I could block these attacks. Perhaps I don't need that any more since I manually kill the state now but it still seems like the option should work as advertised. Additionally #2: dropping packets often doesn't stop SIP floods. https://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/ might be interesting. Not sure that it applies but it's an interesting read anyway. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: mbsync crashes with segfault on 5.7-current
On Fri, Feb 27, 2015 at 3:09 PM, Jan Vlach ja...@volny.cz wrote: This GDB was configured as i386-unknown-openbsd5.7...(no debugging symbols found) Core was generated by `mbsync'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found) Please rebuild mbsync with: $ cd ports/mail/isync ; DEBUG=-ggdb -O0 INSTALL_STRIP= make clean repackage reinstall And post a better backtrace. Ciao! David
mbsync crashes with segfault on 5.7-current
Good afternoon misc@ I can't sync imap folders with isync/mbsync 1.0.6 on 5.7-current on i386, crashes with segfault. It's reproducible on last published snapshot (Feb 22 10:10 @ ftp.eu.openbsd.org) and also on current built from CVS. I've tried using binary package for isync and also building from ports-current, it's the same. Same config file works fine on 5.6-stable running on amd64 (even if I move the output directory away to force full re-sync) If further information is necessary, I'll be more than happy to provide it. Thank you and have a nice day. Jan Vlach # COMMAND OUTPUT $ mbsync -a Reading configuration file /home/janus/.mbsyncrc Resolving imap.volny.cz... ok Connecting to 46.255.224.78:143... ok Connection is now encrypted Logging in... Channel sync-volny.cz Selecting slave INBOX... 0 messages, 0 recent Selecting master INBOX... 63 messages, 0 recent Synchronizing Pulling new messages...Segmentation fault (core dumped) # GDB $ gdb /usr/local/bin/mbsync mbsync.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd5.7...(no debugging symbols found) Core was generated by `mbsync'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found) Loaded symbols for /usr/local/bin/mbsync Reading symbols from /usr/local/lib/libdb.so.5.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdb.so.5.0 Reading symbols from /usr/lib/libssl.so.32.0...done. Loaded symbols for /usr/lib/libssl.so.32.0 Reading symbols from /usr/lib/libcrypto.so.32.0...done. Loaded symbols for /usr/lib/libcrypto.so.32.0 Reading symbols from /usr/lib/libc.so.78.1...done. Loaded symbols for /usr/lib/libc.so.78.1 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 strlen (str=0x1 Address 0x1 out of bounds) at /usr/src/lib/libc/string/strlen.c:39 39 for (s = str; *s; ++s) (gdb) backtrace #0 strlen (str=0x1 Address 0x1 out of bounds) at /usr/src/lib/libc/string/strlen.c:39 #1 0x0f8f2e03 in __vfprintf (fp=0xcfbccf1c, fmt0=0x37056931 %ld.%d_%d.%s, ap=0xcfbccfdc �\226\0057) at /usr/src/lib/libc/stdio/vfprintf.c:879 #2 0x0f8eff45 in vsnprintf (str=0xcfbcd210 1425043955.0_24340�z\bӼҼ005\027lҼϤҼ, n=128, fmt=0x37056931 %ld.%d_%d.%s, ap=0xcfbccfcc ) at /usr/src/lib/libc/stdio/vsnprintf.c:61 #3 0x1705cb09 in ?? () from /usr/local/bin/mbsync #4 0xcfbcd210 in ?? () #5 0x0080 in ?? () #6 0x37056931 in ?? () from /usr/local/bin/mbsync #7 0xcfbccfcc in ?? () #8 0x54f071f3 in ?? () #9 0x in ?? () # DMESG snapshot OpenBSD 5.7-beta (GENERIC) #718: Sun Feb 22 03:18:56 MST 2015 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(R) M CPU 430 @ 1.73GHz (GenuineIntel 686-class) 1.73 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,SSE3,MWAIT,TM2,xTPR,PDCM,PERF real mem = 3212132352 (3063MB) avail mem = 3147300864 (3001MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 08/27/08, BIOS32 rev. 0 @ 0xf, SMBIOS rev. 2.4 @ 0xf3a78 (23 entries) bios0: vendor Hewlett-Packard version 68YGU Ver. F.0E date 08/27/2008 bios0: Hewlett-Packard HP Compaq nx7400 (EY587ES#AKB) acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET APIC MCFG TCPA SSDT SSDT SSDT SSDT acpi0: wakeup devices C098(S5) C225(S5) C0FA(S3) C0FB(S3) C0FC(S3) C0FD(S3) C114(S5) C22F(S5) C11A(S5) C230(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 2 (C098) acpiprt1 at acpi0: bus 8 (C104) acpiprt2 at acpi0: bus 16 (C114) acpiprt3 at acpi0: bus 32 (C11A) acpiprt4 at acpi0: bus 0 (C002) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1 acpipwrres0 at acpi0: C1F3, resource for C1EE acpipwrres1 at acpi0: C200, resource for C1F4 acpipwrres2 at acpi0: C21D, resource for C21B acpipwrres3 at acpi0: C226, resource for C123 acpipwrres4 at acpi0: C320, resource for C324 acpipwrres5 at acpi0: C321, resource for C325 acpipwrres6 at acpi0: C322, resource for C326 acpipwrres7 at acpi0: C323, resource for C327 acpitz0 at acpi0: critical temperature is 256 degC acpitz1 at acpi0: critical temperature is 110
Re: usb ehci errors in 5.6-stable
On Fri, Feb 27, 2015 at 11:04:32AM -0430, Naim, Halim. wrote: I have updated to the latest snapshot. Applied the patch (strange thing, marc.info wouldn't open unless I was using tor). And recompiled the kernel according the FAQ. I haven't seen any echi messages for now. But after I do: # ifconfig athn0 down If I try: # ifconfig athn0 up or # sh /etc/netstart athn0 It hangs without doing anything. After that, usbdevs also hangs. No message is printed when this happens. After that point. No other usb devices works. Attaching them prints nothing. Does this also happen on -current without the patch?
Re: usb ehci errors in 5.6-stable
On Fri, Feb 27, 2015 at 11:27:56AM -0430, Halim Srama wrote: Yes. booted with /obsd and it's the same. This doesn't happen with an urtwn0 USB dongle. So your issue appears to be related to athn rather than the ehci_idone fix patch. Have any other athn users seen this? What's the name and model number on your athn device's case? (Perhaps I can find one and try to reproduce the issue.)
Re: usb ehci errors in 5.6-stable
With the previous -current athn0 used to trigger the ehci_idone. It's a TP-LINK TL-WN722N. On Feb 27, 2015 11:38 AM, Stefan Sperling s...@stsp.name wrote: On Fri, Feb 27, 2015 at 11:27:56AM -0430, Halim Srama wrote: Yes. booted with /obsd and it's the same. This doesn't happen with an urtwn0 USB dongle. So your issue appears to be related to athn rather than the ehci_idone fix patch. Have any other athn users seen this? What's the name and model number on your athn device's case? (Perhaps I can find one and try to reproduce the issue.)
Re: usb ehci errors in 5.6-stable
Stefan Sperling s...@stsp.name writes: On Wed, Feb 25, 2015 at 09:08:56PM -0300, Henrique Lengler wrote: On Tue, Feb 24, 2015 at 12:23:54PM +0100, Stefan Sperling wrote: On Tue, Feb 24, 2015 at 02:30:06PM +0400, Evgeny Zhavoronkov wrote: Ok. So I tried -current and situation is the same. I can reproduce the total crash (laptop reboot) by attach/detach athn usb wifi or playing with usb devs somehow. Hi, I have an athn0 card and I have this problem. If my internet drops, sometimes I can't reset the stuff, in dmesg, I stay receiving a lot of ehci errors. -- Regards Henrique Lengler Everyone, please upgrade to -current and test the diff mpi posted here: http://marc.info/?l=openbsd-techm=142491190521130w=2 I have updated to the latest snapshot. Applied the patch (strange thing, marc.info wouldn't open unless I was using tor). And recompiled the kernel according the FAQ. I haven't seen any echi messages for now. But after I do: # ifconfig athn0 down If I try: # ifconfig athn0 up or # sh /etc/netstart athn0 It hangs without doing anything. After that, usbdevs also hangs. No message is printed when this happens. After that point. No other usb devices works. Attaching them prints nothing. dmesg and usbdevs: OpenBSD 5.7-beta (GENERIC.MP) #1: Fri Feb 27 09:19:15 VET 2015 root@openbsd:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Pentium(R) D CPU 3.00GHz (GenuineIntel 686-class) 2.93 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,PDCM,LAHF real mem = 2146189312 (2046MB) avail mem = 2098733056 (2001MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 09/05/06, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.4 @ 0xfd060 (22 entries) bios0: vendor American Megatrends Inc. version P2.70 date 09/05/2006 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC OEMB acpi0: wakeup devices P0P4(S4) MC97(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) EUSB(S4) PS2K(S4) PS2M(S4) UAR1(S4) GBEN(S4) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 194MHz cpu0: mwait min=64, max=64 cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Pentium(R) D CPU 3.00GHz (GenuineIntel 686-class) 2.93 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,PDCM,LAHF ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (P0P4) acpicpu0 at acpi0 acpi0: SSDT checksum error: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB bios0: ROM list: 0xc/0xee00 cpu0: Enhanced SpeedStep 2924 MHz: speeds: 3000, 3000, 3000, 3000, 3000, 3000, 3000, 3000, 3000, 2400 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82865G Host rev 0x02 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xe000, size 0x1000 ppb0 at pci0 dev 1 function 0 Intel 82865G AGP rev 0x02 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 vendor NVIDIA, unknown product 0x0222 rev 0xa1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 2 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 2 int 19 uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: apic 2 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: apic 2 int 16 ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xc2 pci2 at ppb1 bus 2 rl0 at pci2 dev 5 function 0 Realtek 8139 rev 0x10: apic 2 int 22, address 00:13:8f:d6:2b:03 rlphy0 at rl0 phy 0: RTL internal PHY ichpcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801EB/ER IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: Hitachi HCP725032GLAT80 wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors atapiscsi0 at pciide0 channel 0 drive 1 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: HL-DT-ST, DVDRAM GSA-4167B, DL11 ATAPI 5/cdrom removable wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) ichiic0 at pci0 dev 31 function 3 Intel 82801EB/ER
Re: usb ehci errors in 5.6-stable
Yes. booted with /obsd and it's the same. This doesn't happen with an urtwn0 USB dongle. On Feb 27, 2015 11:13 AM, Stefan Sperling s...@stsp.name wrote: On Fri, Feb 27, 2015 at 11:04:32AM -0430, Naim, Halim. wrote: I have updated to the latest snapshot. Applied the patch (strange thing, marc.info wouldn't open unless I was using tor). And recompiled the kernel according the FAQ. I haven't seen any echi messages for now. But after I do: # ifconfig athn0 down If I try: # ifconfig athn0 up or # sh /etc/netstart athn0 It hangs without doing anything. After that, usbdevs also hangs. No message is printed when this happens. After that point. No other usb devices works. Attaching them prints nothing. Does this also happen on -current without the patch?
Re: usb ehci errors in 5.6-stable
After a couple of hours without using the PC the dongle went of. and trying to restart the interface generates de same problems I reported earlier. On Feb 27, 2015 12:46 PM, Henrique Lengler henriquel...@opmbx.org wrote: On Fri, Feb 27, 2015 at 05:25:49PM +0100, Stefan Sperling wrote: On Fri, Feb 27, 2015 at 11:42:32AM -0430, Halim Srama wrote: With the previous -current athn0 used to trigger the ehci_idone. It's a TP-LINK TL-WN722N. Thanks, those are easy to find and cheap. I'll pick one up ASAP. As I said, I have this problem, and I use the same card. -- Regards Henrique Lengler
Re: touchpad slight regression (snap: 20141121-20150217)
Hi,
On 2/26/15, Ulf Brosziewski ulf.brosziew...@t-online.de wrote:
On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
...
It might be that the following patch to wsmouse.c solves the problem
with the new version of wsconscomm. Tests would be welcome (I could
only verify that the patch does no harm to other touchpad types, i.e.,
Elantech-v4 and Alps Glidepoint).
[...]
Sorry, the change was in the wrong place and would only do a half of
the work. It should look like:
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.26
diff -u -p -r1.26 wsmouse.c
--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
+++ wsmouse.c 27 Feb 2015 02:50:06 -
@@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
}
}
+ if (sc-sc_z == 0)
+ sc-sc_w = INVALID_W;
+
mb = sc-sc_mb;
while ((d = mb ^ ub) != 0) {
/*
I can confirm this change alone causes no adverse, observable
change on my x120e's touchpad.
With -r1.11 of xenocara/driver/xf86-input-synaptics/wsconscomm.c,
in combination with above patch, I no longer seem to notice the
issue for which this message thread was originated.
However, I would appreciate it if someone could enlighten me
as to what the Z and W axis refer.
Thanks,
--patrick
Re: Where is etc57.tgz? in snapshots/amd64/?
On 2/27/2015 12:41 PM, Henrique Lengler wrote: I wanna set a -current openbsd installation. The FAQ [1] for 5.6 say I need etc56.tgz, so my question is do I need a etc57.tgz to install a snapshot? Because I can't find this file in the servers. [1] http://www.openbsd.org/faq/faq4.html#FilesNeeded You're looking at the wrong FAQ (OpenBSD 5.6 Installation Guide). Since you're upgrading to 5.7, you want http://www.openbsd.org/faq/current.html
Where is etc57.tgz? in snapshots/amd64/?
Hi, I wanna set a -current openbsd installation. The FAQ [1] for 5.6 say I need etc56.tgz, so my question is do I need a etc57.tgz to install a snapshot? Because I can't find this file in the servers. [1] http://www.openbsd.org/faq/faq4.html#FilesNeeded -- Regards Henrique Lengler
Re: Where is etc57.tgz? in snapshots/amd64/?
Sometime after 5.6 release the etc packages went away and the files are part of base packages. On 2/27/2015 12:41 PM, Henrique Lengler wrote: I wanna set a -current openbsd installation. The FAQ [1] for 5.6 say I need etc56.tgz, so my question is do I need a etc57.tgz to install a snapshot? Because I can't find this file in the servers.
Re: Last snapshots won't install on VMWare ESXi or getting ether_output panic
Here is the panic got during Installing comp57.tgz vm_fault(0xd0852014, 0xd037c000, 0, 1) - e fatal page fault (6) in supervisor mode trap type 6 code 0 eip d037c370 cs 8 eflags 10246 cr2 dbaeffc cpl b0 panic : trap type 6, code=0, pc=d037c370 syncing disks... #== # Dmesg #== OpenBSD 5.7-beta (RAMDISK_CD) #695: Sun Feb 22 03:29:08 MST 2015 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Xedon(R) CPU E3-1220 V2 @ 3.10GHz (GenuineIntel 686-class) 3.10 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS, MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX, HV,LAHF,PERF,ITSC real mem = 3220697088 (3071MB) avail mem = 3160403968 (3013MB) mainbus0 at root bios0 at mainbus0: date 07/30/13, BIOS32 rev. 0 @ 0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version 6.00 date 07/30/2013 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET cpimadt0 at capi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 65MHz iopic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) bios0: ROM list : 0xc/0x8000 0x8000/0x1e00! 0xca000/0x1000 0xdc000/0x4000! 0xe/0x8000! pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 92443BX AGP rev 0x01 ppb0 at pci0 dev 1 function 0 Intel 92443BX AGP rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x08 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at atapiscsi0: 2 targets scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: NECVMWar, VMware IDE CDR10, 1.00 ATAPI 5/cdrom removable3 cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 Intel 82371AB Power rev 0x08 at pci0 dev 7 function 3 not configured VMware VMCI rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 VMware SVGA II rev 0x00 vga1: aperture needed wsdisplay0 at vga1 mux 1:console (80x25, vt100 emulation) mpi0 at pci0 dev 16 function 0 Symbios Logic 53c1030 rev 0x01: apic 1 int 17 mpi0: 0, firmware 1.3.41.32 scsibus1 at mpi0: 16 targets, initiator 7 scsibus1 at mpi0: 16 targets, initiator 7 mpi0: targer 0 Sync at 160 MHz width 16bit offset 127 GAS 1 DT 1 IU 1 ppb1 at pci0 dev 17 function 0 VMware PCI rev 0x02 pci2 at ppb1 bus2 em0 at pci2 dev 0 function 0 Intel 8254EM rev 0x01: apic 1 int 18, address 00:0c:29:c6:ba:6a ppb2 at pci0 dev 21 function 0 VMware PCIE rev 0x01 pci3 at ppb2 bus 3 ppb3 at pci0 dev 21 function 1 VMware PCIE rev 0x01 ppb4 at ppb3 bus 4 ppb4 at pci0 dev 21 function 2 VMware PCIE rev 0x01 ppb5 at ppb4 bus 5 ppb5 at pci0 dev 21 function 3 VMware PCIE rev 0x01 pci6 at ppb5 bus 6 ppb6 at pci0 dev 21 function 4 VMware PCIE rev 0x01 pci7 at ppb6 bus 7 ppb7 at pci0 dev 21 function 5 VMware PCIE rev 0x01 pci8 at ppb7 bus 8 ppb8 at pci0 dev 21 function 6 VMware PCIE rev 0x01 pci9 at ppb8 bus 9 ppb9 at pci0 dev 21 function 7 VMware PCIE rev 0x01 pci10 at ppb9 bus 10 ppb10 at pci0 dev 22 function 0 VMware PCIE rev 0x01 pci11 at ppb10 bus 11 ppb11 at pci0 dev 22 function 1 VMware PCIE rev 0x01 pci12 at ppb11 bus 12 ppb12 at pci0 dev 22 function 2 VMware PCIE rev 0x01 pci13 at ppb12 bus 13 ppb13 at pci0 dev 22 function 3 VMware PCIE rev 0x01 pci14 at ppb13 bus 14 ppb14 at pci0 dev 22 function 4 VMware PCIE rev 0x01 pci15 at ppb14 bus 15 ppb15 at pci0 dev 22 function 5 VMware PCIE rev 0x01 pci16 at ppb15 bus 16 ppb16 at pci0 dev 22 function 6 VMware PCIE rev 0x01 pci17 at ppb16 bus 17 ppb17 at pci0 dev 22 function 7 VMware PCIE rev 0x01 ... pci33 at ppb32 bus 33 ppb33 at pci0 dev 24 function 7 VMware PCIE rev 0x01 pci34 at ppb33 bus 34 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 softraid0 at root scsibus2 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b #== # VMX file : #== .encoding = UTF-8 config.version = 8 virtualHW.version = 8 nvram = test.nvram pciBridge0.present = TRUE svga.present = TRUE pciBridge4.present = TRUE pciBridge4.virtualDev = pcieRootPort pciBridge4.functions = 8 pciBridge5.present = TRUE pciBridge5.virtualDev = pcieRootPort pciBridge5.functions = 8 pciBridge6.present = TRUE pciBridge6.virtualDev = pcieRootPort pciBridge6.functions = 8 pciBridge7.present = TRUE pciBridge7.virtualDev = pcieRootPort
Re: pf to read protocol information from /etc/services ?
Hello, in the first example you don't specify proto tcp. Regards, Loïc Blot, UNIX Systems, Network and Security Engineer http://www.unix-experience.fr 27 février 2015 09:50 Harald Dunkel harald.dun...@aixigo.de a écrit: Hi folks, /etc/services provides protocol information as well, so I wonder if a pf line like pass in from any to (self) port telnet could be read as pass in proto tcp from any to (self) port 23 ? Currently (5.6 stable) there is an error message, e.g. /etc/pf_gate5.conf:351: port only applies to tcp/udp /etc/pf_gate5.conf:351: skipping rule due to errors /etc/pf_gate5.conf:351: rule expands to no valid combination I cannot follow the no valid combination. Just a suggestion, of course. Keep on your good work Harri
pf to read protocol information from /etc/services ?
Hi folks, /etc/services provides protocol information as well, so I wonder if a pf line like pass in from any to (self) port telnet could be read as pass in proto tcp from any to (self) port 23 ? Currently (5.6 stable) there is an error message, e.g. /etc/pf_gate5.conf:351: port only applies to tcp/udp /etc/pf_gate5.conf:351: skipping rule due to errors /etc/pf_gate5.conf:351: rule expands to no valid combination I cannot follow the no valid combination. Just a suggestion, of course. Keep on your good work Harri
Re: pf to read protocol information from /etc/services ?
On Fri, 27 Feb 2015 09:22:21 + Loïc Blot loic.b...@unix-experience.fr wrote: Hello, in the first example you don't specify proto tcp. Thats the point. /etc/services says telnet 23/tcp so pf could figure this out on its own. Regards Harri
Re: pf to read protocol information from /etc/services ?
On 2015-02-27 10:30, Harald Dunkel wrote: On Fri, 27 Feb 2015 09:22:21 + Loïc Blot loic.b...@unix-experience.fr wrote: Hello, in the first example you don't specify proto tcp. Thats the point. /etc/services says telnet 23/tcp so pf could figure this out on its own. The syntax for this sort of thing (if it ever does any interst and implemented) would probably make more sense as service telnet instead of port telnet, since you're talking about proto+port and not just port. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: pf to read protocol information from /etc/services ?
On Fri, Feb 27, 2015 at 3:40 PM, Research resea...@nativemethods.com wrote: UDP is meaningless in the context of HTTP. Well, actually... https://en.wikipedia.org/wiki/QUIC Not really standard, but still. I now allow UDP on ports 80 and 443 to make Google Chrome happy.
Re: mbsync crashes with segfault on 5.7-current
On Fri, Feb 27, 2015 at 3:16 PM, Jan Vlach ja...@volny.cz wrote: backtrace from binary with debug symbols enabled follows: ... #3 0x1b8c50b8 in nfsnprintf (buf=0xcfbd1920 1425049063.0_2971E�\211, blen=128, fmt=0x3b8bdd71 %ld.%d_%d.%s) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/util.c:193 #4 0x1b8ce4bf in maildir_store_msg (gctx=0x815bd600, data=0xcfbd1a3c, uid=0xcfbd1a48) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/drv_maildir.c:939 Code is wrong: bl = nfsnprintf( base, sizeof(base), %ld.%d_%d.%s, time( 0 ), Pid, ++MaildirCount, Hostname ); Format string uses %ld but time() returns a time_t, which is now long long, so this will fail on all ILP32 archs. Should be patched to bl = nfsnprintf( base, sizeof(base), %lld.%d_%d.%s, (long long)time( 0 ), Pid, ++MaildirCount, Hostname ); (The cast makes it work regardless of what the time_t typedef is.) Line 1089 has another format mismatch: nfsnprintf( nbuf, sizeof(nbuf), %s%s/%s/%ld.%d_%d.%s%s 1089 , gctx-conf-path, gctx-conf-trash, subdirs[gmsg-status M_RECENT], time( 0 ), Pid, ++MaildirCount, Hostname, s ? s : ); Whole port should be built with -Wformat to catch all such issues. Philip Guenther
Re: pf to read protocol information from /etc/services ?
On Feb 27, 2015, at 8:05 AM, Harald Dunkel harald.dun...@aixigo.de wrote:
On Fri, 27 Feb 2015 12:46:19 +
skin...@britvault.co.uk (Craig Skinner) wrote:
$ awk '/^domain/ { print $2 }' /etc/services
53/tcp
53/udp
Now what? Both? Either? First? Last? Random?
Both.
[demime 1.01d removed an attachment of type application/pgp-signature which
had a name of signature.asc]
Both for DNS per-RFC. But service naming means that both TCP and UDP are
implied, so HTTP in a pf rule would apply to TCP and UDP and UDP is meaningless
in the context of HTTP.
Would it not be better to use service names instead of protocol (i.e.: a rule
with “http” instead of “80”), but not infer protocol, as pf does now ?
Re: mbsync crashes with segfault on 5.7-current
Hello David, backtrace from binary with debug symbols enabled follows: Thank you, Jan $ gdb /usr/local/bin/mbsync mbsync.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd5.7... Core was generated by `mbsync'. Program terminated with signal 11, Segmentation fault. Loaded symbols for /usr/local/bin/mbsync Reading symbols from /usr/local/lib/libdb.so.5.0...done. Loaded symbols for /usr/local/lib/libdb.so.5.0 Reading symbols from /usr/lib/libssl.so.32.0...done. Loaded symbols for /usr/lib/libssl.so.32.0 Reading symbols from /usr/lib/libcrypto.so.32.0...done. Loaded symbols for /usr/lib/libcrypto.so.32.0 Reading symbols from /usr/lib/libc.so.78.1...done. Loaded symbols for /usr/lib/libc.so.78.1 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 strlen (str=0x1 Address 0x1 out of bounds) at /usr/src/lib/libc/string/strlen.c:39 39 for (s = str; *s; ++s) (gdb) backtrace #0 strlen (str=0x1 Address 0x1 out of bounds) at /usr/src/lib/libc/string/strlen.c:39 #1 0x08210e03 in __vfprintf (fp=0xcfbd160c, fmt0=0x3b8bdd71 %ld.%d_%d.%s, ap=0xcfbd16dc 006\214;) at /usr/src/lib/libc/stdio/vfprintf.c:879 #2 0x0820df45 in vsnprintf (str=0xcfbd1920 1425049063.0_2971E�\211, n=128, fmt=0x3b8bdd71 %ld.%d_%d.%s, ap=0xcfbd16cc 205) at /usr/src/lib/libc/stdio/vsnprintf.c:61 #3 0x1b8c50b8 in nfsnprintf (buf=0xcfbd1920 1425049063.0_2971E�\211, blen=128, fmt=0x3b8bdd71 %ld.%d_%d.%s) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/util.c:193 #4 0x1b8ce4bf in maildir_store_msg (gctx=0x815bd600, data=0xcfbd1a3c, uid=0xcfbd1a48) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/drv_maildir.c:939 #5 0x1b8c0559 in sync_new (tops=47, sctx=0x89b245c0, tctx=0x815bd600, tconf=0x7f2d42c0, jfp=0x281b7598, srecadd=0xcfbd1c30, pull=1, smaxuid=0xcfbd1bd4) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/sync.c:408 #6 0x1b8c284f in sync_boxes (mctx=0x89b245c0, mname=0x3b8bbcd3 INBOX, sctx=0x815bd600, sname=0x3b8bbcd3 INBOX, chan=0x89735a40) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/sync.c:877 #7 0x1b8bf296 in main (argc=2, argv=0xcfbd1e04) at /usr/ports/pobj/isync-1.0.6/isync-1.0.6/src/main.c:586 (gdb) On Fri, Feb 27, 2015 at 03:50:56PM +0100, David Coppa wrote: Please rebuild mbsync with: $ cd ports/mail/isync ; DEBUG=-ggdb -O0 INSTALL_STRIP= make clean repackage reinstall And post a better backtrace. Ciao! David
Re: Cairo, bug fix and stability increase included on -stable
On 2015-02-26, Henrique Lengler henriquel...@opmbx.org wrote: Hi, In august of 2014, I reported a bug, that makes cairo unstable and gives some segafaults. There was some other people with the same problem. They fixed it, but the fix was only introduced in 1.13, so the openbsd cairo version, have the problem. I would like to know if can this patches be applied on -stable branch? The bug report and the discussion is here: https://bugs.freedesktop.org/show_bug.cgi?id=81699 The two commits that solve the problem is here: http://cgit.freedesktop.org/cairo/commit/?id=13a09526d2120c244471e03b6ae979016ef88e83 http://cgit.freedesktop.org/cairo/commit/?id=a5f51588afd9d5629b03297eb29ff46350b6ba50 I don't see a problem with cherrypicking these commits for -stable, can you send a diff against the -stable ports tree to the maintainer and CC ports@ ?
Re: pf add not working
On 2015-02-26, D'Arcy J.M. Cain da...@vex.net wrote: On Thu, 26 Feb 2015 21:49:15 +0100 Otto Moerbeek o...@drijf.net wrote: What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. Well, from what you describe it is likely there is a rule creating state. It could very well be that one of the rules you left out is the culprit. OK, here is everything: http://www.vex.net/~darcy/pf.conf Use pfctl -ss -v to identify the rule number that created state. Use pfctl -sr -R number to display how that rule was added to the kernel. Few of us here know what level of PF that NetBSD are using and how it interprets rulesets. Additionally: why don't you want to create state? A state check is very much faster than a rule traversal, that's something you probably want on at least the voip media. Additionally #2: dropping packets often doesn't stop SIP floods. https://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/ might be interesting.
