Re: devd problem with 9-stable
On Fri, Jun 15, 2012 at 12:13 PM, Ronald Klop
ronald-freeb...@klop.yi.org wrote:
On Fri, 15 Jun 2012 18:40:45 +0200, Kevin Oberman kob6...@gmail.com wrote:
On Fri, Jun 15, 2012 at 7:53 AM, Ronald Klop
ronald-freeb...@klop.yi.org wrote:
On Fri, 15 Jun 2012 15:50:49 +0200, Warren Block wbl...@wonkity.com
wrote:
On Fri, 15 Jun 2012, Ronald Klop wrote:
On Fri, 15 Jun 2012 08:01:21 +0200, Kevin Oberman kob6...@gmail.com
wrote:
On Thu, Jun 14, 2012 at 3:11 AM, Ronald Klop
ronald-freeb...@klop.yi.org wrote:
On Thu, 14 Jun 2012 02:41:58 +0200, Kevin Oberman kob6...@gmail.com
wrote:
Since updating my systems to 9-Stable, I am not getting my smartcard
reader attached when hot-plugged.
From devd.conf
attach 50 {
device-name ugen[0-9]+;
match vendor 0x0529;
match product 0x0600;
action /usr/local/sbin/openct-control attach usb:529/600 usb
/dev/$dev$
};
detach 50 {
device-name ugen[0-9]+;
match vendor 0x0529;
match product 0x0600;
action /usr/bin/pkill -fx '/usr/local/sbin/ifdhandler -H -p
[a-z0-9]+ $
};
If I manually enter the action command, it works fine, but it
fails
when I insert the device. It worked fine under version 8. I have
confirmed devd is seeing the device inserted just fine. the action
just does not seem to be carried out.
Any idea where I should look? I saw a couple of threads on current
from others seeing something similar, but could find no resolution.
I have seen a
Did you run devd with debug messages on? Options -D and -d are
helpful.
If you do does devd match the right devd.conf sections and start the
action?
With debug i get:
Processing event '!system=USB subsystem=DEVICE type=ATTACH
ugen=ugen1.3 cdev=ugen1.3 vendor=0x0529 product=0x0600 devclass=0xff
devsubclass=0x00 sernum= release=0x0100 mode=host port=1
parent=ugen1.2'
[long list of Testing entries, none of which 'vendor' matched]
Executing 'logger Unknown USB device: vendor 0x0529 product 0x0600 bus
uhub3'
So it looks like devd is not matching the vendor. But my devd.conf
file contains that vendor. I don't know exactly why it is not being
tested against. Nothing in the debug output gives me a clue and I
tried grepping for one of the tested vendor IDs in /etc/devd.conf and
/etc/devd/*.conf. Not found.
I am at a loss.
http://www.freebsd.org/releases/9.0R/errata.html
See point 3 under Open Issues.
Even with those changes, devd is not triggering on my scanner attach:
match subsystem DEVICE;
match type ATTACH;
match cdev ugen[0-9]+.[0-9]+;
match vendor 0x04b8;
match product 0x010a;
action echo HERE! $cdev /tmp/zoot;
# devd -d -D -f /etc/devd/wb.conf
Processing event '!system=USB subsystem=DEVICE type=ATTACH ugen=ugen0.6
cdev=ugen0.6 vendor=0x04b8 product=0x010a devclass=0xff devsubclass=0xff
sernum= release=0x0103 mode=host port=4 parent=ugen0.4'
Pushing table
setting system=USB
setting subsystem=DEVICE
setting type=ATTACH
setting ugen=ugen0.6
setting cdev=ugen0.6
setting vendor=0x04b8
setting product=0x010a
setting devclass=0xff
setting devsubclass=0xff
setting sernum=
setting release=0x0103
setting mode=host
setting port=4
setting parent=ugen0.4
Processing notify event
Testing system=USB against ^DEVFS
Testing system=USB against ^DEVFS
Popping table
I tried the same attaching my webcam on pcbsd in vmware.
[root@pcbsd-1684 /etc/devd]# cat /tmp/bla.conf
notify 100 {
match subsystem DEVICE;
match type ATTACH;
match cdev ugen[0-9]+.[0-9]+;
match vendor 0x2232;
match product 0x1008;
action echo HERE! $cdev /tmp/bla.log;
};
# devd -d -D -f /tmp/bla.conf
...
Processing event '!system=USB subsystem=DEVICE type=ATTACH ugen=ugen1.2
cdev=ugen1.2 vendor=0x2232 product=0x1008 devclass=0xef devsubclass=0x02
sernum= release=0x0019 mode=host port=1 parent=ugen1.1'
Pushing table
setting system=USB
setting subsystem=DEVICE
setting type=ATTACH
setting ugen=ugen1.2
setting cdev=ugen1.2
setting vendor=0x2232
setting product=0x1008
setting devclass=0xef
setting devsubclass=0x02
setting sernum=
setting release=0x0019
setting mode=host
setting port=1
setting parent=ugen1.1
Processing notify event
Testing subsystem=DEVICE against ^DEVICE
Testing type=ATTACH against ^ATTACH
Testing cdev=ugen1.2 against ^ugen[0-9]+.[0-9]+
Testing vendor=0x2232 against ^0x2232
Testing product=0x1008 against ^0x1008
Executing 'echo HERE! ugen1.2 /tmp/bla.log'
Popping table
[root@pcbsd-1684 /etc/devd]# cat /tmp/bla.log
HERE! ugen1.2
Do you see a significant difference with your setup?
Switched to 'notify' with:
notify 50 {
match system USB
match subsystem DEVICE;
match type ATTACH;
match cdev ugen[0-9\.]+;
match vendor 0x0529;
match product 0x0600;
action /usr/local/sbin/openct-control attach usb:529/600 usb
/dev/$devi
ce-name;
};
I still see no attempt to match against vendor
(bsd)tar and multi-volume
Hello, according to tar(1), the base system tape archiver is bsdtar since 8.x , which lacks support for multi-volumes. I guess I can easily omit that restriction by installing gtar from archivers/ in the ports collection. Is there any plan to implement split volume support again for the base system? Any better app to feed tapes these days in FreeBSD? Regards, -Harry signature.asc Description: OpenPGP digital signature
Stucking processes
Hello all. Since I'm using stable as host, and current in chroot, I'll write to both mail list, sorry for any inconvenience. My host is binary freebsd-updated 9; FreeBSD 9.0-RELEASE-p3 (GENERIC) #0: Tue Jun 12 02:52:29 UTC 2012 I have chroot with latest current there installed r237089 (make buildworld buildkernel, no specific flags) When I built from ports some programs in chroot all went fine, until I got stucked process automoc (when building kdelibs4); After few restarts I got build, and forget about it. I'm toying now with portupgrade, and see similar stucks in ruby18 and ruby19 (Even got few times in miniruby while building 1.8); Here's example of stucked processes (they aren't in top, and seems totally inactive. I haven't kill them yet, so can try to dig, but to where?): 2677 5 Is0:00,00 | `-- /bin/sh 2678 5 I 0:00,00 | `-- sudo su 2679 5 I 0:00,00 | `-- su 2680 5 I 0:00,01 | `-- _su (csh) 2687 5 I 0:00,03 | `-- /bin/csh -i 2690 5 I+0:04,34 | `-- ruby19: portupgrade: [1/237] audio/libsamplerate (ruby19) # procstat -k 2690 PIDTID COMM TDNAME KSTACK 2690 100477 ruby19 -mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep do_wait __umtx_op_wait_uint_private_compat32 ia32_syscall Xint0x80_syscall 2690 101110 ruby19 -mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select freebsd32_select ia32_syscall Xint0x80_syscall #top (with inactive filtered out;) last pid: 11049; load averages: 0.09, 0.16, 0.19 up 0+00:14:48 12:27:20 63 processes: 1 running, 62 sleeping CPU: 1.0% user, 0.0% nice, 0.8% system, 1.2% interrupt, 97.0% idle Mem: 184M Active, 96M Inact, 1104M Wired, 2412K Cache, 171M Buf, 454M Free Swap: 4096M Total, 4096M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 2610 root 2 200 261M 82548K kqread 1 0:12 1.27% rtorrent Is this my side's problem, or there's something wrong with current? :) Any help appreciated. -- Regards, Alexander Yerenkow ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mpt: Unable to memory map registers
On 6/15/12 9:24 PM, John Baldwin wrote: On Friday, June 15, 2012 2:12:06 am Andrey Zonov wrote: On 6/13/12 7:10 PM, John Baldwin wrote: On Tuesday, June 12, 2012 5:57:34 pm Andrey Zonov wrote: On 6/13/12 12:51 AM, John Baldwin wrote: On Tuesday, June 12, 2012 3:53:09 pm Andrey Zonov wrote: On 6/12/12 10:06 PM, John Baldwin wrote: [snip] Ok, I've added some more debugging. The patch is a bit larger now and you can fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch New dmesg is in attach. Sheesh, found another bug (wasn't masking 'front' properly). Try updated patch (same URL). Great! It works! Excellent. I've committed the 2 bugs needed to fix your box. However, there is another bug that this exposed that I'd like you to test. Can you update to the latest HEAD, apply the updated pcib_debug.patch, and boot with 'hw.pci.pcib_clear=1' set from the loader? That should exercise the bug I'm worried about and see if my fixes for that (recursively growing windows) works correctly. Attached. Hmm, it doesn't seem like hw.pci.pcib_clear was set (the pcibX devices still tried to allocate their initial windows). Ooops. -- Andrey Zonov MP Configuration Table version 1.4 found at 0x800fcb70 Table 'FACP' at 0xdffb0290 Table 'APIC' at 0xdffb0390 APIC: Found table at 0xdffb0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 5 ACPI ID 4: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 2 ACPI ID 5: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 6 ACPI ID 6: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 3 ACPI ID 7: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 7 ACPI ID 8: enabled SMP: Added CPU 7 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r237018M: Sat Jun 16 09:40:07 UTC 2012 r...@dst-dev.yandex.ru:/usr/obj/usr/src/sys/head amd64 Preloaded elf kernel /boot/kernel/kernel at 0x80fdc000. Calibrating TSC clock ... TSC clock: 2826305989 Hz CPU: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz (2826.31-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xc0ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,OSXSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) Physical memory chunk(s): 0x0001 - 0x0009bfff, 573440 bytes (140 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01028000 - 0xdff9, 3740762112 bytes (913272 pages) 0xdffae000 - 0xdffa, 8192 bytes (2 pages) 0x0001 - 0x0007e2ea0fff, 29576794112 bytes (7220897 pages) avail memory = 33113063424 (31579 MB) INTR: Adding local APIC 0 as a target Event timer LAPIC quality 400 ACPI APIC Table: 090808 APIC1308 INTR: Adding local APIC 0 as a target INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x098000-0x098fff at 0xff800029 x86bios: EBDA 0x09e000-0x09 at 0xfe09e000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 5 APIC: CPU 3 has ACPI ID 7 APIC: CPU 4 has ACPI ID 2 APIC: CPU 5 has ACPI ID 4 APIC: CPU 6 has ACPI ID 6 APIC: CPU 7 has ACPI ID 8 WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ACPI: RSDP 0xf9960 00024 (v02 ACPIAM) ACPI: XSDT 0xdffb0100 00074 (v01 090808 XSDT1308 20080908 MSFT 0097) ACPI: FACP 0xdffb0290 000F4 (v03 090808 FACP1308 20080908 MSFT 0097) ACPI: DSDT 0xdffb04d0 05414 (v01 CLSea CLSea007 0007 INTL 20051117) ACPI: FACS 0xdffbe000 00040 ACPI: APIC 0xdffb0390 000AA
Re: acpidump -dt broken in 9 stable
On Fri, Jun 15, 2012 at 09:57:45PM -0700, mnln.l4 wrote: Just upgrade from 9.0 to 9 stable. `acpidump -dt` shows error message realpath tmp file: No such file or directory It is related to the recent change made to realpath(3) This was a bug/specific operation in acpidump relying on non-conforming realpath(3) behaviour. The r235948 should be merged. pgpqpVC86XDQr.pgp Description: PGP signature
Re: PF to Preventing SMTP Brute Force Attacks
On Jun 15, 2012, at 12:55 PM, Shiv. Nath wrote: # START table bruteforce persist block in log quick from bruteforce pass in on $ext_if proto tcp \ from any to $ext_if port $trusted_tcp_ports \ flags S/SA keep state \ (max-src-conn-rate 3/300, overload bruteforce flush global) # END AND CRON: */12 * * * * /sbin/pfctl -t ssh-bruteforce -T expire 604800 /dev/null 21 What is the function expire 604800 are they entries in the table? should it be -t bruteforce or -t ssh-bruteforce It refers to entries in the table specified by the -t option and instructs pf to expire (remove from the table) all entries older than the specified time (in seconds). Basically, the value 604800 will expire entries older than 1 week. For the above pf rules, the cron entry should be -t bruteforce (although in the pf rules you should be using bruteforce). Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Dear Metthew Paul, Thank you very much for your time, efforts and energy to help me configuring PF. Metthew also advised to create white, so that i do not lock myself. i have have to yet look at it. i will get in touch if i require more help. Thanks Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: USE PF to Prevent SMTP Brute Force Attacks - Resolved !!!
Ooops. Yes, -t bruteforce is correct. expire 604800 means delete
entries after they've been in the table for that number of seconds (ie
after one week)
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
Dear Metthew,
first thanks for assisting to secure 22/25 ports from brute force attack.
i wish to consult if the following white list looks fine to exclude
trusted networks (own network)
int0=em0
secured_attack_ports={21,22,25}
table bruteforce persist
block in log quick from bruteforce
pass in on $int0 proto tcp \
from any to $int0 port $secured_attack_ports \
flags S/SA keep state \
(max-src-conn-rate 5/300, overload bruteforce flush global)
## Exclude Own Netowrk From Brute-Force Rule ##
table own_network persist {71.221.25.0/24, 71.139.22.0/24}
pass in on $int0 proto tcp from own_network to any
OR
pass in on $int0 proto tcp from own_network to secured_attack_ports
Thanks / Regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: USE PF to Prevent SMTP Brute Force Attacks - Resolved !!!
On 16/06/2012 21:03, Shiv. Nath wrote:
Dear Metthew,
Matthew, one a, one e.
first thanks for assisting to secure 22/25 ports from brute force attack.
i wish to consult if the following white list looks fine to exclude
trusted networks (own network)
int0=em0
secured_attack_ports={21,22,25}
table bruteforce persist
block in log quick from bruteforce
pass in on $int0 proto tcp \
from any to $int0 port $secured_attack_ports \
flags S/SA keep state \
(max-src-conn-rate 5/300, overload bruteforce flush global)
## Exclude Own Netowrk From Brute-Force Rule ##
table own_network persist {71.221.25.0/24, 71.139.22.0/24}
pass in on $int0 proto tcp from own_network to any
OR
pass in on $int0 proto tcp from own_network to secured_attack_ports
^
$secured_attack_ports
You seem to have missed out a $ sign there.
But, yes, other than that it looks good looks good. You want to move
the table definitions up to the top of the file and as you've shown, you
want your network specific rule after the more generic rate-limited
accept rule: remember that (except for quick rules) it's the last
matching rule in the ruleset that applies.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
ggate problem
Hi list, I encoutered a panic with ggatec : I misconfigured gg.exports on the server with bad IP address for allowed client. Resulting a panic when creating ggatec on the client. Investigating the panic a I discovered at line 362 in g_gatec.c, the ggio-gctl_sectorsize variable is not checked to be 0 resulting a Fatal trap 18: integer divide fault while in kernel mode, thus because there is no ggated allowed for my client IP (in my misconfigured gg.exports) in my case. It would be better to check before the 'if' at line 362, that the partition we are trying to import with ggatec is available and otherwise give an explicit warning instead of letting the kernel panicing. Sorry for my bad english and the poor description of the problem David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ggate problem
On Sat, Jun 16, 2012 at 11:14:50PM +0200, David ROFFIAEN wrote: Hi list, I encoutered a panic with ggatec : I misconfigured gg.exports on the server with bad IP address for allowed client. Resulting a panic when creating ggatec on the client. Investigating the panic a I discovered at line 362 in g_gatec.c, the ggio-gctl_sectorsize variable is not checked to be 0 resulting a Fatal trap 18: integer divide fault while in kernel mode, thus because there is no ggated allowed for my client IP (in my misconfigured gg.exports) in my case. It would be better to check before the 'if' at line 362, that the partition we are trying to import with ggatec is available and otherwise give an explicit warning instead of letting the kernel panicing. I'm unable to reproduce this. It would be best if you provide: - version of your system - your gg.exports config - exact ggatec command you ran - backtrace from the panic -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
