Re: After installing scsi card, cdrecord stops working.

[Marc L'Heureux]

I used to have dev=/dev/cd0c:0,0,0 but looking at my dmesg I thought I might
have to change it to dev=/dev/cd0c:0,1,1.  Providing different options to
cdrecord does not help, it still bails


It should be dev=/dev/rcd0c:$BUS,0,0 -

where $BUS is the scsi bus number, 1 in your case.

-Otto



Ok, so this works, thanks.  I thought it was 0,1,1 because of the 
follwing dmesg line, but I see my error with the scsibus1 id.


cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2

Anyways, now that my problem is fixed, I'd like some help understanding 
why '# cdrecord -scanbus' doesn't work?  Any thoughts?

After installing scsi card, cdrecord stops working.

[Marc L'Heureux]

I have been running 3.6 for about a year on my server.  I have a backup 
solution that writes to an ide-cdrw 4 times a day.  A month ago I 
installed a scsi card to hook up a newly acquired tape drive.  My cdrw 
backups have been failing since.


I did not change any kernel settings (that I recall), I'm still using 
Generic, and I didn't have to change any sysctl settings.


I've done some tests against the tape drive and it all works ok.

$ sudo mt rewind
$ echo $?
0

When I try to -scanbus I get the following.

$ sudo cdrecord -scanbus
Cdrecord 2.00.3 (i386-unknown-openbsd3.6) Copyright (C) 1995-2002 Jrg 
Schilling

cdrecord: No such file or directory. Cannot open SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are 
root.

cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

I used to have dev=/dev/cd0c:0,0,0 but looking at my dmesg I thought I 
might have to change it to dev=/dev/cd0c:0,1,1.  Providing different 
options to cdrecord does not help, it still bails


$ sudo cdrecord dev=/dev/cd0c:0,1,1 speed=4 blank=fast
Cdrecord 2.00.3 (i386-unknown-openbsd3.6) Copyright (C) 1995-2002 Jrg 
Schilling

scsidev: '/dev/cd0c:0,1,1'
devname: '/dev/cd0c'
scsibus: 0 target: 1 lun: 1
cdrecord: No such file or directory. Cannot open SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are 
root.

cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

I can mount and read the last good backup of my cd, it happened 17 Oct 05 
at 18:00.


$ sudo mount /dev/cd0c /mnt
$ ls -l /mnt
total 447724
-rw-r--r--  1 marc  users475 Jul  7 22:11 backups.rc
-rwxr-xr-x  1 marc  users963 Jul  7 22:11 burnbackups.ksh
-rwxr-xr-x  1 marc  users936 May  7 09:15 homes.ksh
-rw-r--r--  1 root  users  198488314 Oct 17 18:01 homes.tgz
-rw-r--r--  1 root  wheel106 Oct 17 18:02 index.txt
-rw-r--r--  1 root  users   30739621 Oct 17 18:00 
mailserver-20051017-1800.tgz

-rwxr-xr-x  1 marc  users   1138 May  5 18:50 mailserver.ksh
-rw-r--r--  1 marc  users   1966 Jan 19  2005 osbkup.log
-rw-r--r--  1 marc  users   1274 Jan 19  2005 osbkup.rc
-rwxr-xr-x  1 marc  users   2584 Jan 19  2005 osbkup.sh
$ sudo umount /mnt
$ ls -l /mnt
$

I've tried searching google and archives, but I find it difficult to make 
a search query that doesn't just tell me that I need to find the right 
dev= using -scanbus.


Finally, here's my dmesg.  TIA.
I'd provide my dmesg from before the scsi card install, but I don't have 
it around.  I did send it to [EMAIL PROTECTED] though, so it might be 
there if it can be found.


$ dmesg
OpenBSD 3.6 (GENERIC) #59: Fri Sep 17 12:32:57 MDT 2004
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Sempron(tm) 2200+ ("AuthenticAMD" 686-class) 1.50 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE

real mem  = 527867904 (515496K)
avail mem = 474603520 (463480K)
using 4278 buffers containing 26497024 bytes (25876K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 08/06/04, BIOS32 rev. 0 @ 
0xf0010

apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf41b0/208 (11 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x10de product 0x0060
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #2 is the last bus
bios0: ROM list: 0xc/0xdc00 0xce000/0x1000 0xcf000/0x800
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Nvidia nForce2 PCI" rev 0xa2
"Nvidia nForce2" rev 0xa2 at pci0 dev 0 function 1 not configured
"Nvidia nForce2" rev 0xa2 at pci0 dev 0 function 2 not configured
"Nvidia nForce2" rev 0xa2 at pci0 dev 0 function 3 not configured
"Nvidia nForce2" rev 0xa2 at pci0 dev 0 function 4 not configured
"Nvidia nForce2" rev 0xa2 at pci0 dev 0 function 5 not configured
pcib0 at pci0 dev 1 function 0 "Nvidia nForce2 ISA" rev 0xa4
"Nvidia nForce2 SMBus" rev 0xa2 at pci0 dev 1 function 1 not configured
ohci0 at pci0 dev 2 function 0 "Nvidia nForce2 USB" rev 0xa4: irq 11, 
version 1.0, legacy support

usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Nvidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci0 dev 2 function 1 "Nvidia nForce2 USB" rev 0xa4: irq 7, 
version 1.0, legacy support

usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Nvidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
ehci0 at pci0 dev 2 function 2 "Nvidia nForce2 USB2" rev 0xa4: irq 5
ehci0: EHCI version 1.0
ehci0: companion controllers, 4 ports each: ohci0 ohci1
usb2 at ehci0: USB revision 2.0
uhub2 at usb2
uhub2: Nvidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 6 ports with 6 removable, self powered
auich0 at pci0 dev 6 func

Re: Blocking p2p via pf

[Marc L'Heureux]

I don't know if pf can do this, but I've seen ISPs throttle connections 
the longer they're open.  This allows legitimate traffic like HTTP to get 
their small webpage, but larger downloads (such as P2P, but also large 
HTTP downloads) take exponentially longer.


This can still be circumvented by stopping and resuming p2p downloads, but 
it catches the less savvy p2p users.  I agree that the real long term 
solution is to use a content proxy.


ml

On Tue, 11 Oct 2005, Stuart Henderson wrote:


--On 11 October 2005 17:15 +0200, David Elze wrote:


Apart from blocking ports I just see two possibilities:

[..]

You might investigate how many source states users would normally use for 
permitted protocols, how many states are involved with non-permitted use, and 
(ab?)use max-src-states with an overload table to try and contain the 
problem. Expect both false positives and false negatives. beck@ recently 
suggested using overload tables in conjunction with a http redirector to a 
website saying "you've been {evil|stupid}"  which may be 
appropriate depending on your client base...



- slow connections down very hard on well known
  p2p-ports, so the p2p-clients can connect but
  don't get speed at all (still, other dynamic
  ports could be used)


that's not a bad idea, but over time I'd not be surprised to see software to 
test speeds on different ports in an attempt to circumvent this type of 
thing.


Some other ideas involve proxies - either block everything except to trusted 
proxies, or permit other traffic but heavily throttle it.