Re: OT? Is this bad news?
Darren Spruell wrote: On 2/13/07, Han Boetes [EMAIL PROTECTED] wrote: Darren Spruell wrote: Instead we end up with a GPL driver that has to be reverse engineered and we end up with the same problems we already have. Since when is the GPL a close source license? Who said it was? If you mean what I said about the same problems we already have, I mean that we don't have specifications and documentation from which a reliable driver can be written. Problems with magic numbers and unclear implementation details have been pointed out in the past. Reverse engineering can only take you so far, no? Oh right, the Greg KH stuff. I think he should not take half the deal. They should refuse to sign NDA, just like RMS insists. Even if the driver was BSD licensed it wouldn't help you since a linux driver is incompatible with a BSD driver. This is not a BSD v GPL issue at all. This is about some stupid developer accepting a deal when he should fight on. Hardware specifications must be available to all people. Anything else is immoral. # Han
Re: Free Linux Driver Development!
Greg KH wrote: On Wed, Feb 14, 2007 at 08:39:36AM +0100, Stephan A. Rickauer wrote: On the subject of http://www.kroah.com/log/linux/free_drivers.html Now these companies have a great excuse to keep specs locked up tight under NDA, while pretending to be open. The OpenBSD project has been made clear more than once how this will hurt Free Software in the long run. Signing NDA's ensures that Linux gets a working driver, sure, but the internals are indistinguishable from magic. It is a source code version of a blob. I'm guessing that you did not read the followup FAQ about the program at: http://www.kroah.com/log/linux/free_drivers_faq.html Please see the final question and answer on that page. I did read your FAQ but I can't see how it rebuts what has just been said. You seem to be happy with signing NDAs. If the result is a readable and understandable GPL'ed driver, companies will be even less motivated to release programming documentation. This will lead to a GPL-lock-in since you simply replace the vendor not willing to share specifications with an NDA'ed GPL developer not willing to share those, but GPL code only. This is not about freedom but about prostitution. All other projects will have to continue to reverse engineer GPL drivers. A very short sighted strategy of yours, but that's just my opinion. I am just disappointed how easily prominent people like you give up freedom, accompanied by clever-sounding excuses. The price of freedom is eternal vigilance... -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWeb www.ini.unizh.ch RSA public key: https://www.ini.uzh.ch/~stephan/pubkey.asc ---
Re: Free Linux Driver Development!
On Wed, Feb 14, 2007 at 08:39:36AM +0100, Stephan A. Rickauer wrote: On the subject of http://www.kroah.com/log/linux/free_drivers.html Now these companies have a great excuse to keep specs locked up tight under NDA, while pretending to be open. The OpenBSD project has been made clear more than once how this will hurt Free Software in the long run. Signing NDA's ensures that Linux gets a working driver, sure, but the internals are indistinguishable from magic. It is a source code version of a blob. I'm guessing that you did not read the followup FAQ about the program at: http://www.kroah.com/log/linux/free_drivers_faq.html Please see the final question and answer on that page. thanks, greg k-h
Re: Free Linux Driver Development!
On Wed, Feb 14, 2007 at 10:06:36AM +0100, Stephan A. Rickauer wrote: Greg KH wrote: On Wed, Feb 14, 2007 at 08:39:36AM +0100, Stephan A. Rickauer wrote: On the subject of http://www.kroah.com/log/linux/free_drivers.html Now these companies have a great excuse to keep specs locked up tight under NDA, while pretending to be open. The OpenBSD project has been made clear more than once how this will hurt Free Software in the long run. Signing NDA's ensures that Linux gets a working driver, sure, but the internals are indistinguishable from magic. It is a source code version of a blob. I'm guessing that you did not read the followup FAQ about the program at: http://www.kroah.com/log/linux/free_drivers_faq.html Please see the final question and answer on that page. I did read your FAQ but I can't see how it rebuts what has just been said. You seem to have missed: Q: What about the BSDs? A: What about them? They are free to do whatever they wish, I have no input into their development at all, sorry. You seem to be happy with signing NDAs. If the result is a readable and understandable GPL'ed driver, companies will be even less motivated to release programming documentation. This will lead to a GPL-lock-in since you simply replace the vendor not willing to share specifications with an NDA'ed GPL developer not willing to share those, but GPL code only. Well, as my goal is to have a GPL driver for everything, I don't see how this can hurt :) Now others can have different goals, and that's great and fine. I'm not saying you can't work on something if you wish to do so. But for you to try to tell me that I shouldn't work to achive my goal, as it somehow conflicts with your goals, is pretty rude, don't you think? There is no reason you can not extend the same kind of offer to companies to help your project achieve success. This is not about freedom but about prostitution. I'm sorry you feel this way. *plonk*
Re: OT? Is this bad news?
Steven [EMAIL PROTECTED] writes: Which brings me back to the question, what can an OpenBSD/open source/free software user do about it? Sue Linux for anti-competitive behavior? //art
Re: Free Linux Driver Development!
Stephan A. Rickauer [EMAIL PROTECTED] writes: I did read your FAQ but I can't see how it rebuts what has just been said. You seem to be happy with signing NDAs. If the result is a readable and understandable GPL'ed driver, companies will be even less motivated to release programming documentation. This will lead to a GPL-lock-in since you simply replace the vendor not willing to share specifications with an NDA'ed GPL developer not willing to share those, but GPL code only. Which is exactly what the GPL people want since that's the whole point of the license. Otherwise they wouldn't be using the GPL. Duh. //art
named doesn't bind to IP
My named doesn't bind to my private IP and only binds to localhost.
starting BIND 9.3.2-P1
command channel listening on 127.0.0.1#953
command channel listening on ::1#953
I already have the listen-on option in /var/named/etc/named.conf file
pointed to my private IP.
options {
listen-on { 192.168.25.5; };
allow-recursion { clients; };
};
If I do a named -c /var/named/etc/named.conf it gives error -
none:0: open: /var/named/etc/named.conf: file not found
loading configuration: file not found
But the file is there and all files under /var/named are root:named.
My /var/named/etc/named.conf symlinks to /etc/named.conf. And if I
start bind typing named it starts on 127.0.0.1 by reading
/etc/named.conf by default.
Also, if I do named -c /etc/named.conf -g it actually listens on my
private IP along with localhost. Netstat output -
192.168.25.5.domain *.*
Any help would be appreciated.
Re: named doesn't bind to IP
On Wed, Feb 14, 2007 at 09:50:07PM +1100, atstake atstake wrote:
| My named doesn't bind to my private IP and only binds to localhost.
|
| starting BIND 9.3.2-P1
| command channel listening on 127.0.0.1#953
| command channel listening on ::1#953
|
| I already have the listen-on option in /var/named/etc/named.conf file
| pointed to my private IP.
|
| options {
| listen-on { 192.168.25.5; };
| allow-recursion { clients; };
| };
|
| If I do a named -c /var/named/etc/named.conf it gives error -
|
| none:0: open: /var/named/etc/named.conf: file not found
| loading configuration: file not found
|
| But the file is there and all files under /var/named are root:named.
|
| My /var/named/etc/named.conf symlinks to /etc/named.conf. And if I
| start bind typing named it starts on 127.0.0.1 by reading
| /etc/named.conf by default.
|
| Also, if I do named -c /etc/named.conf -g it actually listens on my
| private IP along with localhost. Netstat output -
|
| 192.168.25.5.domain *.*
|
| Any help would be appreciated.
Named is chrooting to /var/named by default. You could try named -t /
-c /var/named/etc/named.conf, but I think you already found the
solution yourself. Just use named -c /etc/named.conf. Check your
'regular' /etc, I doubt there's a named.conf in there.
Read named(8), especially the parts that talk about chroot'ing.
Cheers,
Paul 'WEiRD' de Weerd
--
[++-]+++.+++[---].+++[+
+++-].++[-]+.--.[-]
http://www.weirdnet.nl/
[demime 1.01d removed an attachment of type application/pgp-signature]
Re: mediawiki on chroot
On 2007/02/14 21:55, atstake atstake wrote: I'm getting this error I understand that I need to symlink some file inside the chroot (/var/www) area but I'm not sure which file to be exact. I search previous misc@ archive but they seem a bit confusing. You probably didn't do the 'phpxs' after installing php5-mysql
Re: Free Linux Driver Development!
Artur Grabowski wrote: Stephan A. Rickauer [EMAIL PROTECTED] writes: I did read your FAQ but I can't see how it rebuts what has just been said. You seem to be happy with signing NDAs. If the result is a readable and understandable GPL'ed driver, companies will be even less motivated to release programming documentation. This will lead to a GPL-lock-in since you simply replace the vendor not willing to share specifications with an NDA'ed GPL developer not willing to share those, but GPL code only. Which is exactly what the GPL people want since that's the whole point of the license. Otherwise they wouldn't be using the GPL. Duh. Nah, RMS doesn't want this. A lot of `GPL people' don't want this at all. This deal is meant to divide. # Han
Re: OT? Is this bad news?
Artur Grabowski wrote: Steven [EMAIL PROTECTED] writes: Which brings me back to the question, what can an OpenBSD/open source/free software user do about it? Sue Linux for anti-competitive behavior? Nah. You can't sue `linux,' complain to Greg Kroah Hartmann. Most GPL fans don't want this deal at all. Explain Greg this is unethical. Just like when you email a manifacturer of hardware requesting documentation. # Han
slow io operations on xSeries 336
Hi, I just installed OpenBSD 4.0 on an IBM xSeries 336. I have noticed that, for some reason, I/O operations are not carried out as fast as one would expect for a machine with SCSI disks. For instance, the creation of a 50GB partion took a really long time. The command 4tar xzvf ports.tar.gz4 took more than 14 minutes to finish. Something must be wrong, but I have no idea nor the knowledge to discover. I took a suggestion from a old message in the list and tried to run the .MP kernel, but it did not make any difference. I also noticed that, at boot time, the process stops for quite a while at the line: ipmi0 at mainbus0: I would be very thankful if someone could help me to isolate and solve this problem. Thanks in advance. Regards, Jose ps. below is the output of dmesg. OpenBSD 4.0 (GENERIC.MP) #936: Sat Sep 16 19:27:28 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H, DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16 real mem = 1073094656 (1047944K) avail mem = 970813440 (948060K) using 4256 buffers containing 53755904 bytes (52496K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 01/17/05, BIOS32 rev. 0 @ 0xfd721, SMBIOS rev. 2.3 @ 0xf602c (50 entries) bios0: IBM eserver xSeries 336 -[883721U]- pcibios0 at bios0: rev 2.1 @ 0xf/0x pcibios0: PCI BIOS has 11 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 10 11 15 pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801EB/ER LPC rev 0x00) pcibios0: PCI bus #7 is the last bus bios0: ROM list: 0xc/0xb000 0xcb000/0x4000 ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca8/8 spacing 4 mainbus0: Intel MP Specification (Version 1.4) (IBM ENSW X336 SMP) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200 MHz mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type PCI mainbus0: bus 3 is type PCI mainbus0: bus 4 is type PCI mainbus0: bus 5 is type PCI mainbus0: bus 6 is type PCI mainbus0: bus 7 is type PCI mainbus0: bus 8 is type ISA ioapic0 at mainbus0: apid 14 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 13 pa 0xfec82000, version 20, 24 pins ioapic2 at mainbus0: apid 12 pa 0xfec82400, version 20, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel E7520 MCH rev 0x0a Intel E7520 MCH ERR rev 0x0a at pci0 dev 0 function 1 not configured ppb0 at pci0 dev 2 function 0 Intel MCH PCIE rev 0x0a pci1 at ppb0 bus 2 ppb1 at pci0 dev 4 function 0 Intel MCH PCIE rev 0x0a pci2 at ppb1 bus 3 ppb2 at pci2 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci3 at ppb2 bus 4 mpi0 at pci3 dev 1 function 0 Symbios Logic 53c1030 rev 0x08: apic 13 int 4 (irq 11) scsibus0 at mpi0: 16 targets sd0 at scsibus0 targ 0 lun 0: IBM-ESXS, MAW3300NC FN, C206 SCSI2 0/direct fixed sd0: 286102MB, 78753 cyl, 8 head, 930 sec, 512 bytes/sec, 585937500 sec total safte0 at scsibus0 targ 8 lun 0: IBM, 25P3495a S320 1, 1 SCSI2 3/processor fixed mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 0 DT 1 IU 1 ppb3 at pci2 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci4 at ppb3 bus 5 ppb4 at pci0 dev 6 function 0 Intel MCH PCIE rev 0x0a pci5 at ppb4 bus 6 bge0 at pci5 dev 0 function 0 Broadcom BCM5721 rev 0x01, BCM5750 A1 (0x4001): apic 14 int 16 (irq 11), address 00:0d:60:99:a3:b2 brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb5 at pci0 dev 7 function 0 Intel MCH PCIE rev 0x0a pci6 at ppb5 bus 7 bge1 at pci6 dev 0 function 0 Broadcom BCM5721 rev 0x01, BCM5750 A1 (0x4001): apic 14 int 16 (irq 11), address 00:0d:60:99:a3:b3 brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 Intel E7525 MCH Configuration rev 0x0a at pci0 dev 8 function 0 not configured uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 14 int 16 (irq 11) usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 14 int 19 (irq 3) usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: apic 14 int 23 (irq 5) usb2 at ehci0: USB revision 2.0 uhub2 at usb2 uhub2: Intel EHCI root hub, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered ppb6 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci7 at ppb6 bus 1 vga1 at pci7 dev 1 function 0 ATI Radeon VE QY rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ichpcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 2 Intel 82801EB SATA rev 0x02: DMA, channel 0 configured
I386: Real Mode vs. Protected Mode
Hello! I would like to know when the CPU is switched into protected mode on i386? Before or after executing init386() ? Or does the bootloader / or the BIOS do this? Markus
Performance problems with bge under OpenBSD4.0/i386
Hi, I'm trying to track down the cause of poor network performance under OpenBSD4.0/i386 on HP Proliants (DL380-G4 and DL360-G4p), which seems to be concerning ethernet 802.3x flow control on the bge NICs. Test topology is: HP DL380-G4 int bge0 (BCM5704C auto at 1000baseT full-duplex) | | int Gig 13/6 (auto at 1000baseT full-duplex) Cisco 6513 chassis + WS-X6548-GE-TX + WS-X6748-GE-TX int Gig 12/47 (auto at 1000baseT full-duplex) | | int bge0 (BCM5704C auto at 1000baseT full-duplex) HP DL360-G4p Test traffic is generated with: On Source: dd if=/dev/zero bs=1k count=1 | nc _peer_ 1234 On Sink:nc -l 1234 /dev/null With 4.0-release kernel (GENERIC#1107), the bge driver does not negotiate flowcontrol with the switch: switch# show interfaces flowcontrol | inc Port|admin|Gi12/47|Gi13/6 PortSend FlowControl Receive FlowControl RxPause TxPause adminoper adminoper Gi12/47 desired off desired off 0 0 Gi13/6 desired off desired off 0 0 Network traffic is very slow and the receiving host reports significant 'Input errors' on the NIC interface after transfer: source~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:18:fe:32:2e:4a 1050 0 1276 0 0 source~ dd if=/dev/zero bs=1k count=10 | nc _peer_ 1234 10+0 records in 10+0 records out 10240 bytes transferred in 13.219 secs (7746244 bytes/sec) source~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:18:fe:32:2e:4a52684 0 73166 0 0 sink~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:17:a4:45:f5:25 79 0 106 0 0 sink~ nc -l 1234 /dev/null sink~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:17:a4:45:f5:257084111 50894 0 0 With 4.0-snapshot kernel (GENERIC#1362), the bge driver now negotiates flow control: switch# show interfaces flowcontrol | inc Port|admin|Gi12/47|Gi13/6 PortSend FlowControl Receive FlowControl RxPause TxPause adminoper adminoper Gi12/47 desired on desired on 0 0 Gi13/6 desired on desired on 0 0 However, the transfer is still very slow, and the receiving host still reports significant 'Input errors' on the NIC interface after transfer: source~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:18:fe:32:2e:4a 1459 0 1762 0 0 source~ dd if=/dev/zero bs=1k count=10 | nc _peer_ 1234 10+0 records in 10+0 records out 10240 bytes transferred in 14.120 secs (7251650 bytes/sec) source ~netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:18:fe:32:2e:4a53240 0 73457 0 0 sink~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:17:a4:45:f5:25 89 0 98 0 0 sink~ nc -l 1234 /dev/null sink~ netstat -i -I bge0 | grep -e Name -e Link NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls bge01500 Link 00:17:a4:45:f5:2570849 9 51186 0 0 To summarise, it seems as though flow-control is negotiated for both TX RX in the recent bge driver, but is only functional for TX (if at all). The only relevant source change I can find is: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_bge.c.diff? r1=1.202r2=1.203f=h Flow control support for bge(4)/brgphy(4). From brad@ based on code fromNetBSD with includes the comment /* We can do both TXPAUSE and RXPAUSE. */ Setting 'ifconfig bge0 debug' provides no additional output. I have also repeated the tests with serveral differnet servers, NICs (all bge) and cables and switches to remove faulty device issues. Has anyone an ideas on fixes for this, or how to debug the issue further ? Dmesg below /Pete # dmesg OpenBSD 4.0-current (GENERIC) #1362: Fri Feb 9 14:26:43 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Xeon(TM) CPU 3.40GHz (GenuineIntel 686-class) 3.41 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,SBF,SSE3,MWAIT,DS- CPL,EST,CNXT-ID,CX16 real mem = 1073258496 (1048104K) avail mem = 970895360
Re: Free Linux Driver Development!
On Wed, Feb 14, 2007 at 12:18:16PM +, Jeff Rollin wrote: | On 14/02/07, Han Boetes [EMAIL PROTECTED] wrote: | | Artur Grabowski wrote: | Stephan A. Rickauer [EMAIL PROTECTED] writes: |I did read your FAQ but I can't see how it rebuts what has |just been said. You seem to be happy with signing NDAs. If the |result is a readable and understandable GPL'ed driver, |companies will be even less motivated to release programming |documentation. This will lead to a GPL-lock-in since you |simply replace the vendor not willing to share specifications |with an NDA'ed GPL developer not willing to share those, but |GPL code only. | | Which is exactly what the GPL people want since that's the whole | point of the license. Otherwise they wouldn't be using the | GPL. Duh. | | Nah, RMS doesn't want this. A lot of `GPL people' don't want this | at all. | | This deal is meant to divide. | | | And this discussion isn't? There are already plenty of divisions within the | FOSS world - between the F and OS of FOSS, between Linux and BSD, between | the various BSDs. It's not as if TdR started OpenBSD to continue | contributing to NetBSD, is it? | | And yet when a driver is released under the BSD licence, which conflicts | with the GPL, when do we hear the bitching about it on the BSD side? Wait, | what's that? Oh, we don't? When vendors open up their docs, all profit. When one signs an NDA, in the end, no one profits. Besides, what is keeping Linux from including BSD licensed drivers ? I was under the impression that they have done this in the past. How does a BSD licensed driver conflict with the GPL ? I've heard that the two-clause BSD license should be compatbile with the GPL... Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Free Linux Driver Development!
2007/2/14, Jeff Rollin [EMAIL PROTECTED]: And yet when a driver is released under the BSD licence, which conflicts with the GPL It doesn't. It simply doesn't work under Linux. Best Martin
Re: slow io operations on xSeries 336
On 14/02/2007, at 9:59 PM, Jose Fragoso wrote: Hi, I just installed OpenBSD 4.0 on an IBM xSeries 336. I have noticed that, for some reason, I/O operations are not carried out as fast as one would expect for a machine with SCSI disks. For instance, the creation of a 50GB partion took a really long time. thats very... vague... where are you creating this 50G partitiong? in the installer, or in the installed operating system? what command did you use? how long did it actually take? a really long time could be 5 seconds if you're expectations are too high. The command 4tar xzvf ports.tar.gz4 took more than 14 minutes to finish. Something must be wrong, but I have no idea nor the knowledge to discover. I took a suggestion from a old message in the list and tried to run the .MP kernel, but it did not make any difference. that does seem excessive. can you watch the interrupt rates in the top right of systat vm 1 and let me know what numbers you're seeing? I also noticed that, at boot time, the process stops for quite a while at the line: ipmi0 at mainbus0: the driver is doing a lot of probing to find what sensors are available via ipmi, the pause is normal. I would be very thankful if someone could help me to isolate and solve this problem. Thanks in advance. Regards, Jose ps. below is the output of dmesg. OpenBSD 4.0 (GENERIC.MP) #936: Sat Sep 16 19:27:28 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3 6,CFLUS H, DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16 real mem = 1073094656 (1047944K) avail mem = 970813440 (948060K) using 4256 buffers containing 53755904 bytes (52496K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 01/17/05, BIOS32 rev. 0 @ 0xfd721, SMBIOS rev. 2.3 @ 0xf602c (50 entries) bios0: IBM eserver xSeries 336 -[883721U]- pcibios0 at bios0: rev 2.1 @ 0xf/0x pcibios0: PCI BIOS has 11 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 10 11 15 pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801EB/ER LPC rev 0x00) pcibios0: PCI bus #7 is the last bus bios0: ROM list: 0xc/0xb000 0xcb000/0x4000 ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca8/8 spacing 4 mainbus0: Intel MP Specification (Version 1.4) (IBM ENSW X336 SMP) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200 MHz mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type PCI mainbus0: bus 3 is type PCI mainbus0: bus 4 is type PCI mainbus0: bus 5 is type PCI mainbus0: bus 6 is type PCI mainbus0: bus 7 is type PCI mainbus0: bus 8 is type ISA ioapic0 at mainbus0: apid 14 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 13 pa 0xfec82000, version 20, 24 pins ioapic2 at mainbus0: apid 12 pa 0xfec82400, version 20, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel E7520 MCH rev 0x0a Intel E7520 MCH ERR rev 0x0a at pci0 dev 0 function 1 not configured ppb0 at pci0 dev 2 function 0 Intel MCH PCIE rev 0x0a pci1 at ppb0 bus 2 ppb1 at pci0 dev 4 function 0 Intel MCH PCIE rev 0x0a pci2 at ppb1 bus 3 ppb2 at pci2 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci3 at ppb2 bus 4 mpi0 at pci3 dev 1 function 0 Symbios Logic 53c1030 rev 0x08: apic 13 int 4 (irq 11) scsibus0 at mpi0: 16 targets sd0 at scsibus0 targ 0 lun 0: IBM-ESXS, MAW3300NC FN, C206 SCSI2 0/direct fixed sd0: 286102MB, 78753 cyl, 8 head, 930 sec, 512 bytes/sec, 585937500 sec total safte0 at scsibus0 targ 8 lun 0: IBM, 25P3495a S320 1, 1 SCSI2 3/ processor fixed mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 0 DT 1 IU 1 ppb3 at pci2 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci4 at ppb3 bus 5 ppb4 at pci0 dev 6 function 0 Intel MCH PCIE rev 0x0a pci5 at ppb4 bus 6 bge0 at pci5 dev 0 function 0 Broadcom BCM5721 rev 0x01, BCM5750 A1 (0x4001): apic 14 int 16 (irq 11), address 00:0d:60:99:a3:b2 brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb5 at pci0 dev 7 function 0 Intel MCH PCIE rev 0x0a pci6 at ppb5 bus 7 bge1 at pci6 dev 0 function 0 Broadcom BCM5721 rev 0x01, BCM5750 A1 (0x4001): apic 14 int 16 (irq 11), address 00:0d:60:99:a3:b3 brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 Intel E7525 MCH Configuration rev 0x0a at pci0 dev 8 function 0 not configured uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 14 int 16 (irq 11) usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 14 int 19 (irq 3) usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0 at
Re: Free Linux Driver Development!
On Wed, Feb 14, 2007 at 01:45:06PM +0100, Paul de Weerd wrote: On Wed, Feb 14, 2007 at 12:18:16PM +, Jeff Rollin wrote: | On 14/02/07, Han Boetes [EMAIL PROTECTED] wrote: | | Artur Grabowski wrote: | Stephan A. Rickauer [EMAIL PROTECTED] writes: |I did read your FAQ but I can't see how it rebuts what has |just been said. You seem to be happy with signing NDAs. If the |result is a readable and understandable GPL'ed driver, |companies will be even less motivated to release programming |documentation. This will lead to a GPL-lock-in since you |simply replace the vendor not willing to share specifications |with an NDA'ed GPL developer not willing to share those, but |GPL code only. | | Which is exactly what the GPL people want since that's the whole | point of the license. Otherwise they wouldn't be using the | GPL. Duh. | | Nah, RMS doesn't want this. A lot of `GPL people' don't want this | at all. | | This deal is meant to divide. | | | And this discussion isn't? There are already plenty of divisions within the | FOSS world - between the F and OS of FOSS, between Linux and BSD, between | the various BSDs. It's not as if TdR started OpenBSD to continue | contributing to NetBSD, is it? | | And yet when a driver is released under the BSD licence, which conflicts | with the GPL, when do we hear the bitching about it on the BSD side? Wait, | what's that? Oh, we don't? When vendors open up their docs, all profit. When one signs an NDA, in the end, no one profits. Besides, what is keeping Linux from including BSD licensed drivers ? I was under the impression that they have done this in the past. How does a BSD licensed driver conflict with the GPL ? I've heard that the two-clause BSD license should be compatbile with the GPL... oh come fucking on! do not start this bsd vs gpl crap again! cu -- paranoic mickey (my employers have changed but, the name has remained)
Re: Performance problems with bge under OpenBSD4.0/i386
Pete Vickers a icrit : I'm trying to track down the cause of poor network performance under OpenBSD4.0/i386 on HP Proliants (DL380-G4 and DL360-G4p), which seems to be concerning ethernet 802.3x flow control on the bge NICs. Test topology is: HP DL380-G4 int bge0 (BCM5704C auto at 1000baseT full-duplex) | | int Gig 13/6 (auto at 1000baseT full-duplex) Cisco 6513 chassis + WS-X6548-GE-TX + WS-X6748-GE-TX int Gig 12/47 (auto at 1000baseT full-duplex) | | int bge0 (BCM5704C auto at 1000baseT full-duplex) HP DL360-G4p [...] Has anyone an ideas on fixes for this, or how to debug the issue further ? Did you tweek kernel parameters, like net.inet.ip.ifq.maxlen ? What is the CPU usage during the transfer ? Did you try with autonegotiation off, and with speed fixed at 1000base-T FD on each port ? -- Ronnie Garcia r.garcia at ovea dot com
Re: Free Linux Driver Development!
mickey wrote: oh come fucking on! do not start this bsd vs gpl crap again! On the contrary, this is BSD united with GPL crap. :-) # Han
Re: I386: Real Mode vs. Protected Mode
Hello! On Wed, Feb 14, 2007 at 01:19:04PM +0100, Markus Ritzer wrote: Hello! I would like to know when the CPU is switched into protected mode on i386? Before or after executing init386() ? Or does the bootloader / or the BIOS do this? /usr/src/sys/arch/i386/stand/boot/srt0.S, around line 60: popl %edx cli pushl %cs popl%ds addr32 data32 lgdt (Gdtr - LINKADDR) movl%cr0, %eax orl $CR0_PE, %eax data32 movl %eax, %cr0 data32 ljmp $8, $1f 1: .code32 Markus Kind regards, Hannah. -- Hannah SchrvterEntwicklung [EMAIL PROTECTED] Bei Schlund + Partner AG Brauerstra_e 48 D-76135 Karlsruhe Our software isn't released - it escapes, leaving a trail of bloody testers in its wake. We relish the wailing and gnashing of our customers' teeth!
Re: Free Linux Driver Development!
Han Boetes [EMAIL PROTECTED] writes: Which is exactly what the GPL people want since that's the whole point of the license. Otherwise they wouldn't be using the GPL. Duh. Nah, RMS doesn't want this. A lot of `GPL people' don't want this at all. I quoted too much. The part I meant was: This will lead to a GPL-lock-in. Yeah, big news. I think people pay too much attention to this. Some clown made a bombastic statement about how things have been working for ages. And by that I mean that people write drivers when they get documentation and that Linux is the Microsoft of free software and they don't give a fuck about neither freedom nor quality of their software and will happily sign an NDA just to add another product to their feature sheet. None of this is new, none of this is surprising. Why give him more than his 15 minutes of fame by spreading his I will bend over for documentation bullshit even further? And if you like conspiracy theories, notice that he's working for Novell and this NDA is good, give us more NDA stance is consistent with the still fresh Novell-Microsoft deal that was (in short): patents are good, give us more patents. //art
Annoying problem with dnsmasq
Hello all. I'm trying to set up a firewall/web-proxy/dns-proxy/dhcp-server box at home, using a quite old i386-based pc (AMD k6-2 300, 256mb RAM, 2x10G IDE disks) and OpenBSD 4.0. OS installation, disk management, additional software installation and configuration... everything went fine. Problems started in configuring dnsmasq: I managed to make dns forwarding work ( I really don't need anything more than standard behaviour), then I created a DHCP range entry: expand-hosts domain=manuel.test dhcp-range=192.168.2.100,192.168.2.200,255.255.255.0,1h I chose to activate dnsmasq on the internal intercace only: interface=pcn1 pcn1,'s IP address is fixed and compatible with the range specified: # ifconfig pcn1 pcn1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:29:af:4f:47 media: Ethernet autoselect (autoselect) inet 192.168.2.11 netmask 0xff00 broadcast 192.168.2.255 inet6 fe80::20c:29ff:feaf:4f47%pcn1 prefixlen 64 scopeid 0x2 I read that creating a dhcp-range entry in /etc/dnsmasq.conf makes dnsmasq start the dhcp service automatically, but alas DHCP server apparently doesn't work: linux and windows clients can't grab IP addresses and other IP information, and netstat doesn't show anything listening on port 67/68. # ps -aux | grep dns nobody 16166 0.0 0.3 520 648 ?? S 12:58PM0:00.00 dnsmasq # netstat -an | grep tcp | grep -v tcp6 tcp0 0 127.0.0.1.53 *.*LISTEN tcp0 0 192.168.2.11.53*.*LISTEN tcp0 0 127.0.0.1.6010 *.*LISTEN tcp0 0 192.168.2.11.22192.168.2.1.48605 ESTABLISHED tcp0 0 *.22 *.*LISTEN What am I missing? Thank you everybody for your kind help. Byee, Manuel
Re: Free Linux Driver Development!
On Wed, 14 Feb 2007 13:58:00 +0100, mickey [EMAIL PROTECTED] said: On Wed, Feb 14, 2007 at 01:45:06PM +0100, Paul de Weerd wrote: On Wed, Feb 14, 2007 at 12:18:16PM +, Jeff Rollin wrote: | On 14/02/07, Han Boetes [EMAIL PROTECTED] wrote: | | Artur Grabowski wrote: | Stephan A. Rickauer [EMAIL PROTECTED] writes: |I did read your FAQ but I can't see how it rebuts what has |just been said. You seem to be happy with signing NDAs. If the |result is a readable and understandable GPL'ed driver, |companies will be even less motivated to release programming |documentation. This will lead to a GPL-lock-in since you |simply replace the vendor not willing to share specifications |with an NDA'ed GPL developer not willing to share those, but |GPL code only. | | Which is exactly what the GPL people want since that's the whole | point of the license. Otherwise they wouldn't be using the | GPL. Duh. | | Nah, RMS doesn't want this. A lot of `GPL people' don't want this | at all. | | This deal is meant to divide. | | | And this discussion isn't? There are already plenty of divisions within the | FOSS world - between the F and OS of FOSS, between Linux and BSD, between | the various BSDs. It's not as if TdR started OpenBSD to continue | contributing to NetBSD, is it? | | And yet when a driver is released under the BSD licence, which conflicts | with the GPL, when do we hear the bitching about it on the BSD side? Wait, | what's that? Oh, we don't? When vendors open up their docs, all profit. When one signs an NDA, in the end, no one profits. Besides, what is keeping Linux from including BSD licensed drivers ? I was under the impression that they have done this in the past. How does a BSD licensed driver conflict with the GPL ? I've heard that the two-clause BSD license should be compatbile with the GPL... oh come fucking on! do not start this bsd vs gpl crap again! How long have you people been reading these lists? When are people going to realize that Han is just a troll.
driver maintenance problems
Hi Greg, if i understand correctly, you are advocating the program described on http://www.kroah.com/log/linux/free_drivers.html in order to enable one open source operating system to support as much hardware as possible, which is certainly a useful goal. In fact, i am using Linux myself for one of my servers (the others are running OpenBSD) and for the majority of the workstations i maintain. Yet i am concerned about questions of maintainability of driver code. As far as i understand, the main point about open source software (irrespective of its particular license) is that anybody can read the source code in order to evaluate its functionality, correctness and security, and anybody with the required skills can fix any bugs that might have slipped - or adapt the code to any particular needs. Let me put the problem i feel in the following pointed way, which is all the same not intended to be disrespectful, but only intended to make the point clear, which is, in my humble opinion, not at all a point of Linux vs. BSD. If an immortal being who is at the same time utterly incapable of committing any software bugs writes an open source driver for an operating system which is guaranteed to be absolutely bug free, too, and which is guaranteed to never need any changes to its kernel-driver interfaces, this might be quite useful - provided that the immortal being either commits itself to indefinitely support the driver or that it can foresee any potential uses anybody could have for the hardware device in question. And provided that the operating system in question can fulfill any potential needs any future computer users could ever develop. If a skilled, but mortal programmer carefully writes a driver for a real-world operating system, even if it's a very good OS, it is *much* less useful under NDA than starting from free documentation, irrespective of the particular operating system and irrespective of any licensing issues. Reading source-changes mailing lists, i often see commit messages of the style fixing FOOBAR bug in FOO driver with respect to misuse of BAR firmware (or hardware) interface, thanks to [EMAIL PROTECTED] for pointing this out to me. Shouldn't you try very hard to avoid ruining your chances to profit from such help? To give more examples, how do you guard against developers dropping projects and manufacturers not trusting their successors? Wouldn't you be forced to drop driver support? That would be bad: In the first place, you told Linux users that the device would be supported. Do you deem it fair claiming a device to be supported when a third party you cannot control may in effect force you to drop support? How do you make sure that manufactures do not back out of some of their NDA agreements, effectively rendering the drivers for part of their hardware unmaintainable for future kernel versions? Some manufactures even do such things on purpose in order to motivate customers to buy new products - MS Windows does come to mind here, doesn't it? So if your goal is to get as many GNU/Linux drivers as possible, if your goal is at the same time to get them as correct, as maintainable and as useful as possible, and if your definition of supported includes will also be supported in the future, i really think you should make a stronger point about the importance of open documentation in the GNU/Linux context. In my humble opinion, it would also be fair to tell manufacturers up front and at a prominent place that releasing hardware documentation to the general public will result in better and more flexible drivers, more effective bug squashing and better overall driver maintenance, so in the end of the day, in customers being able to make better use of their device and in getting a better impression of their company. Currently, all i can find in http://www.kroah.com/log/linux/free_drivers.html is this: If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program... I think, at that point, you ought to clearly tell manufacturers that participating in that kind of program will render the resulting driver much less useful than opening documentation. You also ought to seriously urge them in each single case not to take that route. In my humble opinion, even according to your own goals (as far as i understand them) you should seriously reconsider whether writing open source code under NDA is actually useful enough to warrant the effort, in particular given that the offer to do so can motivate manufacturers *not* to release documentation to the public, thereby also harming other GNU/Linux developers and the GNU/Linux community in general and thereby rendering Linux less useful than it could be, regarding the grand total. Additionally, you might consider to supplement your FAQ in the following respects: [EMAIL PROTECTED] $ grep -i maintenance free_drivers*.html [EMAIL PROTECTED] $ grep -i bug
Re: Free Linux Driver Development!
On 2/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: How long have you people been reading these lists? When are people going to realize that Han is just a troll. I've been here since 2004 and i never noticed! However i noticed that Han is sometimes bearer of apparently unpopular opinions So you think he is subscribed just to troll? cognacc
Re: Free Linux Driver Development!
Man I *love* unforeseen consequences! I did read your FAQ but I can't see how it rebuts what has just been said. You seem to have missed: Q: What about the BSDs? A: What about them? They are free to do whatever they wish, I have no input into their development at all, sorry. This is awesome, you protect the vendors by pretending to provide free code. This is so funny that I have tears in my eyes. The GPL has become the new safe harbor for companies who don't want to play in the open source world. Do you really think Sun is GPLing Java because they think it is the right thing to do? The answer might surprise you; they are doing it under pressure from investors because they are not making money. Now how do you give something away but not really? Exactly, Copyrights + GPL. What a fantastic combination! You get inherent patent protection because no one can use your code and copyrights take care of the rest. Now Sun gets to shut up the open source world; hey we gave you (some) of our code now didn't we? And they get to pretend to be open source friendly to boot! The GPL hippies are beat at their own game :-) The GPL being used to protect companies and IP! Oh the irony makes me tingle. You seem to be happy with signing NDAs. If the result is a readable and understandable GPL'ed driver, companies will be even less motivated to release programming documentation. This will lead to a GPL-lock-in since you simply replace the vendor not willing to share specifications with an NDA'ed GPL developer not willing to share those, but GPL code only. Well, as my goal is to have a GPL driver for everything, I don't see how this can hurt :) Sounds like shortsightedness to me. Works for me! Didn't your mommy, or government, tell you to share with others? Now others can have different goals, and that's great and fine. I'm not saying you can't work on something if you wish to do so. But for you to try to tell me that I shouldn't work to achive my goal, as it somehow conflicts with your goals, is pretty rude, don't you think? I am pretty sure your goals are very much the same. Do a s/GPL/BSD/g There is no reason you can not extend the same kind of offer to companies to help your project achieve success. I can't. I am not for sale for some shinny pebbles. This is not about freedom but about prostitution. I'm sorry you feel this way. I am sorry you don't see the damage you are causing. It does illustrate the linux mentality and standards. *plonk* More appropriate would be dee dee dee
Re: OT? Is this bad news?
On Wed, Feb 14, 2007 at 12:51:36PM +0100, Han Boetes wrote: Most GPL fans don't want this deal at all. Real GPL fans appear to be an increasingly diminishing subset of Linux users today though. They're being supplanted by users who want snazzy 3D desktops and simply embrace ``Free Software'' because it's free of cost.
Re: OT? Is this bad news?
* Han Boetes [EMAIL PROTECTED] [070213 23:00]: Darren Spruell wrote: Instead we end up with a GPL driver that has to be reverse engineered and we end up with the same problems we already have. Since when is the GPL a close source license? GPL isn't, but a NDA would require that the documentation, or specifications used to write the driver not be shared. So despite assurances, how could they _not_ obfuscate details in the code if they're to abide by the terms of the NDA? At the same time, how can they obfuscate the code if it's written in terms of the GPL? It seems a little lame to write code under a license like the GPL if you have to sign a NDA to do so. I mean, what takes precedence, and who decides? Does the Linux Driver Development team lack courage to demand open documentation for their drivers so that they can release them properly under the terms of the GPL, or are they actually that deluded that they think that this can work? The problems would be similar if one signed a NDA, and then released code with a BSD license. GPL, however, _requires_ that the code be shared, and so I imagine it will be more problematic. Seriously, how do you resolve the dilemma ethically? Thankfully, there are people like Theo, and the OpenBSD developers, who see this problem more clearly than most. Keep up the good work, and fighting the good fight. In the meantime, I'm going to work on an e-mail to send to Greg Kroah-Hartman expressing my concerns regarding the Linux Driver Development team's recent decision. -- W. Steven Schneider [EMAIL PROTECTED]
Re: Free Linux Driver Development!
Artur Grabowski wrote: Han Boetes [EMAIL PROTECTED] writes: Which is exactly what the GPL people want since that's the whole point of the license. Otherwise they wouldn't be using the GPL. Duh. Nah, RMS doesn't want this. A lot of `GPL people' don't want this at all. I quoted too much. The part I meant was: This will lead to a GPL-lock-in. Yeah, big news. I think people pay too much attention to this. Some clown made a bombastic statement about how things have been working for ages. And by that I mean that people write drivers when they get documentation and that Linux is the Microsoft of free software and they don't give a fuck about neither freedom nor quality of their software and will happily sign an NDA just to add another product to their feature sheet. Now you are making a broad generalisation. It's like saying all muslims are terrorists or all USA people support Bush. I prefer if you keep a neutral stance on the group and reserve your critisism for Greg Kroah Hartmann. For instance Linus Torvalds is firmly against NDA (http://lkml.org/lkml/2005/1/12/361) If you wouldn't say stuff like this I wouldn't even bother replying. None of this is new, none of this is surprising. Why give him more than his 15 minutes of fame by spreading his I will bend over for documentation bullshit even further? And if you like conspiracy theories, notice that he's working for Novell and this NDA is good, give us more NDA stance is consistent with the still fresh Novell-Microsoft deal that was (in short): patents are good, give us more patents. I think he's quite evil indeed. # Han
Re: Free Linux Driver Development!
Greg KH wrote: On Wed, Feb 14, 2007 at 10:06:36AM +0100, Stephan A. Rickauer wrote: You seem to be happy with signing NDAs. If the result is a readable and understandable GPL'ed driver, companies will be even less motivated to release programming documentation. This will lead to a GPL-lock-in since you simply replace the vendor not willing to share specifications with an NDA'ed GPL developer not willing to share those, but GPL code only. Well, as my goal is to have a GPL driver for everything, I don't see how this can hurt :) Now others can have different goals, and that's great and fine. I'm not saying you can't work on something if you wish to do so. But for you to try to tell me that I shouldn't work to achive my goal, as it somehow conflicts with your goals, is pretty rude, don't you think? There is no reason you can not extend the same kind of offer to companies to help your project achieve success. Why do you pursue your goal in this way even though Linus and RMS and many other firmly oppose signing NDA's for very good reasons? You are helping Vendors to keep a lock on the documentation. This is unethical! Everyone should have full specifications to a piece of hardware they have purchased! The GPL was written by RMS because he refused to sign an NDA! # Han
Re: OT? Is this bad news?
On 2/14/07, Steven [EMAIL PROTECTED] wrote: * Han Boetes [EMAIL PROTECTED] [070213 23:00]: Darren Spruell wrote: Instead we end up with a GPL driver that has to be reverse engineered and we end up with the same problems we already have. Since when is the GPL a close source license? GPL isn't, but a NDA would require that the documentation, or specifications used to write the driver not be shared. So despite assurances, how could they _not_ obfuscate details in the code if they're to abide by the terms of the NDA? At the same time, how can they obfuscate the code if it's written in terms of the GPL? It seems a little lame to write code under a license like the GPL if you have to sign a NDA to do so. I mean, what takes precedence, and who decides? Does the Linux Driver Development team lack courage to demand open documentation for their drivers so that they can release them properly under the terms of the GPL, or are they actually that deluded that they think that this can work? The problems would be similar if one signed a NDA, and then released code with a BSD license. GPL, however, _requires_ that the code be shared, and so I imagine it will be more problematic. Seriously, how do you resolve the dilemma ethically? We haven't actually seen what will happen in this situation (unless we have, before my time, but I don't see anyone linking examples). Maybe instead of paranoia we should give the benefit of the doubt. From the FAQ: [NDAs] are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all. He might *actually* be telling the truth. Maybe not all NDAs are conspiracies against us, but are just marketers trying to keep things quiet, and beyond that the companies don't care. That code might actually be readable! --then again it might not. We'll see. Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? -Nick
Kernel panic in 4.1-beta
Greetings: I will not have time for a proper bug report until this evening when I get home, but I thought I would throw this out there for now. This issue is reproducible, and it occurred in the previous snapshot as well. Briefly, here is how it happens: I have net.inet.ip.forwarding=1, and two interfaces: re0 is on my internal LAN which is routed to the internet through another box running 4.0-stable. vr0 is connected to an ibook, also running 4.0-stable, through a switch. The box that panics (vtest) is pretty much idle except for forwarding packets. pf is disabled. To produce the panic, I just generate a lot of traffic from the ibook (a cvs update of /usr/src is generally sufficient). dmesg and ddb output follow. vtest is still sitting at the ddb prompt in case someone can suggest additional information I might gather. OpenBSD/i386 BOOT 2.13 boot booting hd0a:/bsd: entry point at 0x200120 [ using 550188 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.1-beta (GENERIC) #1367: Tue Feb 13 14:05:15 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA Esther processor 1200MHz (CentaurHauls 686-class) 1.21 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2 cpu0: RNG AES AES-CTR SHA1 SHA256 RSA real mem = 1005023232 (981468K) avail mem = 908505088 (887212K) using 4256 buffers containing 50376704 bytes (49196K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 07/18/06, BIOS32 rev. 0 @ 0xfb570, SMBIOS rev. 2.3 @ 0xf (34 entries) apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xdc84 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdbb0/208 (11 entries) pcibios0: bad IRQ table checksum pcibios0: PCI BIOS has 11 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 5 10 11 pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT8237 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xfc00 acpi at mainbus0 not configured cpu0 at mainbus0 cpu0: Enhanced SpeedStep 1200 MHz (860 mV): speeds: 1200, 1000, 800, 600, 400 MHz pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA CN700 Host rev 0x00 pchb1 at pci0 dev 0 function 1 VIA CN700 Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA CN700 Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA PT890 Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA CN700 Host rev 0x00 pchb5 at pci0 dev 0 function 7 VIA CN700 Host rev 0x00 ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 VIA S3 Unichrome PRO IGP rev 0x01: aperture at 0xf400, size 0x1000 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) VIA VT6306 FireWire rev 0x80 at pci0 dev 10 function 0 not configured re0 at pci0 dev 11 function 0 Realtek 8169 rev 0x10, RTL8169/8110SC (0x1800): irq 5, address 00:30:18:a8:10:78 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA pciide0: using irq 11 for native-PCI interrupt pciide1 at pci0 dev 15 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide1 channel 0 drive 0: Maxtor 90680U2 wd0: 16-sector PIO, LBA, 6490MB, 13293504 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 4 pciide1: channel 1 disabled (no drives) uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81: irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 10 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 11 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 11 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 uhub3: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 11 ehci0: timed out waiting for BIOS usb4 at ehci0: USB revision 2.0 uhub4 at usb4 uhub4: VIA EHCI root hub, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x60: irq 11 ac97: codec id 0x56494170 (VIA Technologies 70) ac97:
Re: OT? Is this bad news?
He might *actually* be telling the truth. Maybe not all NDAs are conspiracies against us, but are just marketers trying to keep things quiet, and beyond that the companies don't care. That code might actually be readable! --then again it might not. We'll see. As an optimist, I tend to agree with you. He hasn't really started something new - he's really just making it public knowledge with an open letter to hardware makers how FOSS drivers get made. A lot of shops must avoid the FOSS world because they don't want to take on another platform for support, no knowing that the community will. Realistically, while a company may require an NDA while they want to keep things secret, I expect having an unobfuscated driver out there will negate any need to enforce it longer than necessitated by marketing departments. I also expect that any drivers written in this manner will be discluded from the mainline linux kernel tree unless they are absolutely clearly written to a degree that the top deciders in Linux will accept it regardless of NDAs. Manufacturers who continue to be troublesome will see their drivers go away or require more work at least for users. If I can choose between two SCSI cards in Linux where one is supported by generic kernels, but the other requires either binary blobs or firmware loaders, or patching my own kernel with their code, I'll pick the easy one hands down. I think manufacturers will see that. Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? I imagine that's the best case scenario here, but that certainly does make things harder and everyone's a little more likely to lose something in translation. It's one of those situations where it *can* work, but no one wants to do it that way. It's not as bad as reverse engineering without a working model, but it is still reverse engineering because you're building your own specifications based on something that isn't the specifications. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org Advancing E-Business Standards Since 1993
Re: OT? Is this bad news?
Hello! On Wed, Feb 14, 2007 at 10:42:43AM -0500, Nick ! wrote: [...] Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? That's exactly what was meant by reverse engineer. Then, by reading the GPL code w/o hardware docs, you see only *that* the GPL driver is doing thisorthat, but not *why* exactly it's doing thisorthat at a specific point. And if thisorthat (e.g. peeking and poking around magical I/O addresses, using magical values/bit masks) doesn't work as it should, you don't know exactly in what way it deviates from the hardware spec, as you don't have access to it. I.e. difficult debugging, troubleshooting, maintenance. And the point of Theo co is that it'd be much easier with open documentation. And you could identify points where things are done in an unnecessarily twisted/dirty/... way using the docs and eliminate them, even if you used a GPL driver as *additional* reference, together with docs. -Nick Kind regards, Hannah.
Re: OT? Is this bad news?
On 2/14/07, Nick ! [EMAIL PROTECTED] wrote: On 2/14/07, Steven [EMAIL PROTECTED] wrote: The problems would be similar if one signed a NDA, and then released code with a BSD license. GPL, however, _requires_ that the code be shared, and so I imagine it will be more problematic. Seriously, how do you resolve the dilemma ethically? We haven't actually seen what will happen in this situation (unless we have, before my time, but I don't see anyone linking examples). Maybe instead of paranoia we should give the benefit of the doubt. From the FAQ: We have seen this happen in the past. A couple of examples have already been given, such as when one particular BSD project went under NDA with one particular storage adapter manufacturer and came out with crap drivers for the community. This has also been an item of HUGE debate over the last couple of years in this project's community. Search archives and Undeadly for specifics. I'm providing a couple of resources in this posting. [NDAs] are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, Read: the _created code_ is to be released. Not the _docs_ and _specifications_ that led to the code. What do you think helps keep driver code maintainable and improved as time goes on? Code itself, or documentation and specifications? nothing will be obfuscated at all. This statement is wrong and just plain idiotic. Something is obfuscated; the original specifications from which working, maintainable drivers can be written. The code itself *is* obfuscation. This is the reason our community doesn't petition hardware manufacturers to give us driver source code; it's nearly useless. He might *actually* be telling the truth. Maybe not all NDAs are conspiracies against us, but are just marketers trying to keep things quiet, and beyond that the companies don't care. That code might actually be readable! Don't make excuses for the project guy (as well intentioned as he may be), and certainly don't make excuses for the hardware vendors who screw their customer base. The code will be readable to some degree, without a doubt, but it will *not* accurately provide implementation documentation so that a working, maintainable driver can be authored by other open source projects. Driver code can be filled with magic numbers, meaningless constants, and inadequate commenting that results in a working implementation for the Linux kernel source tree but insufficient information for reverse engineering that crap for any other implementation. In short, it's next to useless. Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? That *has* been the approach in many cases. And it sucks. http://www.openbsd.org/papers/opencon06-docs/index.html http://kerneltrap.org/node/6550 http://kerneltrap.org/node/7184 http://kerneltrap.org/node/6497 DS
Re: OT? Is this bad news?
On 2/14/07, Neil Joseph Schelly [EMAIL PROTECTED] wrote: Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? I imagine that's the best case scenario here, No, the best case scenario is that the good intentions of the Linux driver project would be focused on getting vendors to provide open documentation from which any OSS project, including Linux, can produce good drivers. People say it can't happen, but the OpenBSD project has shown on more than a few occasions that it can and does work. The only difference here is one project has a pair of big brass balls hanging between their legs and the other doesn't. DS
Re: OT? Is this bad news?
Programming documentation is restricted also because the hardware is full of bugs and like Theo said there is no errata for a lot of hardware. On 2/14/07, Rod Dorman [EMAIL PROTECTED] wrote: On Wednesday, February 14, 2007, 10:42:43, Nick ! wrote: ... Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? ... And what, you get a new chunk of code that replicates misinterpretations of the hardware specs? An often quoted open source adage Many eyes make all bugs shallow fails when the number of eyes being permitted to look at the hardware documentation is restricted. -- [EMAIL PROTECTED] The avalanche has already started, it is too Rod Dorman late for the pebbles to vote. - Ambassador Kosh
Re: slow io operations on xSeries 336
thats very... vague... Sorry. I agree. where are you creating this 50G partitiong? in the installer, or in the installed operating system? what command did you use? In the installer. how long did it actually take? a really long time could be 5 seconds if you're expectations are too high. More than 2 minutes, for sure!. Perhaps, more. that does seem excessive. can you watch the interrupt rates in the top right of systat vm 1 and let me know what numbers you're seeing? I did run the same command again. Only this time I used tar xzf ports.tar.gz Look at the times: # date;tar xzf ports.tar.gz;date Wed Feb 14 10:59:34 BRT 2007 Wed Feb 14 11:11:04 BRT 2007 The total number of interrupts ranged from 270 to 850, most of it being mpi0 (170 out of 271 and 747 out of 850). It always showed 100 for clock. If you feel it is important, I can send you the print screen of the moment these values were shown (off the list if you prefer). Thanks a lot in advance. Regards, Jose = Nantucket Summer Vacation Rentals Award-winning island homes in charming Nantucket village. Beautifully furnished. Roses, shell path, white picket fence. Tennis, pool. Contact us for reservations and more information. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=51054f4dd849962e7cce9ae18 5bfd186
ftp though ftp-proxy timeouts
Since upgrading a couple firewalls this weekend from 3.8 to 4.0, I've noticed a large increase in passive-mode FTP transfer timeouts. Before the upgrade, I had no issues...but now there are a number of client's FTP servers that I have to transfer files to and from that transfers simply fail on. I can log in just fine, but the data connections hang at random. Sometimes they work, but often they don't. I've increased the debugging on ftp-proxy and it isn't telling me anything relevant. my ftpproxy_flags are -r relevant lines from my pf.conf: --- nat-anchor ftp-proxy/* rdr-anchor ftp-proxy/* rdr on $int_if inet proto tcp from any to any port 21 - 127.0.0.1 8021 anchor ftp-proxy/* pass out on $ext_if proto tcp from ($ext_if) to any port 21 keep state --- is anyone else experiencing anything similar? TIA. ryanc -- Ryan Corder [EMAIL PROTECTED] Systems Engineer, NovaSys Health LLC. 501-219- ext. 646 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Annoying problem with dnsmasq
On 2/14/07, Manuel Ravasio [EMAIL PROTECTED] wrote: I read that creating a dhcp-range entry in /etc/dnsmasq.conf makes dnsmasq start the dhcp service automatically, but alas DHCP server apparently doesn't work: linux and windows clients can't grab IP addresses and other IP information, and netstat doesn't show anything listening on port 67/68. # ps -aux | grep dns nobody 16166 0.0 0.3 520 648 ?? S 12:58PM0:00.00 dnsmasq # netstat -an | grep tcp | grep -v tcp6 tcp0 0 127.0.0.1.53 *.*LISTEN tcp0 0 192.168.2.11.53*.*LISTEN tcp0 0 127.0.0.1.6010 *.*LISTEN tcp0 0 192.168.2.11.22192.168.2.1.48605 ESTABLISHED tcp0 0 *.22 *.*LISTEN What am I missing? Not sure about anything else you might be missing, but DHCP uses UDP, not TCP. See if PF is currently blocking traffic to your service(s) also. DS
Re: Annoying problem with dnsmasq
On my OpenWRT router, dnsmasq needs to be told that it is authoritative on dhcp requests with the ``dhcp-authoritative'' keyword in dnsmasq.conf On 2/14/07, Manuel Ravasio [EMAIL PROTECTED] wrote: Hello all. I'm trying to set up a firewall/web-proxy/dns-proxy/dhcp-server box at home, using a quite old i386-based pc (AMD k6-2 300, 256mb RAM, 2x10G IDE disks) and OpenBSD 4.0. OS installation, disk management, additional software installation and configuration... everything went fine. Problems started in configuring dnsmasq: I managed to make dns forwarding work ( I really don't need anything more than standard behaviour), then I created a DHCP range entry: expand-hosts domain=manuel.test dhcp-range=192.168.2.100,192.168.2.200,255.255.255.0,1h I chose to activate dnsmasq on the internal intercace only: interface=pcn1 pcn1,'s IP address is fixed and compatible with the range specified: # ifconfig pcn1 pcn1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:29:af:4f:47 media: Ethernet autoselect (autoselect) inet 192.168.2.11 netmask 0xff00 broadcast 192.168.2.255 inet6 fe80::20c:29ff:feaf:4f47%pcn1 prefixlen 64 scopeid 0x2 I read that creating a dhcp-range entry in /etc/dnsmasq.conf makes dnsmasq start the dhcp service automatically, but alas DHCP server apparently doesn't work: linux and windows clients can't grab IP addresses and other IP information, and netstat doesn't show anything listening on port 67/68. # ps -aux | grep dns nobody 16166 0.0 0.3 520 648 ?? S 12:58PM0:00.00 dnsmasq # netstat -an | grep tcp | grep -v tcp6 tcp0 0 127.0.0.1.53 *.*LISTEN tcp0 0 192.168.2.11.53*.*LISTEN tcp0 0 127.0.0.1.6010 *.*LISTEN tcp0 0 192.168.2.11.22192.168.2.1.48605 ESTABLISHED tcp0 0 *.22 *.*LISTEN What am I missing? Thank you everybody for your kind help. Byee, Manuel -- ID: AF133028 fp:9D6B DC0F CCDA 53FA 3F04 A551 BC23 374D AF13 3028
Re: Annoying problem with dnsmasq
Darren Spruell escreveu: On 2/14/07, Manuel Ravasio [EMAIL PROTECTED] wrote: I read that creating a dhcp-range entry in /etc/dnsmasq.conf makes dnsmasq start the dhcp service automatically, but alas DHCP server apparently doesn't work: linux and windows clients can't grab IP addresses and other IP information, and netstat doesn't show anything listening on port 67/68. # ps -aux | grep dns nobody 16166 0.0 0.3 520 648 ?? S 12:58PM0:00.00 dnsmasq # netstat -an | grep tcp | grep -v tcp6 tcp0 0 127.0.0.1.53 *.*LISTEN tcp0 0 192.168.2.11.53*.*LISTEN tcp0 0 127.0.0.1.6010 *.*LISTEN tcp0 0 192.168.2.11.22192.168.2.1.48605 ESTABLISHED tcp0 0 *.22 *.*LISTEN What am I missing? Not sure about anything else you might be missing, but DHCP uses UDP, not TCP. See if PF is currently blocking traffic to your service(s) also. DS Don't know why you would prefer dnsmasq when the default installation of OpenBSD already have both ISC dhcpd and bind daemons. I use then, rather then having to install a package and configure it. Also, if you want a caching nameserver only, simply putting named_flags= on /etc/rc.conf.local and opening requests to your internal net only, on both TCP and UDP port 53, will give a fully functional recursive dns. And the configuration of /etc/dhcpd.conf is the same as ISC dhcpd. There is even an example provided. Also, from the ISC dhcpd readme, http://www.isc.org/sw/dhcp/dhcpv3-README.php#firewall, you must let traffic coming from 0.0.0.0 port 68 udp to 255.255.255.255 port 67 for dhcp queries and also from your internal net port 68 udp to your firewall internal ip port 68 udp for dhcp renews. Try opening up these ports on your internal interface. My regards, -- Giancarlo Razzolini Linux User 172199 Red Hat Certified Engineer no:804006389722501 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Ubuntu 6.10 Edgy Eft Snike Tecnologia em Informatica 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
PF drops tcp packets from a machine with Gentoo linux kernel 2.6.18
I have pf running on an OpenBSD 4.0 (patches 1-5, 7) router and I have one user with two Gentoo Linux machines with kernel 2.6.18 who is having troubles. Everyone else is having no problem at all. This user is having any tcp connection he makes dropped by the firewall. The state shows up when I run pfctl -ss but a sniff on both ends of the router shows that it is dropping the packets. If I set the debug level to loud I get the following output. Gentoo and OpenBSD talking to each other Feb 13 15:35:41 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.6:14625 [lo=1438155416 high=1438171799 win=181 modulator=0] [lo=3399502493 high=3399502674 win=16384 modulator=0] 7:4 FPA seq=3399502493 ack=1438155416 len=776 ackskew=0 pkts=14:3 dir=in,rev Feb 13 15:35:41 titanium /bsd: pf: State failure on: 1 | Feb 13 15:35:43 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.6:11431 [lo=1182669220 high=1182684868 win=181 modulator=0] [lo=2952473521 high=2952473702 win=16384 modulator=0] 4:4 PA seq=2952473521 ack=1182668484 len=752 ackskew=736 pkts=4:2 dir=in,rev Feb 13 15:35:43 titanium /bsd: pf: State failure on: 1 | Feb 13 15:35:43 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.6:11431 [lo=1182669220 high=1182684868 win=181 modulator=0] [lo=2952473521 high=2952473702 win=16384 modulator=0] 4:4 PA seq=2952474273 ack=1182669220 len=24 ackskew=0 pkts=5:2 dir=in,rev Feb 13 15:35:43 titanium /bsd: pf: State failure on: 1 | Feb 13 15:35:44 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.6:11431 [lo=1182669220 high=1182685604 win=181 modulator=0] [lo=2952473521 high=2952473702 win=16384 modulator=0] 4:4 PA seq=2952473521 ack=1182669220 len=776 ackskew=0 pkts=5:3 dir=in,rev Feb 13 15:35:44 titanium /bsd: pf: State failure on: 1 | Feb 13 15:35:47 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.6:11431 [lo=1182669220 high=1182685604 win=181 modulator=0] [lo=2952473521 high=2952473702 win=16384 modulator=0] 4:4 PA seq=2952473521 ack=1182669220 len=776 ackskew=0 pkts=5:3 dir=in,rev Feb 13 15:35:47 titanium /bsd: pf: State failure on: 1 | The two gentoo machines trying to talk to each other Feb 13 14:55:42 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=1806113440 ack=159381924 len=736 ackskew=0 pkts=3:3 dir=out,fwd Feb 13 14:55:42 titanium /bsd: pf: State failure on: 1 | Feb 13 14:55:42 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=159381924 ack=1806113440 len=752 ackskew=0 pkts=3:3 dir=in,rev Feb 13 14:55:42 titanium /bsd: pf: State failure on: 1 | Feb 13 14:55:43 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=1806113440 ack=159381924 len=736 ackskew=0 pkts=3:3 dir=out,fwd Feb 13 14:55:43 titanium /bsd: pf: State failure on: 1 | Feb 13 14:55:43 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=159381924 ack=1806113440 len=752 ackskew=0 pkts=3:3 dir=in,rev Feb 13 14:55:43 titanium /bsd: pf: State failure on: 1 | Feb 13 14:55:43 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=1806113440 ack=159381924 len=736 ackskew=0 pkts=3:3 dir=out,fwd Feb 13 14:55:43 titanium /bsd: pf: State failure on: 1 | Feb 13 14:55:43 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=159381924 ack=1806113440 len=752 ackskew=0 pkts=3:3 dir=in,rev Feb 13 14:55:43 titanium /bsd: pf: State failure on: 1 | Feb 13 14:55:44 titanium /bsd: pf: BAD state: TCP 10.10.10.224:22 10.10.10.224:22 10.8.0.98:54077 [lo=1806113440 high=1806113623 win=181 modulator=0] [lo=159381924 high=159382105 win=183 modulator=0] 4:4 PA seq=1806113440 ack=159381924 len=736 ackskew=0 pkts=3:3 dir=out,fwd Feb 13 14:55:44 titanium /bsd: pf: State failure on: 1 | I am not quite sure exactly how to interpret this but it seemed to be an issue with tcp windows so I had him turn off these two settings on his linux box /proc/sys/net/ipv4/tcp_window_scaling /proc/sys/net/ipv4/tcp_sack After this it started working but seemed slow to him. Checking the pf
Re: OT? Is this bad news?
On 2/14/07, L. V. Lammert [EMAIL PROTECTED] wrote: At 10:24 AM 2/14/2007 -0700, you wrote: No, the best case scenario is that the good intentions of the Linux driver project would be focused on getting vendors to provide open documentation from which any OSS project, including Linux, can produce good drivers. People say it can't happen, but the OpenBSD project has shown on more than a few occasions that it can and does work. The only difference here is one project has a pair of big brass balls hanging between their legs and the other doesn't. DS Unfortunately, Theo's might not even be big enough - many of the h/w venders are now writing drivers with cough, cough DRM included - which will never be OS'd. Windmills anyone? Maybe we need some input from developers (if they get a minute to spare) - what are the probabiliites that we can maintain current drivers now that Vista is driving the market? Can we do anything to help? In general, the developers have already given that advice. Boycott uncooperative vendors' products, give your money to those that provide documentation. No, the OpenBSD community will not put a dent in the picture when compared with the market share of the rest of the customer base. However, even tiny hits to the bottom line become large issues to address when shareholders realize that the company's bottom line isn't where it _could be_. Small though it be, such action can make a difference, especially if the right people feel the pain in the right way. The FOSS community has to realize that this approach will *never* happen if everyone just rolls over and gives up on it (or in to it.) DS
Re: PF drops tcp packets from a machine with Gentoo linux kernel 2.6.18
On 2/14/07, Tim Kuhlman [EMAIL PROTECTED] wrote: I have pf running on an OpenBSD 4.0 (patches 1-5, 7) router and I have one user with two Gentoo Linux machines with kernel 2.6.18 who is having troubles. Everyone else is having no problem at all. This user is having any tcp connection he makes dropped by the firewall. The state shows up when I run pfctl -ss but a sniff on both ends of the router shows that it is dropping the packets. If I set the debug level to loud I get the following output. [snip] One other point I needs some clarification on, in my searching around I did find an article saying that you need the flags S/SA everytime you use keep state for tcp connections in your firewall rules. This didn't seem right to me but I tried it anyway just to see and it had no affect. What is the final word on this, should you always use flags S/SA? This kind of thing has happened to me in the past; likely you're doing something wrong with your state building in the first place so that you're getting state built one direction one interface and checked on a different one, or similar. If you simplify your ruleset as a temporary test, you'll probably find things magically work. If so you'll know it's not the Linux boxen or firewall itself but your policy. Gradually add components back into the ruleset and you'll likely narrow down where you've b0rked it. A couple of other points, I have tried various combinations of scrubing in my pf rules including turning it off with no luck. Also all other machines including other linux boxes work fine with this. If any more information is needed let me know. Thanks for the help! Yeah, when I went through it scrub rules had nothing to do with it. All state, period. (Note that in -current the default is now to implicitly build rules with both 'keep state' and 'S/SA' without having to specify; default stateful behavior makes these boo-boos less likely.) When I had the same problem, it was very erratic and seemed isolated to a Linux box at first too. I don't know if there's something in the TCP stack that reacts more adversely to this, but my fix in that case was a refactoring of my state model. YMMV. DS
Re: Free Linux Driver Development!
On Wednesday 14 February 2007 10:18 am, you wrote: On 2/14/07, Jeff Rollin [EMAIL PROTECTED] wrote: Nah, RMS doesn't want this. A lot of `GPL people' don't want this at all. This deal is meant to divide. And this discussion isn't? There are already plenty of divisions within the FOSS world - between the F and OS of FOSS, between Linux and BSD, between the various BSDs. It's not as if TdR started OpenBSD to continue contributing to NetBSD, is it? And yet when a driver is released under the BSD licence, which conflicts with the GPL, when do we hear the bitching about it on the BSD side? Wait, what's that? Oh, we don't? Why does everyone want to turn this into a GPL vs. BSD license discussion? It's not the license that is up for debate; rather it's the fact that a driver was (will be?) produced under NDA and bridges are now being burned. It's not a matter of license; if a BSD licensed driver was produced from docs acquired under NDA, the problem would be the same. The Linux camp would have to reverse engineer our driver and we don't like that having to be the only option for anyone. The problem is that drivers are / will be produced *without open disclosure of docs*. It's not that a BSD-licensed driver is better for the community; it's the fact that a driver produced under open docs _makes the docs available to the community for their own driver implementations__. This is something no one should argue about. The problem is the NDA, and the shortsightedness; not the license. DS I think you hit the nail on the head... I am sure even RMS is not in favour of this as it goes against the _spirit_ of the GPL. Perhaps he can update v3 to prevent this?
Re: PF drops tcp packets from a machine with Gentoo linux kernel 2.6.18
On Wed, 14 Feb 2007, Tim Kuhlman wrote: [snip] So what is happening? It seems to me that either pf is broken or his linux kernel is broken and pf is catching it. Any ideas as to which is the cause? One other point I needs some clarification on, in my searching around I did find an article saying that you need the flags S/SA everytime you use keep state for tcp connections in your firewall rules. This didn't seem right to me but I tried it anyway just to see and it had no affect. What is the final word on this, should you always use flags S/SA? Not always, but very often. The main rule is to make sure that the packet creating the state is not a packet of an already established connection, but a packet creating the connection. Creating the state from the beginning allows pf to get the info about the window scaling and other tcp options used. Using flags S/SA keep state is the easiest way to achieve that. Note that on current, this is the default. -Otto
Re: Free Linux Driver Development!
On Feb 14, 2007, at 11:48 AM, Marc Ravensbergen wrote: On Wednesday 14 February 2007 10:18 am, you wrote: On 2/14/07, Jeff Rollin [EMAIL PROTECTED] wrote: This is becoming one of those topics which goes on way to long, and in which all the modalities applicable to OpenBSD have been exhausted much earlier in the discussion. NDA's bad. Freedom good. Blobs suck. This is policy enforced by the owner of the name OpenBSD. Linux, Gnu and other subjects have their own mailing lists. -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
dmesg for supermicro x7dvl-e
Hello I've got a new toy today, here's the dmesg: What does this server contain? * Intel Xeon 5130 * SuperMicro X7DVL-E (http://www.supermicro.com/products/motherboard/Xeon1333/5000V/X7DVL-E.cfm) No other specialities. The keyboard is connected via USB, works. Disks are attached to the SATA controller, detected. Fully functional it appears. Made using cd40.iso from amd64. OpenBSD 4.0 (RAMDISK_CD) #883: Sat Sep 16 20:46:50 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 2146426880 (2096120K) avail mem = 1836118016 (1793084K) using 22937 buffers containing 214851584 bytes (209816K) of memory mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: Intel(R) Xeon(R) CPU 5130 @ 2.00GHz, 2000.31 MHz cpu0: FPU,VME,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,SBF,SSE3,NXE,LONG cpu0: 4MB 64b/line 16-way L2 cache pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x25d4 rev 0xb1 ppb0 at pci0 dev 2 function 0 vendor Intel, unknown product 0x25f7 rev 0xb1 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 3 ppb3 at pci2 dev 2 function 0 vendor Intel, unknown product 0x3518 rev 0x01 pci4 at ppb3 bus 4 em0 at pci4 dev 0 function 0 Intel PRO/1000 PT (80003ES2) rev 0x01: irq 11, address 00:30:48:8b:58:b0 em1 at pci4 dev 0 function 1 Intel PRO/1000 PT (80003ES2) rev 0x01: irq 10, address 00:30:48:8b:58:b1 ppb4 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci5 at ppb4 bus 5 vendor Intel, unknown product 0x1a38 (class system subclass miscellaneous, rev 0xb1) at pci0 dev 8 function 0 not configured pchb1 at pci0 dev 16 function 0 Intel 5000 Error Reporting rev 0xb1 pchb2 at pci0 dev 16 function 1 Intel 5000 Error Reporting rev 0xb1 pchb3 at pci0 dev 16 function 2 Intel 5000 Error Reporting rev 0xb1 pchb4 at pci0 dev 17 function 0 Intel 5000 Reserved rev 0xb1 pchb5 at pci0 dev 19 function 0 Intel 5000 Reserved rev 0xb1 pchb6 at pci0 dev 21 function 0 Intel 5000 FBD rev 0xb1 pchb7 at pci0 dev 22 function 0 Intel 5000 FBD rev 0xb1 ppb5 at pci0 dev 28 function 0 Intel 6321ESB PCIE rev 0x09 pci6 at ppb5 bus 6 uhci0 at pci0 dev 29 function 0 Intel 6321ESB USB rev 0x09: irq 5 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 6321ESB USB rev 0x09: irq 10 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 29 function 2 Intel 6321ESB USB rev 0x09: irq 11 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3 at pci0 dev 29 function 3 Intel 6321ESB USB rev 0x09: irq 7 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0 at pci0 dev 29 function 7 Intel 6321ESB USB rev 0x09: irq 5 ehci0: timed out waiting for BIOS usb4 at ehci0: USB revision 2.0 uhub4 at usb4 uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered ppb6 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xd9 pci7 at ppb6 bus 7 vga1 at pci7 dev 1 function 0 ATI ES1000 rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Intel 6321ESB LPC rev 0x09 at pci0 dev 31 function 0 not configured pciide0 at pci0 dev 31 function 1 Intel 6321ESB IDE rev 0x09: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TEAC, CD-224E, 1.9A SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) pciide1 at pci0 dev 31 function 2 Intel 6321ESB SATA rev 0x09: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using irq 10 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: WDC WD1500ADFD-00NLR1 wd0: 16-sector PIO, LBA48, 143089MB, 293046768 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 wd1 at pciide1 channel 1 drive 0: WDC WD1500ADFD-00NLR1 wd1: 16-sector PIO, LBA48, 143089MB, 293046768 sectors wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5 Intel 6321ESB SMBus rev 0x09 at pci0 dev 31 function 3 not configured isa0 at mainbus0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 rd0: fixed, 3584 blocks uhidev0 at uhub0 port 2 configuration 1 interface 0 uhidev0: BTC USB Multimedia Keyboard, rev 1.10/1.20, addr 2, iclass 3/1 ukbd0 at uhidev0 wskbd1 at ukbd0 mux 1 wskbd1: connecting to
Re: SIP on OpenBSD
On Tue, 2007-02-13 at 11:09 +0100, Claudio Jeker wrote: The only problem is that we don't support zaptel. It is an incredible ugly interface that only works with the digium cards that are not supported. Head of the ftp://ftp.sangoma.com/OpenBSD/current_wanpipe/README reads: Future release: Wanpipe version -- o Support Asterisk interface. Nov 23, 2006: wanpipe version - 1.6.5-8 (wanpipe-1.6.5-8.tgz) -- [...] o Support OpenBSD-4.0 kernel Therefore, I am hoping to have Asterisk+Sangoma cards running on OpenBSD sooner than most people are expecting. (Meaning that we won't need zaptel/libpri drivers.) FYI.
Re: OT? Is this bad news?
On Wednesday 14 February 2007 12:24 pm, Darren Spruell wrote: On 2/14/07, Neil Joseph Schelly [EMAIL PROTECTED] wrote: Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? I imagine that's the best case scenario here, No, the best case scenario is that the good intentions of the Linux driver project would be focused on getting vendors to provide open My statement wasn't an opinion, so please don't say I'm wrong. His question was about how this project could lead to drivers for BSD. And it ~could~ be that cleanroom implementations of the driver code developed for GPL projects get reliable enough under BSD here. That is the best case scenario here - that drivers are written well enough that reliable specs can be drawn up from them and be useful. I didn't in my email suggest I thought this was the best way to make drivers. I just answered the question he asked about creating BSD drivers based on GPL'd drivers without the original specs. Please don't correct my statements out of context. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org Advancing E-Business Standards Since 1993
Re: PF drops tcp packets from a machine with Gentoo linux kernel 2.6.18
On Wednesday 14 February 2007 12:11 pm, Darren Spruell wrote:
On 2/14/07, Tim Kuhlman [EMAIL PROTECTED] wrote:
I have pf running on an OpenBSD 4.0 (patches 1-5, 7) router and I have
one user with two Gentoo Linux machines with kernel 2.6.18 who is having
troubles. Everyone else is having no problem at all. This user is having
any tcp connection he makes dropped by the firewall. The state shows up
when I run pfctl -ss but a sniff on both ends of the router shows that
it is dropping the packets. If I set the debug level to loud I get the
following output.
[snip]
One other point I needs some clarification on, in my searching around I
did find an article saying that you need the flags S/SA everytime you
use keep state for tcp connections in your firewall rules. This didn't
seem right to me but I tried it anyway just to see and it had no affect.
What is the final word on this, should you always use flags S/SA?
This kind of thing has happened to me in the past; likely you're doing
something wrong with your state building in the first place so that
you're getting state built one direction one interface and checked on
a different one, or similar.
If you simplify your ruleset as a temporary test, you'll probably find
things magically work. If so you'll know it's not the Linux boxen or
firewall itself but your policy. Gradually add components back into
the ruleset and you'll likely narrow down where you've b0rked it.
A couple of other points, I have tried various combinations of scrubing
in my pf rules including turning it off with no luck. Also all other
machines including other linux boxes work fine with this. If any more
information is needed let me know. Thanks for the help!
Yeah, when I went through it scrub rules had nothing to do with it.
All state, period. (Note that in -current the default is now to
implicitly build rules with both 'keep state' and 'S/SA' without
having to specify; default stateful behavior makes these boo-boos less
likely.)
When I had the same problem, it was very erratic and seemed isolated
to a Linux box at first too. I don't know if there's something in the
TCP stack that reacts more adversely to this, but my fix in that case
was a refactoring of my state model. YMMV.
DS
You think it is an issue with my state table rules even though running an
pfctl -ss shows that the state is established?
I keep state on my outgoing connection and don't do any on the incoming
connection except for some ssh connections which I rate limit. These ssh
connections haven't been the issue anyway.
The basic outgoing rule is relatively simple it is
pass out on { $int_if $vpn_if $ext_if $dsl_if $DMZ_production_if $DMZ_proto_if
} proto {tcp udp icmp} modulate state
After that I do some queuing but most of the test connections should have just
gone into the default queue. Here are the rules,
pass out on $ext_if proto udp from $ext_ip port $vpn_port to $vpn_tungsten keep
state queue vpn
pass out on $ext_if proto udp from $ext_ip port domain to any keep state queue
vpn
pass out on $ext_if from DMZ_production_boxes to any modulate state queue dmz
The problem has occurred between pretty much any combination of those
interfaces except the ext_if and dsl_if which I haven't tested. I will try and
simplify things a bit but unfortunately the box is in production and has a lot
of traffic moving through it right now so I can't do anything too drastic right
away. One thing I will do right away is add the flag S/SA to all of these
entries, I don't see any reason why that will break anything on the live
machine.
Any other specific suggestions?
Whoops I was just grepping for state in my rules and I missed one though it
shouldn't have applied to any of these connections
pass in on $int_if route-to ($dsl_if $dsl_gw) from non-servers to Internet
keep state
Thanks for the help.
--
Tim Kuhlman
Network Administrator
ColoradoVnet.com
Re: PF drops tcp packets from a machine with Gentoo linux kernel 2.6.18
On 2007/02/14 11:47, Tim Kuhlman wrote: So what is happening? It seems to me that either pf is broken or his linux kernel is broken and pf is catching it. Any ideas as to which is the cause? Ruleset more likely. If you post it, people can make suggestions. Might be useful to capture a SYN with tcpdump and post any state entries relating to it, too (the relevant parts of pfctl -ss -v).
Re: SIP on OpenBSD
On 2007/02/14 22:14, Soner Tari wrote: Therefore, I am hoping to have Asterisk+Sangoma cards running on OpenBSD sooner than most people are expecting. (Meaning that we won't need zaptel/libpri drivers.) The Sangoma cards work with their own drivers with zaptel loaded on top http://www.voip-info.org/wiki/view/Sangoma btw, asterisk-bsd is probably a better venue for this.
Re: PF drops tcp packets from a machine with Gentoo linux kernel 2.6.18
On 2007/02/14 12:11, Darren Spruell wrote: Yeah, when I went through it scrub rules had nothing to do with it. All state, period. (Note that in -current the default is now to implicitly build rules with both 'keep state' and 'S/SA' without having to specify; default stateful behavior makes these boo-boos less likely.) When I had the same problem, it was very erratic and seemed isolated to a Linux box at first too. I don't know if there's something in the TCP stack that reacts more adversely to this, but my fix in that case was a refactoring of my state model. YMMV. New linux kernels (and Windows) set the window size such that wscale0 by default (if you want to test this from an OpenBSD box, increase net.inet.tcp.recvspace). As tcpdump will show you, the wscale value is *only* in SYN packets. This is multiplied by the window size in the TCP headers of subsequent packets to find the actual window size (see RFC1323 paragraph 1.1 on 'window size limit' and paragraph 2). If the state was created from a packet other than the SYN, it won't have wscale information (if it was collected, it's shown in pfctl -ss -v). Without this the range of permitted sequence numbers is incorrect and state failures can occur (especially in those cases where the unscaled window size, shown by 'win' in tcpdump, works out to a small value). (People who are intentionally using stateless filtering will have to adjust their ruleset when they upgrade to 4.1; from the mailing list posts about it, the number of people who will be affected negatively by this change is much smaller than the number who will be affected positively).
Re: Free Linux Driver Development!
On Feb 14, 2007, at 1:29 PM, Darren Spruell wrote: On 2/14/07, Jack J. Woehr [EMAIL PROTECTED] wrote: Linux, Gnu and other subjects have their own mailing lists. Only if you operate under the assumption that the actions of these other groups don't undermine the efforts of your own. No, I'm operating under the three (3) assumptions that: a) All us OBSD loyalists have already heard this message. b) All us OBSD loyalists who are going to do something about it have already decided what to do. c) There are no new ideas in the second/third day of a Misc thrash. :-) :-) :-) -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: Free Linux Driver Development!
On 2/14/07, Jack J. Woehr [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 11:48 AM, Marc Ravensbergen wrote: On Wednesday 14 February 2007 10:18 am, you wrote: On 2/14/07, Jeff Rollin [EMAIL PROTECTED] wrote: This is becoming one of those topics which goes on way to long, and in which all the modalities applicable to OpenBSD have been exhausted much earlier in the discussion. NDA's bad. Freedom good. Blobs suck. This is policy enforced by the owner of the name OpenBSD. Linux, Gnu and other subjects have their own mailing lists. Only if you operate under the assumption that the actions of these other groups don't undermine the efforts of your own. What this Linux driver project is doing can seriously impact our ability to get the vendors to release open docs. Look down the road a few years when suddenly the amount of new hardware supported under OpenBSD is at a lesser standard of quality (or reduced). All it takese is for hardware vendors to be led into the comforting knowledge that they don't *have* to release docs since the most popular open source operating system grovels at their feet under NDA. DS
Re: Free Linux Driver Development!
On Feb 14, 2007, at 1:38 PM, Darren Spruell wrote: My alternative is to go blare my mouth on Slashdot, but I'm more than a little outnumbered there. Actually, someone should (has already?) start one of those projects/ campaigns like browse anywhere (http://www.anybrowser.org/campaign/) and create a website and a cute downloadable URL snippet-cum-icon and get people to put it all over the cyberverse. Open Hardware Specs, no blobs, no NDA's. -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
PF + rsync trouble
Hi
I'm having issues with rsyncing ftp.rfc-editor.org through a PF firewall,
other connections (also other rsync connections) work well.
rsync -avz --delete ftp.rfc-editor.org::rfcs-text-only my-rfc-mirror
receiving file list ... done
./
rfc-index.xml
...
rfc1591.txt
rfc1592.txt
nothing is going to happen... will timeout in a few minutes
my setup is LAN -- OBSDGW2 - PPPOE - Internet
fxp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:50:8b:95:a4:d3
description: WLan uplink
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::250:8bff:fe95:a4d3%fxp1 prefixlen 64 scopeid 0x3
inet 10.1.16.1 netmask 0xfffc broadcast 10.1.16.3
pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492
dev: rl0 state: session
sid: 0xe682 PADI retries: 49 PADR retries: 0 time: 09:51:14
I've played with scrub (out on pppoe0 max-mss 1440, +no-df, + fragment
reassemble, ...) but doesnt solve my problem.
I'm using nat on pppoe0 (nat on $extif from localips to any - (pppoe0))
I would provide a full tcpdump, but that would make my message a bit big...
Currently my pf.conf looks as follows:
set block-policy return
set skip on { lo, enc0 }
#scrub in all no-df random-id fragment reassemble
#scrub out on pppoe0 max-mss 1492 no-df
scrub out on pppoe0 max-mss 1440
nat on $extif from localips to any - (pppoe0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
rdr on $allif inet proto tcp from localips
to !norouteips port ftp - 127.0.0.1 port 8021
rdr on $extif inet proto tcp from any to ($extif)
port http - 10.0.0.200 port 80
#rdron $extif inet proto tcp from any to ($extif)
port ftp - 10.0.0.200 port ftp
#rdron $extif inet proto tcp from any to any
port 49152:65535 - 10.0.0.200 port 49152:65535
norouteips and allow local traffic on trusted interfaces
antispoof quick for { $extif, $wlanif }
block in all
passout all keep state flags S/SA
block in quick on $extif inet from norouteips to any
block return out quick on $extif inet proto icmp from any to
norouteips
block dropout quick on $extif inet from any to norouteips
passin quick on $allif inet from localips to !firewall
keep state
passin quick inet proto icmp from any to { ($extif)
firewall } icmp-type echoreq code 0
passin quick inet proto tcp from any to { ($extif)
firewall } port ssh keep state
[some rules for other subnets]
passin on $wlanif inet from 10.1.16.200 to any
keep state flags S/SA
18:28:07.899188 128.9.176.20.rsync 10.1.16.200.1701: . 9777343:9778583(1240)
ack 100609 win 0 nop,nop,timestamp 1443728300 1809939 (DF)
18:28:07.901084 10.1.16.200.1701 128.9.176.20.rsync: . ack 9778583 win 23552
nop,nop,timestamp 1810010 1443728300 (DF)
18:28:07.902910 128.9.176.20.rsync 10.1.16.200.1701: . 9778583:9780011(1428)
ack 100609 win 0 nop,nop,timestamp 1443728300 1809939 (DF)
18:28:07.906844 128.9.176.20.rsync 10.1.16.200.1701: . 9780011:9781439(1428)
ack 100609 win 0 nop,nop,timestamp 1443728300 1809939 (DF)
18:28:07.908805 10.1.16.200.1701 128.9.176.20.rsync: . ack 9781439 win 23552
nop,nop,timestamp 1810012 1443728300 (DF)
18:28:07.910276 128.9.176.20.rsync 10.1.16.200.1701: . 9781439:9782679(1240)
ack 100609 win 0 nop,nop,timestamp 1443728300 1809939 (DF)
18:28:07.913469 10.1.16.200.1701 128.9.176.20.rsync: . ack 9782679 win 23552
nop,nop,timestamp 1810013 1443728300 (DF)
18:28:07.914486 128.9.176.20.rsync 10.1.16.200.1701: . 9782679:9784107(1428)
ack 100609 win 0 nop,nop,timestamp 1443728300 1809939 (DF)
18:28:07.918422 128.9.176.20.rsync 10.1.16.200.1701: . 9784107:9785535(1428)
ack 100609 win 0 nop,nop,timestamp 1443728302 1809944 (DF)
18:28:07.920355 10.1.16.200.1701 128.9.176.20.rsync: . ack 9785535 win 23552
nop,nop,timestamp 1810015 1443728300 (DF)
18:28:07.921610 128.9.176.20.rsync 10.1.16.200.1701: . 9785535:9786775(1240)
ack 100609 win 0 nop,nop,timestamp 1443728302 1809944 (DF)
18:28:07.923453 10.1.16.200.1701 128.9.176.20.rsync: . ack 9786775 win 23552
nop,nop,timestamp 1810016 1443728302 (DF)
18:28:07.925819 128.9.176.20.rsync 10.1.16.200.1701: . 9786775:9788203(1428)
ack 100609 win 0 nop,nop,timestamp 1443728302 1809944 (DF)
18:28:07.929512 128.9.176.20.rsync 10.1.16.200.1701: . 9788203:9789631(1428)
ack 100609 win 0 nop,nop,timestamp 1443728302 1809944 (DF)
18:28:07.931435 10.1.16.200.1701 128.9.176.20.rsync: . ack 9789631 win 23552
nop,nop,timestamp 1810018 1443728302 (DF)
18:28:07.933195 128.9.176.20.rsync 10.1.16.200.1701: . 9789631:9790871(1240)
ack 100609 win 0 nop,nop,timestamp 1443728302 1809944 (DF)
18:28:07.936777 10.1.16.200.1701
Nagios plugin for checking OpenBGPd-Peers
Hello, has anybody wrote a nagios plugin to check the presence of some specified bgp-peers set up with openbgpd? In the past I used check_bgp in combination with cisco routers, which checks the peer-state via snmp. Regards, Falk
Re: slow io operations on xSeries 336
can i see a dmesg as well? if you're running the machine as an amd64, can you try it again as an i386? dlg On 15/02/2007, at 3:38 AM, Jose Fragoso wrote: thats very... vague... Sorry. I agree. where are you creating this 50G partitiong? in the installer, or in the installed operating system? what command did you use? In the installer. how long did it actually take? a really long time could be 5 seconds if you're expectations are too high. More than 2 minutes, for sure!. Perhaps, more. that does seem excessive. can you watch the interrupt rates in the top right of systat vm 1 and let me know what numbers you're seeing? I did run the same command again. Only this time I used tar xzf ports.tar.gz Look at the times: # date;tar xzf ports.tar.gz;date Wed Feb 14 10:59:34 BRT 2007 Wed Feb 14 11:11:04 BRT 2007 The total number of interrupts ranged from 270 to 850, most of it being mpi0 (170 out of 271 and 747 out of 850). It always showed 100 for clock. If you feel it is important, I can send you the print screen of the moment these values were shown (off the list if you prefer). Thanks a lot in advance. Regards, Jose = Nantucket Summer Vacation Rentals Award-winning island homes in charming Nantucket village. Beautifully furnished. Roses, shell path, white picket fence. Tennis, pool. Contact us for reservations and more information. http://a8-asy.a8ww.net/a8-ads/adftrclick? redirectid=51054f4dd849962e7cce9ae18 5bfd186
Re: Performance problems with bge under OpenBSD4.0/i386
From: Pete Vickers [EMAIL PROTECTED] Date: Wed, 14 Feb 2007 13:33:25 +0100 # ifconfig bge0 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:17:a4:45:f5:25 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::217:a4ff:fe45:f525%bge0 prefixlen 64 scopeid 0x1 inet x.x.x.x netmask 0xff00 broadcast x.x.x.x This suggests flow control has *not* been negotiated. With msk(4), I get: borodin$ ifconfig msk0 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:16:cb:a2:87:67 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet6 fe80::216:cbff:fea2:8767%msk0 prefixlen 64 scopeid 0x1 inet 192.168.0.17 netmask 0xff00 broadcast 192.168.0.255
Re: PF + rsync trouble
On Wednesday 14 February 2007 21:59, Chris C. wrote:
Hi
I'm having issues with rsyncing ftp.rfc-editor.org through a PF firewall,
other connections (also other rsync connections) work well.
rsync -avz --delete ftp.rfc-editor.org::rfcs-text-only my-rfc-mirror
receiving file list ... done
./
rfc-index.xml
...
rfc1591.txt
rfc1592.txt
nothing is going to happen... will timeout in a few minutes
my setup is LAN -- OBSDGW2 - PPPOE - Internet
fxp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:50:8b:95:a4:d3
description: WLan uplink
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::250:8bff:fe95:a4d3%fxp1 prefixlen 64 scopeid 0x3
inet 10.1.16.1 netmask 0xfffc broadcast 10.1.16.3
pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492
dev: rl0 state: session
sid: 0xe682 PADI retries: 49 PADR retries: 0 time: 09:51:14
I've played with scrub (out on pppoe0 max-mss 1440, +no-df, + fragment
reassemble, ...) but doesnt solve my problem.
I'm using nat on pppoe0 (nat on $extif from localips to any - (pppoe0))
I would provide a full tcpdump, but that would make my message a bit big...
Currently my pf.conf looks as follows:
set block-policy return
set skip on { lo, enc0 }
#scrub in all no-df random-id fragment reassemble
#scrub out on pppoe0 max-mss 1492 no-df
scrub out on pppoe0 max-mss 1440
nat on $extif from localips to any - (pppoe0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
rdr on $allif inet proto tcp from localips
to !norouteips port ftp - 127.0.0.1 port 8021
rdr on $extif inet proto tcp from any to ($extif)
port http - 10.0.0.200 port 80
#rdron $extif inet proto tcp from any to ($extif)
port ftp - 10.0.0.200 port ftp
#rdron $extif inet proto tcp from any to any
port 49152:65535 - 10.0.0.200 port 49152:65535
norouteips and allow local traffic on trusted interfaces
antispoof quick for { $extif, $wlanif }
block in all
passout all keep state flags S/SA
block in quick on $extif inet from norouteips to any
block return out quick on $extif inet proto icmp from any to
norouteips
block dropout quick on $extif inet from any to norouteips
passin quick on $allif inet from localips to !firewall
keep state
passin quick inet proto icmp from any to {
($extif) firewall } icmp-type echoreq code 0
passin quick inet proto tcp from any to {
($extif) firewall } port ssh keep state
[some rules for other subnets]
passin on $wlanif inet from 10.1.16.200 to
any keep state flags S/SA
[tcpdump]
any suggestions? thanks!
Have to reply to my own post...
The rsync process completes on the gateway itself, but not on any device
behind it.
Re: Problems with routing
On 13/02/07, Martin Schrvder [EMAIL PROTECTED] wrote: 2007/2/14, Jamie Penman-Smithson [EMAIL PROTECTED]: Any hints? afterboot(8) has a section on routing. Best Martin I read afterboot(8) but I didn't see anything related to the issue that I'm experiencing. Time to go back to Linux I suppose.. -- -Jamie L. Penman-Smithson [EMAIL PROTECTED]
Tunnel, VPN, NAT
I've managed to solve a problem that was bodering me for some time now. I decided to put this solution to the list just in case someday somebody will be in similar situation. How to solve the problem described on this picture: 193.x.x.x/27 193.y.y.y/27 | 192.168.1.0/24 | 192.168.2.0/24 || || || || Host A tunnel Host D -Internet 172.16.16.6 172.16.15.6 \/ +-- Host B -- Host C --+ 172.16.16.5172.16.15.5 In short, I have two distant locations, connected with fiber, only one has access to internet. The client requested to have on both locations public addressable IP space and private addressable IP space. Host A and Host D are connected by a fiber provider, who connected both locations with a PTP (Host B Host C are providers routers). The solution I came to (with the help of Dag Richards) is to build a gre tunnel from host A to Host D. Firstly I managed to access internet using ipsec. Dag pointed out that I should be doing NAT before ipsec. Explanation: packet enters routing decision is made - packet encrypted if matches quickmode route egress iface chosen NAT applied So on the same router that can't be done in OBSD. So I left out encryption for this part of the project, because I don't need encryption for traffic going to internet. The task now is to build a gre tunnel between Host A Host D. Building up gre tunnel and setting up routes: Enable on both routers: sysctl net.inet.gre.allow=1 Host A # cat /etc/hostname.gre0 193.x.x.x 193.z.z.z netmask 0x link1 up tunnel 172.16.16.6 172.16.15.6 !route -qn delete default !route -qn add -host default 193.z.z.z Host D # cat /etc/hostname.gre0 193.z.z.z 193.x.x.x netmask 0x link1 up tunnel 172.16.15.6 172.16.16.6 !route add 192.168.1.0/24 193.x.x.x !route add 193.x.x.x/27 193.x.x.x I had to add those routes just to tell the router where to send packets that have been natted and to route other public addressable IP space through the tunnel. Now I have a working tunnel, Host A can access the internet. Let's allow others to access internet from private addressable IP space on Host A. As Dag pointed out I should be doing NAT for request coming from 192.168.1.0/24 on the end of gre tunnel, on Host D. This should look something like this: nat on bge0 from 192.168.1.0/24 - 193.x.x.x, where bge0 stands for my external_if on Host D. Be careful to allow gre proto in both pf.conf. After that I just had to connect two LANs together with ipsec: On host D: ike esp from 192.168.2.0/24 to 192.168.1.0/24 peer 172.16.16.6 On Host A: ike esp from 192.168.1.0/24 to 192.168.2.0/24 peer 172.16.15.6 Mitja
Re: Problems with routing
2007/2/14, Jamie Penman-Smithson [EMAIL PROTECTED]: I read afterboot(8) but I didn't see anything related to the issue that I'm experiencing. -- If you wish to route packets between interfaces, add one or both of the following directives (depending on whether IPv4 or IPv6 routing is re- quired) to /etc/sysctl.conf: net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Packets are not forwarded by default, due to RFC requirements. -- Time to go back to Linux I suppose.. We won't miss you. Best Martin
Re: external usb disk freezing machine
hmm, on Wed, Feb 07, 2007 at 08:42:19PM +0100, frantisek holop said that here i go again, describing usb problems. i am really not sure now if it is a) my external disk, b) openbsd, c) bios/motherboard/usb port that is giving me the headache... none of them. it seems that it was acpi after all, and acpi.c,v 1.78 solves this issue. -f -- friends are people you can be quiet with.
Re: external usb disk freezing machine
Cool :-) On Thu, Feb 15, 2007 at 12:08:11AM +0100, frantisek holop wrote: hmm, on Wed, Feb 07, 2007 at 08:42:19PM +0100, frantisek holop said that here i go again, describing usb problems. i am really not sure now if it is a) my external disk, b) openbsd, c) bios/motherboard/usb port that is giving me the headache... none of them. it seems that it was acpi after all, and acpi.c,v 1.78 solves this issue. -f -- friends are people you can be quiet with.
Re: PF + rsync trouble
On 2/14/07, Chris C. [EMAIL PROTECTED] wrote: On Wednesday 14 February 2007 21:59, Chris C. wrote: Hi I'm having issues with rsyncing ftp.rfc-editor.org through a PF firewall, other connections (also other rsync connections) work well. rsync -avz --delete ftp.rfc-editor.org::rfcs-text-only my-rfc-mirror receiving file list ... done ./ rfc-index.xml ... rfc1591.txt rfc1592.txt nothing is going to happen... will timeout in a few minutes any suggestions? thanks! Have to reply to my own post... The rsync process completes on the gateway itself, but not on any device behind it. Enable debugging in PF and see if you get any error conditions in your kernel logs. # pfctl -x loud (set back to normal with 'pfctl -x urgent') -- Darren Spruell [EMAIL PROTECTED]
Re: Problems with routing
On 14/02/07, Martin Schrvder [EMAIL PROTECTED] wrote: 2007/2/14, Jamie Penman-Smithson [EMAIL PROTECTED]: I read afterboot(8) but I didn't see anything related to the issue that I'm experiencing. If you wish to route packets between interfaces, add one or both of the following directives (depending on whether IPv4 or IPv6 routing is re- quired) to /etc/sysctl.conf: net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 I already did this, to no effect. -- -Jamie L. Penman-Smithson [EMAIL PROTECTED]
Re: Problems with routing
I'm attempting to setup openbsd 4.0 as a router, the system has two interfaces, rl0 and rl1. It looks something like this (apologies if this looks really odd): router [x.x.58.129] --- router2: rl0 [x.x.58.130] router2: rl1 [x.x.58.140] --- Not so much odd as lacking information. Post ifconfig output instead. Presumably the OpenBSD box is 'router2', though you don't actually say. If I had to guess, I'd say you're probably trying to overlap networks and not doing it right, but you won't get good answers if you make people guess. Which box are you talking about anyway? (I'd guess router2, but you don't actually say). DMZ subnet x.x.58/28 I don't see any x.x.58.0 networks in your diagram, is that what you actually meant to write? route add -net x.x.58.128 -netmask 255.255.255.240 -iface x.x.58.140 route add -host x.x.58.129 -iface x.x.58.130 Directly connected networks already appear in the routing table, you don't add static routes for them. Under Linux I just had: ... irrelevant, this is not Linux.
is there an install packages file list?
I'm going to be installing on a soekris box (probably on flash media), and I'm trying to figure out what the bare minimum I need to install. Is there somewhere I can see what files are included in the base40.tgz, etc40.tgz etc... so I know what don't fill up the flash card at the start? They are going to be a pf firewall, and ipsec vpn (with one of them running poptop for roadwarriors). Any pitfalls I should watch out for on this? fstab options etc..? --Bryan
Re: Problems with routing
On 15/02/07, Stuart Henderson [EMAIL PROTECTED] wrote: I'm attempting to setup openbsd 4.0 as a router, the system has two interfaces, rl0 and rl1. It looks something like this (apologies if this looks really odd): router [x.x.58.129] --- router2: rl0 [x.x.58.130] router2: rl1 [x.x.58.140] --- Not so much odd as lacking information. Post ifconfig output instead. Presumably the OpenBSD box is 'router2', though you don't actually say. Yes, router2 is the OpenBSD box. rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:50:fc:a0:c9:ae groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 82.133.58.130 netmask 0xfff0 broadcast 82.133.58.143 inet6 fe80::250:fcff:fea0:c9ae%rl0 prefixlen 64 scopeid 0x2 rl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:50:fc:a0:c9:b0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 82.133.58.140 netmask 0xfff0 broadcast 82.133.58.143 inet6 fe80::250:fcff:fea0:c9b0%rl1 prefixlen 64 scopeid 0x3 If I had to guess, I'd say you're probably trying to overlap networks and not doing it right, but you won't get good answers if you make people guess. Which box are you talking about anyway? (I'd guess router2, but you don't actually say). router2 Thanks, -- -Jamie L. Penman-Smithson [EMAIL PROTECTED]
Re: is there an install packages file list?
On 2/14/07, Bryan Irvine [EMAIL PROTECTED] wrote: I'm going to be installing on a soekris box (probably on flash media), and I'm trying to figure out what the bare minimum I need to install. Is there somewhere I can see what files are included in the base40.tgz, etc40.tgz etc... so I know what don't fill up the flash card at the start? They're just .tgz files. Just $tar -tzvf *40.tgz They are going to be a pf firewall, and ipsec vpn (with one of them running poptop for roadwarriors). Any pitfalls I should watch out for on this? fstab options etc..? This has come up before lots. Trying searching the archives at http://marc.theaimsgroup.com?l=openbsd-misc and good luck -Nick
Re: is there an install packages file list?
On Wed, 14 Feb 2007 17:00:55 -0800, Bryan Irvine wrote: I'm going to be installing on a soekris box (probably on flash media), and I'm trying to figure out what the bare minimum I need to install. Is there somewhere I can see what files are included in the base40.tgz, etc40.tgz etc... so I know what don't fill up the flash card at the start? They are going to be a pf firewall, and ipsec vpn (with one of them running poptop for roadwarriors). Any pitfalls I should watch out for on this? fstab options etc..? Don't even consider reducing the base install. There is no reason to. On a Soekris 4801 here I have been running OpenBSD 3.9 and 4.0 for more that a year (3.9 beta was running before release) on a Apacer PhotoSteno CF card with verbose spamd logging (until a month ago when I moved spamd onto our new MTA). I do pxe boot installs and I leave out all the X sets and the comp set. Xis not needed for anything on that host and compiling is best done on a build host we keep here with lots more RAM and grunt in the CPU. The CF is 512MB but any new boxes will have 1024MB simply because they are now cheaper than the 512 was when I bought it and also the wear-levelling is better on larger CFs. Pretty soon we won't see smaller cards easily bought. I don't run httpd or use sendmail for anything except the daily/weekly/monthly/security reports but it is more work trimming stuff than the benefit of smaller filesystems when I'm not short of space anyway. Here is the end of disklabel followed by mount and df -h. Note that I have an unused 68.9 MB partition and that /usr has ALL the manpages loaded and space for any packages I may need to add. Swap is never used. I just tossed a bit in because (1) it stops the system whinging about it not being there and (2) I don't need the space, as you can see. 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 60.0M 0.0M 4.2BSD 2048 16384 122 # Cyl 0*- 121 b: 9.8M 60.0Mswap # Cyl 122 - 141 c:488.7M 0.0M unused 0 0 # Cyl 0 - 992 d: 99.9M 69.9M 4.2BSD 2048 16384 204 # Cyl 142 - 344 e:250.0M169.8M 4.2BSD 2048 16384 328 # Cyl 345 - 852 f: 68.9M419.8M 4.2BSD 2048 16384 16 # Cyl 853 - 992 [puffy:/var/log] $ mount /dev/wd0a on / type ffs (local, noatime, softdep) /dev/wd0e on /usr type ffs (local, noatime, nodev, read-only, softdep) /dev/wd0d on /var type ffs (local, noatime, nodev, nosuid, softdep) [puffy:/var/log] $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/wd0a 59.0M 27.3M 28.8M49%/ /dev/wd0e 245M163M 69.6M70%/usr /dev/wd0d 98.3M6.6M 86.8M 7%/var Any questions? Rod/ From the land down under: Australia. Do we look umop apisdn from up over?
Re: is there an install packages file list?
On 2/14/07, Bryan Irvine [EMAIL PROTECTED] wrote: I'm going to be installing on a soekris box (probably on flash media), and I'm trying to figure out what the bare minimum I need to install. Is there somewhere I can see what files are included in the base40.tgz, etc40.tgz etc... so I know what don't fill up the flash card at the start? They are going to be a pf firewall, and ipsec vpn (with one of them running poptop for roadwarriors). Any pitfalls I should watch out for on this? fstab options etc..? After reading many posts on misc about the reliability of CF and since 1 GB compact flash is cheap these days I didn't bother with any of the above and just did an install picking the sets that I needed, avoiding x*, comp, and game: [EMAIL PROTECTED]:/home/ethant# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 74254050650219891272%/ mfs:24827 15855 1 15062 0%/tmp [EMAIL PROTECTED]:/home/ethant# cat /etc/fstab /dev/wd0a / ffs rw,noatime 1 1 swap /tmp mfs rw,-s=32768,nodev,nosuid,noexec 0 0 Nothing fancy. noatime is the only thing different from a normal install for me other than the fact that I split the filesystem into /, /usr, /tmp, /var, and /home on larger disks. Greg
Re: Problems with routing
On Thu, 15 Feb 2007 01:08:28 +, Jamie Penman-Smithson wrote: On 15/02/07, Stuart Henderson [EMAIL PROTECTED] wrote: I'm attempting to setup openbsd 4.0 as a router, the system has two interfaces, rl0 and rl1. It looks something like this (apologies if this looks really odd): router [x.x.58.129] --- router2: rl0 [x.x.58.130] router2: rl1 [x.x.58.140] --- Not so much odd as lacking information. Post ifconfig output instead. Presumably the OpenBSD box is 'router2', though you don't actually say. Yes, router2 is the OpenBSD box. That ain't gonna work. Your configuration of the two nics on router2 is wrong. My guess is that you have a routed subnet supplied by your ISP and that you have taken the first usable one (xx.xx.58.129) and used it on the LAN i/f of your (ADSL?) modem. Router 2 now gets .130 on its rl0 and that's fine but you have applied .140 to rl1 and both interfaces are in the same network: xx.xx.58.128/28. You cannot do that and expect routing to work in r2. 2 ways (maybe more possible but I don't have all day 8-) ) to get around it. 1 alias ALL of your IPs except .129 onto rl0 and then use RFC1918 addrs on rl1 and its attached hosts. You can then rdr or binat them to the correct addresses on rl0. 2 You can use a pair of RFC1918 IPs on the modem and rl0, static route the /28 to rl0, configure rl1 to use .129 and hang all (up to 13) hosts on a LAN there. Case 2 requires tricky NATting and pf rules but I have done it several times and it just works but your original post makes me think you'd need a few more clues first. So go with #1 for an easier life. Any replies/questions on list please. Offlist replies /dev/null Rod/ From the land down under: Australia. Do we look umop apisdn from up over?
Re: is there an install packages file list?
On 2/14/07, Greg Thomas [EMAIL PROTECTED] wrote: On 2/14/07, Bryan Irvine [EMAIL PROTECTED] wrote: I'm going to be installing on a soekris box (probably on flash media), and I'm trying to figure out what the bare minimum I need to install. Is there somewhere I can see what files are included in the base40.tgz, etc40.tgz etc... so I know what don't fill up the flash card at the start? They are going to be a pf firewall, and ipsec vpn (with one of them running poptop for roadwarriors). Any pitfalls I should watch out for on this? fstab options etc..? After reading many posts on misc about the reliability of CF and since 1 GB compact flash is cheap these days I didn't bother with any of the above and just did an install picking the sets that I needed, avoiding x*, comp, and game: [EMAIL PROTECTED]:/home/ethant# df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 74254050650219891272%/ mfs:24827 15855 1 15062 0%/tmp [EMAIL PROTECTED]:/home/ethant# cat /etc/fstab /dev/wd0a / ffs rw,noatime 1 1 swap /tmp mfs rw,-s=32768,nodev,nosuid,noexec 0 0 Nothing fancy. noatime is the only thing different from a normal install for me other than the fact that I split the filesystem into /, /usr, /tmp, /var, and /home on larger disks. Oh, yeah: [EMAIL PROTECTED]:/var# du -hs www 82.1M www And I don't know why my /usr is so much larger than Rod's: [EMAIL PROTECTED]:/# sudo du -hs /usr 369M/usr Greg
Re: OT? Is this bad news?
On 2/14/07, Marco S Hyman [EMAIL PROTECTED] wrote: Also, please educate me: couldn't a BSD driver be created by using the cleanroom approach? One person reads the GPL code, writes specs, another implements them? Or is this covered when people say reverse engineer? [...] Thanks for clearing that up Hannah, Neil, Rod, Darren, and Marco. I always see the bitching on here (usually leading to a license war) and never was entirely sure what the big deal was. -Nick
Presentacion - Consulta
El motivo de esta carta es la presentacisn de DIMARCOMP como posible proveedor de Hardware; avalan nuestra empresa mas de 10 aqos de experiencia en el rubro de la Informatica en sus diferentes aspectos. Representa marcas reconocidas como LG, Intel, Kingston, Genius, Codegen, SMC, Noganet, Energit, Asus, nos encontramos entre los Microsoft System Builders. Dimarcomp se desempeqa como Importador y tambiin Distribuidor Mayorista de Equipamiento para empresas, gremio y afines (Hardware y accesorios para PC). Si se encuentra interesado en conocernos azn mas (listas de precios, ofertas y consultas varias), quedo a su entera disposicisn. ATENCION: Como este mail es znicamente a modo de presentacisn llegara solamente UNA VEZ, si Ud. necesita recibir informacisn periodicamente responda este mail solicitandolo. Si por el contrario llega mas de una vez, por favor notificarlo y disculparme ante todo por la molestia que pudo haberle ocasionado. Los saluda Atte. Ventas - DIMARCOMP Alejandro Pavilaitis msn: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] tel: 4554 2800 - Int: 111
arpresolve: can't allocate llinfo
Hello all, My OpenBSD firewall is still randomly stopping routing packets and I still can't figure out why. :-( I made the suggested patch to if_ether.c, ut now I just get the following line in /var log messages: Feb 14 18:08:41 bytor /bsd: arpresolve: can't allocate llinfo for 192.168.1.1:no link address Symptoms: Firewall can ping the wifi router (to which ADSL modem is attached), but pinging anything beyond it fails. If I try to traceroute to some place beyond the router, it doesn't show the router as the first hop. (If it can ping the router, shouldn't it show up a the first hop on a traceroute?). Even though the firewall can ping the router, it cannot ping my laptop, even though the route to both goes out ral0. The laptop cannot ping the firewall either. I know the router is still working because my laptop can still access the internet through it once I reset the default gateway to the router instead of the firewall. IPv6 ssh connections form the laptop to the firewall stay active. Things is, arp -a and route -n show -inet show extactly the same thing whether the problem is currently in progress or everything is working perfectly. No NICs accidentally have addresses on the wrong segment. I had routed running, but stopping it has made no difference. Anybody have any ideas? [EMAIL PROTECTED] 1:03:58 [9]/etc arp -a bytor (192.168.0.1) at 00:0e:0c:bc:38:9d on em1 static xanadu (192.168.0.2) at 00:0e:0c:b9:4d:ed on em1 heechee.wireless (192.168.1.1) at 00:13:10:0e:0b:08 on ral0 snowdog.wireless (192.168.1.3) at 00:12:17:60:fe:40 on ral0 redbarchetta.wireless.fenris.cjb.net (192.168.1.191) at 00:18:de:20:4f:2e on ral0 bytor (192.168.16.1) at 00:0e:0c:b9:50:74 on em0 static snowdog (192.168.16.2) at 00:15:f2:e8:7f:51 on em0 [EMAIL PROTECTED] 1:04:03 [10]/etc route -n show -inet Routing tables Internet: Destination GatewayFlagsRefs UseMtu Interface default 192.168.1.1UGS16 188916 - ral0 127.0.0.1 127.0.0.1 UH 2 6049 33224 lo0 192.168.0/24 link#3 UC 20 - em1 192.168.0.1 00:0e:0c:bc:38:9d UHLc9 996889 - lo0 192.168.0.2 00:0e:0c:b9:4d:ed UHLc156064 - em1 192.168.1/24 link#4 UC 30 - ral0 192.168.1.1 00:13:10:0e:0b:08 UHLc2 3272 - ral0 192.168.1.3 00:12:17:60:fe:40 UHLc0 483 - ral0 192.168.1.191 00:18:de:20:4f:2e UHLc0 4587 - ral0 192.168.2/24 link#1 UC 00 - fxp0 192.168.16/24 link#2 UC 20 - em0 192.168.16.1 00:0e:0c:b9:50:74 UHLc0 50 - lo0 192.168.16.2 00:15:f2:e8:7f:51 UHLc5 392664 - em0 [EMAIL PROTECTED] 1:04:13 [11]/etc cat hostname.ral0 inet 192.168.1.2 255.255.255.0 192.168.1.255 nwid fenris nwkey 0x0A18135EB54723927B64AB65BC inet6 alias 2001:05c0:92cf:1::c0a8:0102 64 [EMAIL PROTECTED] 1:06:08 [12]/etc cat hostname.em0 inet 192.168.16.1 255.255.255.0 192.168.16.255 inet6 alias 2001:05c0:92cf:10::c0a8:1001 64 [EMAIL PROTECTED] 1:06:18 [13]/etc cat hostname.em1 inet 192.168.0.1 255.255.255.0 192.168.0.255 inet6 alias 2001:05c0:92cf:0::c0a8:0001 64 [EMAIL PROTECTED] 1:06:33 [14]/etc cat hostname.fxp0 inet 192.168.2.1 255.255.255.0 192.168.2.255 inet6 alias 2001:5c0:92cf:2::c0a8:0201 64
Re: mediawiki on chroot
On 2/14/07, Stuart Henderson [EMAIL PROTECTED] wrote: On 2007/02/14 21:55, atstake atstake wrote: I'm getting this error I understand that I need to symlink some file inside the chroot (/var/www) area but I'm not sure which file to be exact. I search previous misc@ archive but they seem a bit confusing. You probably didn't do the 'phpxs' after installing php5-mysql Mediawiki is working now. But this time there's a different kind of error. When I type http://mysite.com/mediawiki; it takes me to http://www/mediawiki/index.php/Main_Page; I need to type http://mysite.com/mediawiki/index.php/Main_Page; to get to my mediawiki and when I log in to mediawiki, create a file and try to _save_ it, it takes me to http://www/mediawiki/index.php/OpenBSD;. But eventually it _does_ save the file. Apache error_log shows: [error] PHP Warning: Unknown: open(/tmp//sess_gmmltgdpemd3sutt31mrivba34, O_RDWR) failed: Permission denied (13) in Unknown on line 0 [error] PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct () in Unknown on line Any kind of help would be appreciated.
