dhcpd problem with tftp-server-name option in 4.3-stable
My dhcp server is running amd64/4.3-stable, GENERIC kernel.
Clients on 192.168.250.0/23 use the tftp-server-name option. When
dhcpd starts, the first request from that subnet gets all parameters
correctly; all subsequent requests, whether from the same client or
other clients, receive all the supplied options correctly except the
tftp-server-name value; dhcpd either doesn't give the option or gives
the option value as null. Other options and the other subnets/ranges
work fine. Basically, dhcpd only gives out the tftp-server-name value
once, to the first customer.
I installed isc-dhcp-server-3.1.0 package to see if the problem
persisted. Using the identical (almost) dhcpd.conf below, everything
works fine with the ISC dhcpd. The only thing I added to dhcpd.conf
for isc-dhcp-server to work was the ddns-update-style ad-hoc;
parameter. Each subnet listed below corresponds to a separate physical
ethernet interface (no vlans, no IP aliases.)
---
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
#
authoritative;
ddns-update-style ad-hoc;
default-lease-time 86400;
max-lease-time 172800;
subnet 192.168.252.0 netmask 255.255.252.0 {
range 192.168.254.2 192.168.254.253;
option domain-name playsecond.com;
option subnet-mask 255.255.252.0;
option routers 192.168.253.1;
option netbios-name-servers 192.168.252.15;
option netbios-node-type 8;
option ntp-servers 192.168.253.1;
option domain-name-servers 192.168.252.11, 192.168.252.12,
192.168.253.51,
192.168.253.54;
}
subnet 192.168.249.0 netmask 255.255.255.0 {
range 192.168.249.100 192.168.249.110;
option subnet-mask 255.255.255.0;
option routers 192.168.249.1;
option ntp-servers 66.42.62.246, 84.16.227.204, 149.156.24.40,
200.80.18.131
;
option domain-name-servers 198.144.192.4, 206.13.28.12;
}
subnet 192.168.250.0 netmask 255.255.254.0 {
range 192.168.250.25 192.168.251.253;
option subnet-mask 255.255.254.0;
option tftp-server-name 192.168.250.11;
option domain-name-servers 192.168.252.11, 192.168.252.12;
option routers 192.168.250.1;
option ntp-servers 192.168.250.1;
}
---
-Glenn
Re: 4.2 xenocara make build problem
On Sun, Jun 8, 2008 at 9:32 PM, Jesus Sanchez [EMAIL PROTECTED] wrote: Hi, using 4.2. Today I downloaded the xenocara.tar.gz from ftp.openbsd.org and it seems to have a problem. I untared the source into /usr/src/xenocara don't go any further http://www.openbsd.org/faq/upgrade43.html#xenocaramove
OpenBSD 4.2 guest on Linux Host, run problem
Hi there, I found out that you have tested successfully OpenBSD 4.2 guest on qemu Linux, I have problems running OpenBSD 4.2 on Linux qemu and i have attached the result in this letter. Can you help me? Thank you in advance for your time. [EMAIL PROTECTED] virt]# ./run.sh Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory qemu: fatal: triple fault EAX=d083d000 EBX=0083f000 ECX= EDX=d08ff000 ESI=0083d000 EDI=008ff000 EBP= ESP= EIP=d0338bee EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00cf9300 CS =0008 00cf9f00 SS =0010 00cf9300 DS =0010 00cf9300 FS = GS = LDT= 8000 TR = 8000 GDT= 000439f8 0027 IDT= 00043760 027f CR0=e03f CR2=000437a0 CR3=0083f000 CR4= CCS=0030 CCD=d083ef64 CCO=SUBL FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= ./run.sh: line 3: 4776 Aborted qemu -m 256 ./openbsd42.img -net nic,vlan=0 -net user,vlan=0,hostname=foo
Re: Are there any Open Source / Free Software vt220 / vt320 / vt400 terminal emulators out there?
Hi, On Fri, Jun 6, 2008 at 6:33 PM, Jon [EMAIL PROTECTED] wrote: o;? I am referring to the old hardware dumb terminals, which had the vt320 standards etc. A client of mine uses a legacy database application that absolutely requires such an emulator (and is using Accuterm right now). A Free Software program that emulates these well enough and runs on GNU or BSD is what I'm looking for. Does the system support wyse terminal emulation? If so try comms/wy60. We used this at my old job after the green screens started dying. -- Best Regards Edd http://students.dec.bournemouth.ac.uk/ebarrett
Re: Are there any Open Source / Free Software vt220 / vt320 / vt400 terminal emulators out there?
On Fri, Jun 06, 2008 at 10:33:02AM -0700, Jon wrote: o;? I am referring to the old hardware dumb terminals, which had the vt320 standards etc. A client of mine uses a legacy database application Ehh, it's a bit rewriting history to call the vt line dumb terminals. vt terminals were considered pretty smart, acutully mroe or less defining the term smart terminal. That's still refelected in the termcap database: a dumb terminal has no random cursor movement, it more or less emulates a teletype. -Otto
Re: 4.2 xenocara make build problem
On Sun, Jun 8, 2008 at 1:32 PM, Jesus Sanchez [EMAIL PROTECTED] wrote: Hi, using 4.2. Today I downloaded the xenocara.tar.gz from ftp.openbsd.org and it seems to have a problem. I untared the source into /usr/src/xenocara, cleaned the /usr/xobj/* dir and set a DESTDIR. As root, I runed make bootstrap (no problem) make obj (no problem) make build (-- problem --) It have problems when compiling /usr/src/xenocara/lib/freetype You need to have /usr/X11R6/bin in your PATH to build Xenocara,
Re: OpenBSD 4.2 guest on Linux Host, run problem
This appears to be a qemu error and is probably best posted on the qemu-users mailing list. On Mon, Jun 9, 2008 at 2:13 PM, Boril Boyanov [EMAIL PROTECTED] wrote: Hi there, I found out that you have tested successfully OpenBSD 4.2 guest on qemu Linux, I have problems running OpenBSD 4.2 on Linux qemu and i have attached the result in this letter. Can you help me? Thank you in advance for your time. [EMAIL PROTECTED] virt]# ./run.sh Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory qemu: fatal: triple fault EAX=d083d000 EBX=0083f000 ECX= EDX=d08ff000 ESI=0083d000 EDI=008ff000 EBP= ESP= EIP=d0338bee EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00cf9300 CS =0008 00cf9f00 SS =0010 00cf9300 DS =0010 00cf9300 FS = GS = LDT= 8000 TR = 8000 GDT= 000439f8 0027 IDT= 00043760 027f CR0=e03f CR2=000437a0 CR3=0083f000 CR4= CCS=0030 CCD=d083ef64 CCO=SUBL FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= ./run.sh: line 3: 4776 Aborted qemu -m 256 ./openbsd42.img -net nic,vlan=0 -net user,vlan=0,hostname=foo
Re: small, random essay on performance tuning, was: remove....
On Sat, 2008-06-07 at 13:23 +0300, Lars Noodin wrote: It seems from the messages, and my limited experience, that many come to OpenBSD from other systems where messing with the kernel is both required and expected[1], that includes Linux and FreeBSD. [1] Case in point see AFS client problem in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/191353 Seems like the discussion that one points to ends with you just need to compile the OpenAFS kernel module, not the kernel. Try another case-in-point. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: 4.2 xenocara make build problem
Matthieu Herrb escribis: On Sun, Jun 8, 2008 at 1:32 PM, Jesus Sanchez [EMAIL PROTECTED] wrote: Hi, using 4.2. Today I downloaded the xenocara.tar.gz from ftp.openbsd.org and it seems to have a problem. I untared the source into /usr/src/xenocara, cleaned the /usr/xobj/* dir and set a DESTDIR. As root, I runed make bootstrap (no problem) make obj (no problem) make build (-- problem --) It have problems when compiling /usr/src/xenocara/lib/freetype You need to have /usr/X11R6/bin in your PATH to build Xenocara, thanks, but after adding that detail, the build process stucks in the same place. Here are the last error lines: *** Error code 1 Stop in /usr/src/xenocara/lib/freetype. *** Error code 1 Stop in /usr/src/xenocara/lib/freetype (line 28 of /usr/src/xenocara/lib/freetype/Makefile). *** Error code 1 Stop in /usr/src/xenocara/lib. *** Error code 1
Re: 4.2 xenocara make build problem
xavier brinon escribis: On Sun, Jun 8, 2008 at 9:32 PM, Jesus Sanchez [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, using 4.2. Today I downloaded the xenocara.tar.gz from ftp.openbsd.org http://ftp.openbsd.org and it seems to have a problem. I untared the source into /usr/src/xenocara don't go any further http://www.openbsd.org/faq/upgrade43.html#xenocaramove using 4.2, as the FAQ says, it's on /usr/src not /usr
Re: Are there any Open Source / Free Software vt220 / vt320 / vt400 terminal emulators out there?
Jon [EMAIL PROTECTED] wrote: I am referring to the old hardware dumb terminals, which had the vt320 standards etc. A client of mine uses a legacy database application that absolutely requires such an emulator (and is using Accuterm right The best VT220 emulator is the underappreciated xterm(1). For VT320 and later you are out of luck. -- Christian naddy Weisgerber [EMAIL PROTECTED]
Re: How to overwrite MSS value in SYN packets?
07.06.08, 21:04, Alexey Suslikov [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Now I tested wuth very simply topology: just 2 pc's and switch One OpenBSD another Linux with web server. Now I have only one line in my pf.conf: scrub all max-mss 1400 fragment reassemble This one-liner will not work unless you have corresponding pass rule in your pf.conf, so I highly suspect what you even have packet filter disabled. Do you have pf=YES in /etc/rc.conf.local? Yes. I have. bash-3.2# pfctl -sr scrub all no-df random-id max-mss 1400 fragment reassemble pass in quick all flags S/SA keep state pass out quick all flags S/SA keep state Also, topology you have will not route packets as you told us before. Yes. I made it simplie to understand. Now I have only one BSD as client ftching one file from linux box. And we don't really like linux tcpdumps here so very few will speak up and help. If you can't get OpenBSD box to work please provide OpenBSD tcpdump output. Ok. Here is openbsd tcpdump. But I still see len 1440 packets. 03:57:54.035986 192.168.133.200.9901 192.168.133.1.80: S [tcp sum ok] 1790495358:1790495358(0) win 16384 mss 1400,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3743718606 0 (ttl 64, id 55493, len 64) 03:57:54.036047 192.168.133.1.80 192.168.133.200.9901: S [tcp sum ok] 2480387518:2480387518(0) ack 1790495359 win 5792 mss 1460,sackOK,timestamp 343617 3743718606,nop,wscale 7 (DF) (ttl 64, id 0, len 60) 03:57:54.036080 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 1 win 16384 nop,nop,timestamp 3743718606 343617 (ttl 64, id 40579, len 52) 03:57:54.036210 192.168.133.200.9901 192.168.133.1.80: P 1:70(69) ack 1 win 16384 nop,nop,timestamp 3743718606 343617 (ttl 64, id 7424, len 121) 03:57:54.036257 192.168.133.1.80 192.168.133.200.9901: . [tcp sum ok] ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35838, len 52) 03:57:54.040971 192.168.133.1.80 192.168.133.200.9901: P 1:229(228) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35839, len 280) 03:57:54.040976 192.168.133.1.80 192.168.133.200.9901: . 229:1617(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35840, len 1440) 03:57:54.040979 192.168.133.1.80 192.168.133.200.9901: . 1617:3005(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35841, len 1440) 03:57:54.041009 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 1617 win 14768 nop,nop,timestamp 3743718606 343617 (ttl 64, id 64488, len 52) 03:57:54.041066 192.168.133.1.80 192.168.133.200.9901: . 3005:4393(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35842, len 1440) 03:57:54.041076 192.168.133.1.80 192.168.133.200.9901: . 4393:5781(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35843, len 1440) 03:57:54.041080 192.168.133.1.80 192.168.133.200.9901: . 5781:7169(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35844, len 1440) 03:57:54.041106 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 4393 win 11992 nop,nop,timestamp 3743718606 343617 (ttl 64, id 23140, len 52) 03:57:54.041158 192.168.133.1.80 192.168.133.200.9901: P 7169:8557(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35845, len 1440) 03:57:54.041163 192.168.133.1.80 192.168.133.200.9901: . 8557:9945(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35846, len 1440) 03:57:54.041166 192.168.133.1.80 192.168.133.200.9901: FP 9945:10469(524) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35847, len 576) 03:57:54.041189 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 7169 win 9216 nop,nop,timestamp 3743718606 343617 (ttl 64, id 19692, len 52) 03:57:54.041242 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 9945 win 6440 nop,nop,timestamp 3743718606 343617 (ttl 64, id 11042, len 52) 03:57:54.041292 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 10470 win 5916 nop,nop,timestamp 3743718606 343617 (ttl 64, id 19856, len 52) 03:57:54.041463 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 10470 win 16384 nop,nop,timestamp 3743718606 343617 (ttl 64, id 18257, len 52) 03:57:54.044006 192.168.133.200.9901 192.168.133.1.80: F [tcp sum ok] 70:70(0) ack 10470 win 16384 nop,nop,timestamp 3743718606 343617 (ttl 64, id 44491, len 52) 03:57:54.044058 192.168.133.1.80 192.168.133.200.9901: . [tcp sum ok] ack 71 win 46 nop,nop,timestamp 343618 3743718606 (DF) (ttl 64, id 0, len 52) - Alexey.
Re: How to overwrite MSS value in SYN packets?
On Mon, Jun 9, 2008 at 9:06 AM, B A [EMAIL PROTECTED] wrote: bash-3.2# pfctl -sr scrub all no-df random-id max-mss 1400 fragment reassemble pass in quick all flags S/SA keep state pass out quick all flags S/SA keep state Ok. Here is openbsd tcpdump. But I still see len 1440 packets. 03:57:54.035986 192.168.133.200.9901 192.168.133.1.80: S [tcp sum ok] 1790495358:1790495358(0) win 16384 mss 1400,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3743718606 0 (ttl 64, id 55493, len 64) 03:57:54.036047 192.168.133.1.80 192.168.133.200.9901: S [tcp sum ok] 2480387518:2480387518(0) ack 1790495359 win 5792 mss 1460,sackOK,timestamp 343617 3743718606,nop,wscale 7 (DF) (ttl 64, id 0, len 60) 03:57:54.036080 192.168.133.200.9901 192.168.133.1.80: . [tcp sum ok] ack 1 win 16384 nop,nop,timestamp 3743718606 343617 (ttl 64, id 40579, len 52) 03:57:54.036210 192.168.133.200.9901 192.168.133.1.80: P 1:70(69) ack 1 win 16384 nop,nop,timestamp 3743718606 343617 (ttl 64, id 7424, len 121) 03:57:54.036257 192.168.133.1.80 192.168.133.200.9901: . [tcp sum ok] ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35838, len 52) 03:57:54.040971 192.168.133.1.80 192.168.133.200.9901: P 1:229(228) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35839, len 280) 03:57:54.040976 192.168.133.1.80 192.168.133.200.9901: . 229:1617(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35840, len 1440) 03:57:54.040979 192.168.133.1.80 192.168.133.200.9901: . 1617:3005(1388) ack 70 win 46 nop,nop,timestamp 343617 3743718606 (DF) (ttl 64, id 35841, len 1440) You might want to read up on packet structures as this is working as expected. The header of a TCP packet is normally 40 bytes--so you're seeing a maximum MSS of 1400 bytes and an MTU of 1440 bytes.
snmp MIB variables
Hello, Reyk Floeter mentioned in his ONLamp interview (link below) that snmpd currently supports most of the SNMPv1/v2c MIBs, IP-MIB, BRIDGE-MIB, HOST-RESOURCES-MIB, IF-MIB, and the OPENBSD-SENSORS-MIB http://www.onlamp.com/pub/a/bsd/2008/04/29/puffy-and-the-crytonauts-whats-new-in-openbsd-43.html I have a 4.3 installation that lacks the vast majority of these MIBs. The most relevant for me is HOST-RESOURCES-MIB - 1.3.6.1.2.1.25.1. # snmpctl -n show mib | grep 1.3.6.1.2.1.25.1 # Are these MIBs planned releases, or is my installation missing something? Thanks in advance for the help. -HKS
Re: spamd sync question
Hi, I apologize to replying to myself. I am just trying to provide more info about my question so that maybe someone will be able to give an answer. 1) I wanted to run the new version of spamd (with the up to date sync protocol) without having to upgrade to CURRENT. I guess I can not or should not do it. 2) In my setup the two bridges that should be in sync are in front of MTAs with different IP addresses (different MX or different destionation domain address). So I wonder if it makes sense to sync both the greylists and whitelists, or only the whitelists. Thanks for any help. Regards, Jose. -- See Exclusive Videos: 10th Annual Young Hollywood Awards http://www.hollywoodlife.net/younghollywoodawards2008/
Re: Are there any Open Source / Free Software vt220 / vt320 / vt400 terminal emulators out there?
Christian Weisgerber wrote: The best VT220 emulator is the underappreciated xterm(1). The s/underappreciated/under appreciated terminal know as xterm, would be more appreciated if they modernized it a little... Anyone who peddles a terminal emulator without pseudo transparency should be locked up indefinitely. :-) -Nix Fan.
Re: Are there any Open Source / Free Software vt220 / vt320 / vt400 terminal emulators out there?
The best VT220 emulator is the underappreciated xterm(1). The s/underappreciated/under appreciated terminal know as xterm, would be more appreciated if they modernized it a little... Anyone who peddles a terminal emulator without pseudo transparency should be locked up indefinitely. :-) On-glass character remainance is not to be compared with pseudo transparency. Spoiled brats. Grumpy
My Book Studio Edition II problem
Hello, I'm attempting to get a Western Digital My Book Studio Edition II working with my OpenBSD 4.2 machine. The drive is formatted for FAT32 and functions while the machine is booted into Windows. I have it attached via USB, but when I attempt to mount the drive, it fails: % sudo mount -t msdos /dev/sd0i /mnt mount_msdos: /dev/sd0i on /mnt: Cannot allocate memory Similarly, fdisk and disklabel both fail. % fdisk sd0 fdisk: DIOCGDINFO: Input/output error fdisk: Can't get disk geometry, please use [-chs] to specify. % fdisk -c 16383 -h 16 -s 63 sd0 fdisk: DIOCGDINFO: Input/output error Disk: sd0 geometry: 16383/16/63 [16514064 Sectors] Offset: 0 Signature: 0x0 Starting EndingLBA Info: #: id C H S - C H S [ start:size ] 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused % disklabel sd0 disklabel: ioctl DIOCGDINFO: Input/output error Does anyone have any ideas on how I can get this working? I've included a dmesg and a usbdevs bellow. Many thanks, -Larry OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor 1.70GHz (GenuineIntel 686-class) 600 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2 real mem = 804220928 (766MB) avail mem = 769486848 (733MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/02/06, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (61 entries) bios0: vendor IBM version 1RETDPWW (3.21 ) date 06/02/2006 bios0: IBM 2378RRU apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 97% apm0: AC off, battery charge high, estimated 1:22 hours apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xfd6e0/0x920 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdea0/272 (15 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #6 is the last bus bios0: ROM list: 0xc/0x1 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 0xe/0x1 cpu0 at mainbus0 cpu0: Enhanced SpeedStep 600 MHz (988 mV): speeds: 1700, 1400, 1200, 1000, 800, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82855PE Hub rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82855PE AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility M7 LW rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29 function 0 Intel 82801DB USB rev 0x01: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801DB USB rev 0x01: irq 11 uhci2 at pci0 dev 29 function 2 Intel 82801DB USB rev 0x01: irq 11 ehci0 at pci0 dev 29 function 7 Intel 82801DB USB rev 0x01: irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0: Intel EHCI root hub, rev 2.00/1.00, addr 1 ppb1 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x81 pci2 at ppb1 bus 2 cbb0 at pci2 dev 0 function 0 TI PCI4520 CardBus rev 0x01: irq 11 cbb1 at pci2 dev 0 function 1 TI PCI4520 CardBus rev 0x01: irq 11 em0 at pci2 dev 1 function 0 Intel PRO/1000MT (82540EP) rev 0x03: irq 11, address 00:11:25:86:54:f3 iwi0 at pci2 dev 2 function 0 Intel PRO/Wireless 2200BG rev 0x05: irq 11, address 00:12:f0:12:94:ba cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 cardslot1 at cbb1 slot 1 flags 0 cardbus1 at cardslot1: bus 6 device 0 cacheline 0x8, lattimer 0xb0 pcmcia1 at cardslot1 ichpcib0 at pci0 dev 31 function 0 Intel 82801DBM LPC rev 0x01: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 82801DBM IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: HTS726060M9AT00 wd0: 16-sector PIO, LBA, 57231MB, 117210240 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: MATSHITA, UJDA755yDVD/CDRW, 1.72 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 Intel 82801DB SMBus rev 0x01: irq 11 iic0 at ichiic0 auich0 at pci0 dev 31 function 5 Intel 82801DB AC97 rev 0x01: irq 11, ICH4 AC97 ac97: codec id 0x41445374 (Analog Devices AD1981B) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auich0 Intel 82801DB Modem rev 0x01 at pci0 dev 31 function 6 not configured usb1 at uhci0: USB revision 1.0 uhub1 at usb1: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb2 at uhci1: USB
Re: remove any unwanted devices from the kernel.
Nick Holland wrote: The biggest reasons to do this are because you have too much time on your hands, and you want to impress people by having things break, then you swoop in to rescue everyone from your fabricated disaster. Actually I think most people do it because you are tought to do so with both Linux and FreeBSD. Just like people who come from a windows environment try to download a package from the providers website rather than install the package provided by the OS/Distro/whatever. # Han
libstdc++.so.44.1 missing in latest snapshot
Hi, as mentioned in the title libstdc++.so is not in the iso, nor in comp43. Fulvio
Re: Are there any Open Source / Free Software vt220 / vt320 / vt400 terminal emulators out there?
gnome-terminal, and compiz with the blur effect heavily applied, no scrollbar and window decorations which cast large shadows and match the transparency and color of your terminal atop a very busy desktop background, is where it's at. On Mon, 2008-06-09 at 11:42 -0700, Unix Fan wrote: Christian Weisgerber wrote: The best VT220 emulator is the underappreciated xterm(1). The s/underappreciated/under appreciated terminal know as xterm, would be more appreciated if they modernized it a little... Anyone who peddles a terminal emulator without pseudo transparency should be locked up indefinitely. :-) -Nix Fan.
Re: libstdc++.so.44.1 missing in latest snapshot
On Mon, Jun 09, 2008 at 05:34:51PM +0200, fulvio ciriaco wrote: Hi, as mentioned in the title libstdc++.so is not in the iso, nor in comp43. Fulvio $ tar ztf base43.tgz | grep libstdc ./usr/lib/libstdc++.so.44.1 Which snapshot on which arch do you use? Snapshot from June 7th here on sparc64. Regards, Markus
Re: Lost sensors info when upgraded from 4.2 to 4.3
On Thursday 05 June 2008 15.42.37 you wrote: On 2008-06-05, Per-Olov Sjvholm [EMAIL PROTECTED] wrote: I did an upgrade (read reinstall) last week on a Dell PE830 server from OpenBSD 4.2 to 4.3. It is a 4.3 RELEASE std install, but a stable update of kernel and userland from May 29. The sensors worked ok in 4.2. In 4.3 it looks like this where the sensor info is null.. They were probably from ipmi before, this was knocked out of GENERIC until bad interactions with acpi on some machine are fixed. See http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/conf/GENERIC r1.589. A, I see... dmesg says.. ipmi at mainbus0 not configured and.. adt0 at iic0 addr 0x2e: lm96000 rev 0x68 So the sensors show up but are unusable and shows zero? So I should not expect these to be usable in 4.3 even with a stable update? Do I have to track the cvs tree and go to current when fixed if I want these sensors? Or fix the problem myself ;-) Did not see any problem with them on 4.2. Are there any more info than what can be seen on r1.589 of GENERIC? If they worked perfect on 4.2. Is it likely they will cause trouble now on the same hardware? (I think of enabling this in GENERIC) Thanks /Per-Olov -- GPG keyID: 4DB283CE GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE GPG key: http://keyserv.nic-se.se:11371/pks/lookup?op=getsearch=0xCFB4BBE94DB283CE
Re: Zeroconf / Howl Problems.
On Mon, Jun 9, 2008 at 12:31 PM, Jeremy Karlson [EMAIL PROTECTED] wrote: Starting Howl in debug mode seems to indicate that it's sending the multicast packets to somewhere I can't explain - 224.0.0.251. 224.0.0.251 is the multicast address for mDNS.
nmeaattach(8) removed in -current, superseeded by ldattach(8)
If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. The nmeaattach command has been removed in -current, so has the nmeaattach_flags option in /etc/rc.conf (replaced with ldattach_flags). Please note that ldattach(8) has a slightly different synopsis than nmeaattach(8) had: nmeaattach cuaU0 becomes ldattach nmea cuaU0
Re: How to overwrite MSS value in SYN packets?
Hello everybody, I fully agree with Daniel, here we've correct values. May i suggest (in order to clarify situation) we use the same host/IP during exchanges (because it's a bit difficult to diagnose what's happening0) :-) Precedent message was between OpenBSD/Linux (IP were 10.137.8.104 - 10.137.9.55) and there were bad mss 10.137.8.104.30290 10.137.9.55.80: S 568783555:568783555(0) win 16384 mss 1460 Now we're using not only OpenBSD's tcpdump but obviously different IPs (and good mss) 192.168.133.200.9901 192.168.133.1.80: S [tcp sum ok] 1790495358:1790495358(0) win 16384 mss 1400 So, are they the same hosts (with just different IP) ? Please note i may try to reproduce a lot of things, i just need to know about them... :-) With regards, Jean-Philippe. On Mon, 9 Jun 2008 10:54:44 -0600 Daniel Melameth [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 9:06 AM, B A [EMAIL PROTECTED] wrote: bash-3.2# pfctl -sr scrub all no-df random-id max-mss 1400 fragment reassemble pass in quick all flags S/SA keep state pass out quick all flags S/SA keep state Ok. Here is openbsd tcpdump. But I still see len 1440 packets. 03:57:54.035986 192.168.133.200.9901 192.168.133.1.80: S [tcp sum ok] 1790495358:1790495358(0) win 16384 mss 1400,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3743718606 0 You might want to read up on packet structures as this is working as expected. The header of a TCP packet is normally 40 bytes--so you're seeing a maximum MSS of 1400 bytes and an MTU of 1440 bytes.
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
On Mon, Jun 9, 2008 at 3:36 PM, Marc Balmer [EMAIL PROTECTED] wrote: If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. Thanks Marc for passing on this information. Can you describe in short why this change was made?
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
* James Hartley wrote: On Mon, Jun 9, 2008 at 3:36 PM, Marc Balmer [EMAIL PROTECTED] wrote: If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. Thanks Marc for passing on this information. Can you describe in short why this change was made? we do not want more than one utility to attach line disciplines. and ldattach(8) superseedes nmeaattach(8). there is no need to keep the latter.
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
On Mon, 9 Jun 2008, James Hartley wrote: On Mon, Jun 9, 2008 at 3:36 PM, Marc Balmer [EMAIL PROTECTED] wrote: If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. Thanks Marc for passing on this information. Can you describe in short why this change was made? ldattach is more generic; it can handle all existing and future line discliplines
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
On Mon, Jun 9, 2008 at 3:36 PM, Marc Balmer [EMAIL PROTECTED] wrote: If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. Thanks Marc for passing on this information. Can you describe in short why this change was made? No need to have two ways to do one thing.
Re: Zeroconf / Howl Problems.
On Mon, Jun 9, 2008 at 12:31 PM, Jeremy Karlson [EMAIL PROTECTED] wrote: 224.0.0.251 is the multicast address for mDNS. That could be correct. Honestly, I'm not sure. I believe you. :-P But that's not the weird part to me. [howl] error sending packet to 224.0.0.251 (23126) [assert] error: 64 (Host is down) That's the weird part. I'm admittedly not a networking guy, but I don't see how a multicast can fail like this, especially when it's not directed at any specific host. Care to enlighten me? -- Jeremy
restricting snmpd access on 4.3 to a single IP
Hi, I've read the man page for snmpd.conf, but didn't see mention of a way to restrict snmpd to only respond to gets and sets from one ip address. Is there a way to do this in snmpd.conf or should I look to a pf solution? Thanks, JL
Re: restricting snmpd access on 4.3 to a single IP
On Mon, Jun 9, 2008 at 3:23 PM, Jurvis LaSalle [EMAIL PROTECTED] wrote: Hi, I've read the man page for snmpd.conf, but didn't see mention of a way to restrict snmpd to only respond to gets and sets from one ip address. Is there a way to do this in snmpd.conf or should I look to a pf solution? are you referring to the net-snmp package or the base snmpd daemon?
Re: Zeroconf / Howl Problems.
did you check /etc/netstart? there's a blurb in there about configuring a multicast host. No I didn't. I'm pretty sure that's exactly what I'm looking for. Thanks a lot for the quick and helpful response. -- Jeremy
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
On Mon, Jun 9, 2008 at 3:53 PM, James Hartley [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 3:36 PM, Marc Balmer [EMAIL PROTECTED] wrote: If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. Thanks Marc for passing on this information. Can you describe in short why this change was made? For those interested, Marc has more information posted on undeadly.com. Thanks again, Marc!
Re: Lost sensors info when upgraded from 4.2 to 4.3
On 6/9/08, Per-Olov Sjvholm [EMAIL PROTECTED] wrote: On Thursday 05 June 2008 15.42.37 you wrote: On 2008-06-05, Per-Olov Sjvholm [EMAIL PROTECTED] wrote: I did an upgrade (read reinstall) last week on a Dell PE830 server from OpenBSD 4.2 to 4.3. It is a 4.3 RELEASE std install, but a stable update of kernel and userland from May 29. The sensors worked ok in 4.2. In 4.3 it looks like this where the sensor info is null.. They were probably from ipmi before, this was knocked out of GENERIC until bad interactions with acpi on some machine are fixed. See http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/conf/GENERIC r1.589. A, I see... dmesg says.. ipmi at mainbus0 not configured and.. adt0 at iic0 addr 0x2e: lm96000 rev 0x68 So the sensors show up but are unusable and shows zero? So I should not expect these to be usable in 4.3 even with a stable update? Do I have to track the cvs tree and go to current when fixed if I want these sensors? Or fix the problem myself ;-) or just config -ef /bsd and turn ipmi back on.
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
On Mon, Jun 09, 2008 at 04:52:24PM -0700, James Hartley wrote: For those interested, Marc has more information posted on undeadly.com. Ahem. http://undeadly.org/ Thanks again, Marc! Indeed. :) -ME
Re: Zeroconf / Howl Problems.
On Mon, 9 Jun 2008, Jeremy Karlson wrote: Has anyone had any success setting up Howl (Zeroconf) on OpenBSD 4.3. I've done a lot of Googling and read the (minimal) docs, but I can't get it working. I'm unable to determine if I'm doing something incorrectly, or if it is a problem with Howl, or something else. I'm looking for suggestions on where to start. IIRC, multicast processing must be explicitly enabled. Have you done that? Dave Background: Fresh install of OpenBSD 4.3 i386 within the last couple of days. All software is installed from packages. I'm using a Linksys EG1032v3 network card with the RE driver. Starting Howl in debug mode seems to indicate that it's sending the multicast packets to somewhere I can't explain - 224.0.0.251. # ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:14:bf:54:f7:df groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet6 fe80::214:bfff:fe54:f7df%re0 prefixlen 64 scopeid 0x1 inet 192.168.2.11 netmask 0xff00 broadcast 192.168.2.255 # cat /etc/mDNSResponder.conf Galactica _ssh._tcp local. 22 # mDNSResponder -d -f /etc/mDNSResponder.conf [howl] registered interface 192.168.2.11 (23126) [howl] starting up... (23126) [howl] registered Galactica (23126) [assert] error: 64 (Host is down) [assert] where: socket.c, sw_socket_udp_really_sendto, line: 969 [howl] error sending packet to 224.0.0.251 (23126) [assert] error: 64 (Host is down) [assert] where: socket.c, sw_socket_udp_really_sendto, line: 969 [howl] error sending packet to 224.0.0.251 (23126) [assert] error: 64 (Host is down) [assert] where: socket.c, sw_socket_udp_really_sendto, line: 969 ... Thanks. -- Jeremy -- Dave Anderson [EMAIL PROTECTED]
Re: nmeaattach(8) removed in -current, superseeded by ldattach(8)
So, this is not perl? :-) Actually, I heard another OS can have 5 or more APIs to do the same thing (say, listing a directory) because one team wants it this way, and another doesn't. On 6/9/08, Theo de Raadt [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 3:36 PM, Marc Balmer [EMAIL PROTECTED] wrote: If you are using a GPS device with nmeaattach(8), please switch to ldattach(8) now. Thanks Marc for passing on this information. Can you describe in short why this change was made? No need to have two ways to do one thing. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related
Re: Zeroconf / Howl Problems.
On 2008-06-09, Jeremy Karlson [EMAIL PROTECTED] wrote: Has anyone had any success setting up Howl (Zeroconf) on OpenBSD 4.3. I've done a lot of Googling and read the (minimal) docs, but I can't get it working. I'm unable to determine if I'm doing something incorrectly, or if it is a problem with Howl, or something else. I'm looking for suggestions on where to start. Did you configure your routing table to allow multicast? See the multicast_* options in rc.conf(5)
Re: news about BSD world
On Fri, May 16, 2008 at 4:54 AM, Katarzyna Kaczor [EMAIL PROTECTED] wrote: Hi Guys, Would you like to reach to the large audience of BSD Magazine? I am happy to announce that we started News Section on BSD Magazine website. In this bookmark you can place news, press releases, latest and upcoming BSD events announcements and other information precious for BSD Community. If you want to add your news, please contact me directly at [EMAIL PROTECTED] Thanks a lot :) Hi, What ever happened with this? Any progress or status updates?
