Re: spamd-setup fails from cron
> > you could be hitting the 'zero minute rush', where world+dog tries to > > connect simultaneously. try shifting to a few minutes past the hour > and > > see if that helps. > > > > Please avoid 15 minutes past the hour ;-) Years ago I've been toying with the idea of having a flag for random-delay mode in spamd-setup. So the default cronjob is still set at zero minute, but spamd-setup then waits for random amount of minutes before hitting the server. You lose the predictability of when your blacklists get updated but it spreads the load on the infrastructure without involving the human factor (the lazy admin that uncomments the cron entry without changing the time). Mitja
Re: GENERIC.MP cold reboot at savecore
sthen@ just commited a backported fix for this to 4.8-stable for i386 and amd64, it fixed my Dell PE T110 that experienced the same symptoms. Update your 4.8-stable source tree and try again.
Re: kernel pppoe performance problems
First of all, do not reply to mails sent in private on a public list, it's impolite and will expose my email address to more spam. Second, man 4 pppoe says: MTU/MSS ISSUES Problems can arise on machines with private IPs connecting to the Inter- net via a machine running both Network Address Translation (NAT) and pppoe. Standard Ethernet uses a Maximum Transmission Unit (MTU) of 1500 bytes, whereas PPPoE mechanisms need a further 8 bytes of overhead. This leaves a maximum MTU of 1492. pppoe sets the MTU on its interface to 1492 as a matter of course. However, machines connecting on a private LAN will still have their MTUs set to 1500, causing conflict. While pppoe(8) has an internal option, ``mssfixup'', which is enabled by default and takes care of this, pppoe users have to rely on other meth- ods. Using a packet filter, the Maximum Segment Size (MSS) can be set (clamped) to the required value. The following rule in pf.conf(5) would set the MSS to 1440: match on pppoe0 scrub (max-mss 1440) Although in theory the maximum MSS over a PPPoE interface is 1452 bytes, 1440 appears to be a safer bet. Note that setting the MSS this way can have undesirable effects, such as interfering with the OS detection fea- tures of pf(4). which is definitely not "the same as man 8 pppoe". > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Matt > Schwartz > Sent: Wednesday, July 14, 2010 10:42 PM > To: misc@openbsd.org > Subject: Re: kernel pppoe performance problems > > Hi. I don't see that option available for kernel pppoe. I see it for a > userland version. man 4 pppoe shows the same as man 8 pppoe. > > > > On Jul 14, 2010, at 1:25 PM, Mitja MuE>eniD > wrote: > > > Sounds like you didn't clamp the MSS, see man 4 pppoe towards the end. It's > > not a performance problem, but a misconfiguration one. > > > >> -Original Message- > >> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > > Matt > >> S > >> Sent: Wednesday, July 14, 2010 10:16 PM > >> To: misc@openbsd.org > >> Subject: kernel pppoe performance problems > >> > >> Hello All, > >> > >> I want to try to use pppoe with kernel ppp in an attempt to improve > >> performance. So, I have a pppoe0 device configured and connection > >> established properly. The box that runs kernel pppoe is obviously my > >> gateway machine. If I am on the gateway machine, performance is decent. > > If > >> I am on one of my other boxes, performance really drops to the point of > >> dialup. I made certain to rm -f /etc/mygate as one wiki suggested but it > >> had no effect. If I use userland pppoe, I don't have this problem so I > >> think that both my NIC cards are okay. The nic card connected to my DSL > >> modem is bge0 and the nic for my home network is em0. My home network is > >> 10.40.60.0/24. I know I have NAT correctly configured because I can ping > >> google.com from one of the other boxes. Do you have any hints as to how I > >> can troubleshoot this further? Below is my configuration for the > >> hostname.pppoe0 : > >> > >> inet 0.0.0.0 255.255.255.255 NONE pppoedev bge0 authproto pap authname > >> "" authkey "" up > >> dest 0.0.0.1 > >> !/sbin/route add default 0.0.0.1 > >> > >> > >> Thank you, > >> Matt
Re: Why I left OpenBSD
> Please, someone do an image macro. "I'm in ur router, remappin' yar keyz" Here you are: http://cheezburger.com/View/3620602624 (improved spelling checked through the awesome http://speaklolcat.com/ service). Liek it? :) Mitja
Re: heads up - softraid metadata change
Don't thank me, I had nothing to do with it - just reporting the good news :) All the thanks and kudos go to Joel, Marco and everybody who's ever worked on softraid(4). Mitja > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of J.C. > Roberts > Sent: Friday, March 26, 2010 8:11 PM > To: Mitja MuE>eniD > Cc: misc@openbsd.org > Subject: Re: heads up - softraid metadata change > > On Fri, 26 Mar 2010 18:31:59 +0100 Mitja MuE>eniD > > wrote: > > > Joel Sing (jsing@) has just commited to -current a softraid update > > that bumps the softraid metadata version - see the commit mail and > > the brief article on Undeadly. The new kernel will not assemble the > > existing softraid volumes, so special caution is required BEFORE > > upgrading your -current kernel or moving to next snapshot. > > > > http://www.openbsd.org/faq/current.html#20100326 > > > > http://marc.info/?l=openbsd-cvs&m=126960262412653&w=2 > > > > http://www.undeadly.org/cgi?action=article&sid=20100326172808 > > > > > > Mitja (looking forward to more softraid goodies! :) > > > > > Excellent! --It seems we're moving closer to bootable softraid. > > Thanks Mitja, Joel, and Marco. > > jcr
heads up - softraid metadata change
Joel Sing (jsing@) has just commited to -current a softraid update that bumps the softraid metadata version - see the commit mail and the brief article on Undeadly. The new kernel will not assemble the existing softraid volumes, so special caution is required BEFORE upgrading your -current kernel or moving to next snapshot. http://www.openbsd.org/faq/current.html#20100326 http://marc.info/?l=openbsd-cvs&m=126960262412653&w=2 http://www.undeadly.org/cgi?action=article&sid=20100326172808 Mitja (looking forward to more softraid goodies! :)
New OpenOffice.org port build box needed
A few days ago Robert Nagy (the OpenOffice.org port maintainer) added his request for a build box to www.openbsd.org/want.html. OpenOffice.org 3 is a huge port to build and maintain, and a single build takes over 12 hours on the machine that Robert currently has and cannot afford to run anymore due to electricity costs. A machine with a modern quad-core CPU would cut the build time in half or less, thus making Robert's work of bringing you a prebuilt and working OpenOffice.org package much simpler. He also got an offer for free hosting of the build machine, but the caveat is that it has to be in a 1U rack mount form. By helping Robert get a new rackmount server both issues (the build time and the cost of running) will be much improved, which will allow him to put more effort in maintaining the port. An entry-level rack server may look expensive, but considering the price of commercial office suites, such a machine does not cost more than a few commercial licences. If you can donate towards the purchase of this build machine, please contact rob...@openbsd.org or make a Paypal donation directly to his e-mail. Since the initial call for donations on Undeadly ( http://www.undeadly.org/cgi?action=article&sid=20090221214700&mode=expanded&; count=2 ), almost half of the required funds have already been received. So please step forward and help the developer get the tools for his work! Thank you, Mitja
Re: Problem with current i386 snapshot
Same here on a Thinkpad x31.
Mitja
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Emilio Perea
> Sent: Sunday, August 03, 2008 6:29 AM
> To: misc@openbsd.org
> Subject: Problem with current i386 snapshot
>
> This build seems to go into an endless reboot cycle, rebooting before
> anything shows up in the console of a Soekris net4801. The previous
> snapshot (build #1004) works fine. Unfortunately I have
> nothing to show
> for it as far as filing a proper bug report. BIOS screen followed by
> the changing console to com0 message followed by the BIOS screen etc.
>
> Problem build:
> OpenBSD 4.4-beta (GENERIC) #1010: Sat Aug 2 12:39:46 MDT 2008
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
>
> Last working version dmesg:
> OpenBSD 4.4-beta (GENERIC) #1004: Thu Jul 31 00:42:16 MDT 2008
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by National Semi ("Geode
> by NSC" 586-class) 267 MHz
> cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
> cpu0: TSC disabled
> real mem = 133787648 (127MB)
> avail mem = 120946688 (115MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 20/80/03, BIOS32 rev. 0
> @ 0xf7840
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc8000/0x9000
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
> sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq 10, address 00:00:24:c2:9e:30
> nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
> sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq 10, address 00:00:24:c2:9e:31
> nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
> sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq 10, address 00:00:24:c2:9e:32
> nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
> gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
> gpio0 at gscpcib0: 64 pins
> "NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured
> pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01:
> DMA, channel 0 wired to compatibility, channel 1 wired to
> compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 4-sector PIO, LBA, 1953MB, 4001760 sectors
> wd0(pciide0:0:0): using PIO mode 4
> geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev
> 0x00: iid 6 revision 3 wdstatus 0
> ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev
> 0x08: irq 11, version 1.0, legacy support
> isa0 at gscpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0:
> spkr0 at pcppi0
> nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
> gpio1 at nsclpcsio0: 29 pins
> gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0 "Compaq OHCI root hub" rev 1.00/1.00 addr 1
> biomask fbe5 netmask ffe5 ttymask
> softraid0 at root
> root on wd0a swap on wd0b dump on wd0b
Re: note for faq, maybe
Yes, I can confirm that. I too got bitten by it before and I was considering proposing a patch for upgradeXX.html, but I got sidetracked. Mitja > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Marc Balmer > Sent: Thursday, July 10, 2008 3:55 PM > To: [EMAIL PROTECTED] > Cc: misc@openbsd.org > Subject: note for faq, maybe > > if you use pppoe(4) for internet, and want to do a remote > update from 4.2 to 4.3, over said pppoe(4) link, then the > normal update procedure will not work, because the 4.3 > kernel and the 4.2 ifconfig binary can not work together. > > after rebooting the new 4.3 bsd kernel, the network will > not be configure and you will walk/drive to the system (just > like I did today). > > so, brefore rebooting to 4.3, at least unpack the 4.3 ifconfig > binary from base43.tgz > > - Marc
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Harald Dunkel > Sent: Monday, June 30, 2008 9:17 AM > To: [EMAIL PROTECTED] > Cc: Misc OpenBSD > Subject: Re: isakmpd -- NCP IPsec client: peer proposed > invalid phase 2 IDs > > Hi Prabhu, > > I do get a connection for > > ike passive esp from 192.168.5.0/31 to 192.168.1.249 > > but not for > > ike passive esp from 192.168.5.1 to 192.168.1.249 > > (192.168.1.249 is the remote Windows laptop running NCP IPsec client.) > > So I doubt that this is a problem of aes vs 3des. AFAICS the problem > is that isakmpd doesn't accept the proposal packet with > > : > payload: ID len: 12 type: IPV4_ADDR = 192.168.1.249 > payload: ID len: 16 type: IPV4_ADDR_SUBNET = > 192.168.5.1/255.255.255.255 [ttl 0] (id 1, len 248) > : > > If I setup an IPsec tunnel between 2 OpenBSD hosts, then the > proposal packet says > > : > payload: ID len: 12 type: IPV4_ADDR = 192.168.5.3 > payload: ID len: 12 type: IPV4_ADDR = 192.168.5.1 [ttl > 0] (id 1, len 312) > : > > which seems to be fine for isakmpd. It is not a problem within isakmpd, it will accept IPV4_ADDR_SUBNET of size /32. As I already explained to you in a private mail, ipsecctl will export both 192.168.1.249 and 192.168.1.249/32 into IPV4_ADDR=192.168.1.249 while your windows client is sending IPV4_ADDR_SUBNET for 192.168.1.249/32, and this will not match. I have looked into changing this ipsecctl's behaviour but I can't find a clean way to do it. > > The questions are: > > Does NCP's IPsec client violate some RFC? > Can isakmpd adjusted to accept "IPV4_ADDR_SUBNET" in the proposal > packet, if this is fine with the RFCs? Since it's not an isakmpd's problem but a problem in ipsecctl parsing the config for isakmpd, you can always use the old-style isakmpd.conf config. Or see if your windows client can define a different destination type. > > > Regards > > Harri Mitja
more pci ids
Found in a Dell T300, verified through pciids.sourceforge.net Mitja === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1360 diff -u -r1.1360 pcidevs --- pcidevs 20 May 2008 08:23:18 - 1.1360 +++ pcidevs 21 May 2008 18:32:37 - @@ -2441,6 +2441,22 @@ product INTEL TURBO_MEMORY 0x444e Turbo Memory product INTEL 80960RD 0x5200 i960 RD PCI-PCI product INTEL PRO_100_SERVER 0x5201 PRO 100 Server +product INTEL 5100_HB 0x65c0 5100 Host +product INTEL 5100_PCIE_2 0x65e2 5100 PCIE +product INTEL 5100_PCIE_3 0x65e3 5100 PCIE +product INTEL 5100_PCIE_4 0x65e4 5100 PCIE +product INTEL 5100_PCIE_5 0x65e5 5100 PCIE +product INTEL 5100_PCIE_6 0x65e6 5100 PCIE +product INTEL 5100_PCIE_7 0x65e7 5100 PCIE +product INTEL 5100_FSB 0x65f0 5100 FSB +product INTEL 5100_RESERVED_1 0x65f1 5100 Reserved +product INTEL 5100_RESERVED_2 0x65f3 5100 Reserved +product INTEL 5100_DDR 0x65f5 5100 DDR +product INTEL 5100_DDR2 0x65f6 5100 DDR +product INTEL 5100_PCIE_23 0x65f7 5100 PCIE +product INTEL 5100_PCIE_45 0x65f8 5100 PCIE +product INTEL 5100_PCIE_67 0x65f9 5100 PCIE +product INTEL 5100_PCIE_47 0x65fa 5100 PCIE product INTEL IOAT_SCNB0x65ff I/OAT SCNB product INTEL 82371SB_ISA 0x7000 82371SB ISA product INTEL 82371SB_IDE 0x7010 82371SB IDE Before: pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x65c0 rev 0x90 ppb0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x65f7 rev 0x90: apic 4 int 16 (irq 0) ppb1 at pci0 dev 3 function 0 vendor "Intel", unknown product 0x65e3 rev 0x90 ppb2 at pci0 dev 4 function 0 vendor "Intel", unknown product 0x65e4 rev 0x90: apic 4 int 16 (irq 0) ppb3 at pci0 dev 5 function 0 vendor "Intel", unknown product 0x65e5 rev 0x90: apic 4 int 16 (irq 0) ppb4 at pci0 dev 6 function 0 vendor "Intel", unknown product 0x65f9 rev 0x90: apic 4 int 16 (irq 0) ppb5 at pci0 dev 7 function 0 vendor "Intel", unknown product 0x65e7 rev 0x90 pchb1 at pci0 dev 16 function 0 vendor "Intel", unknown product 0x65f0 rev 0x90 pchb2 at pci0 dev 16 function 1 vendor "Intel", unknown product 0x65f0 rev 0x90 pchb3 at pci0 dev 16 function 2 vendor "Intel", unknown product 0x65f0 rev 0x90 pchb4 at pci0 dev 17 function 0 vendor "Intel", unknown product 0x65f1 rev 0x90 pchb5 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x65f3 rev 0x90 pchb6 at pci0 dev 21 function 0 vendor "Intel", unknown product 0x65f5 rev 0x90 pchb7 at pci0 dev 22 function 0 vendor "Intel", unknown product 0x65f6 rev 0x90 After: pchb0 at pci0 dev 0 function 0 "Intel 5100 Host" rev 0x90 ppb0 at pci0 dev 2 function 0 "Intel 5100 PCIE" rev 0x90 ppb1 at pci0 dev 3 function 0 "Intel 5100 PCIE" rev 0x90 ppb2 at pci0 dev 4 function 0 "Intel 5100 PCIE" rev 0x90 ppb3 at pci0 dev 5 function 0 "Intel 5100 PCIE" rev 0x90 ppb4 at pci0 dev 6 function 0 "Intel 5100 PCIE" rev 0x90 ppb5 at pci0 dev 7 function 0 "Intel 5100 PCIE" rev 0x90 pchb1 at pci0 dev 16 function 0 "Intel 5100 FSB" rev 0x90 pchb2 at pci0 dev 16 function 1 "Intel 5100 FSB" rev 0x90 pchb3 at pci0 dev 16 function 2 "Intel 5100 FSB" rev 0x90 pchb4 at pci0 dev 17 function 0 "Intel 5100 Reserved" rev 0x90 pchb5 at pci0 dev 19 function 0 "Intel 5100 Reserved" rev 0x90 pchb6 at pci0 dev 21 function 0 "Intel 5100 DDR" rev 0x90 pchb7 at pci0 dev 22 function 0 "Intel 5100 DDR" rev 0x90
two new pci ids
Found in a Dell PE R200 and verified through pciids.sf.net Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1336 diff -u -r1.1336 pcidevs --- pcidevs 23 Mar 2008 12:10:00 - 1.1336 +++ pcidevs 1 Apr 2008 19:49:00 - @@ -2327,6 +2327,8 @@ product INTEL 82X38_PT_IDER0x29e6 82X38 PT IDER product INTEL 82X38_KT 0x29e7 82X38 KT product INTEL 82X38_PCIE_2 0x29e9 82X38 PCIE +product INTEL 3200_HB 0x29f0 3200/3210 Host +product INTEL 3200_PCIE0x29f1 3200/3210 PCIE product INTEL 82GM965_HB 0x2a00 GM965 Host product INTEL 82GM965_PCIE 0x2a01 GM965 PCIE product INTEL 82GM965_IGD_10x2a02 GM965 Video turns pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x29f0 rev 0x01 ppb0 at pci0 dev 1 function 0 vendor "Intel", unknown product 0x29f1 rev 0x01: irq 15 into pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: irq 15 Regards, Mitja
ipsec.conf and AES 256
As far as I can tell, currently in ipsec.conf there is no way to use AES with KEY_LENGHT=256. Is anybody working on adding this? Otherwise I might try it when the time permits. I'm thinking that isakmpd should first learn about a new default transform, let's say AES256 - then adding that into ipsecctl/ipsec.conf should be pretty much trivial. The other route is not to add this new default transform to isakmpd, but to have ipsecctl generate a config with a non-default transform - this does not touch isakmpd at all, but is less than trivial in ipsecctl. Thoughts, anyone? Mitja
Re: glxsb crypto crash
For the archives,
the following two commits have fixed this:
--
CVSROOT:/cvs
Module name:src
Changes by: [EMAIL PROTECTED] 2007/11/14 12:10:44
Modified files:
sys/arch/i386/i386: via.c
sys/arch/i386/pci: glxsb.c
Log message:
do not process requests linked to unused sessions. (crypto_freesession
might happen between enqueuing a crypto request and scheduling of
the crypto thread); ok hshoexer
--
CVSROOT:/cvs
Module name:src
Changes by: [EMAIL PROTECTED] 2007/11/14 12:12:37
Modified files:
sys/crypto : crypto.c
Log message:
do not call crypto_done() on errors, since the drivers already do this.
otherwise we call the callback twice; fixes panics on crypto errors as
seen on reboot; ok hshoexer
--
Regards, Mitja
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Mitja Mu>enih
> Sent: Saturday, November 10, 2007 10:56 PM
> To: misc@openbsd.org
> Subject: glxsb crypto crash
>
> Not my day, obviously
>
> On a net5501 machine that I just upgraded to 4.2 I
> experienced a sudden
> reboot and found this in dmesg:
>
> uvm_fault(0xd078d120, 0x0, 0, 1) -> e
> fatal page fault (6) in supervisor mode
> trap type 6 code 0 eip d03d4fab cs 8 eflags 10296 cr2 4 cpl 90
> panic: trap type 6, code=0, pc=d03d4fab
> Starting stack trace...
> panic(0,d6a0215c,da48ed3c,0,d6a0215c) at panic+0x71
> panic(d06a2ca7,6,0,d03d4fab,d067c27d) at panic+0x71
> trap() at trap+0x119
> --- trap (number 6) ---
> swcr_authcompute(d6845068,d68440e0,0,d69a5900,2) at
> swcr_authcompute+0x33
> glxsb_crypto_freesession(d6845068,d68440e0,0,d69a5900,90) at
> glxsb_crypto_freese
> ssion+0xe3
> glxsb_crypto_process(d6845068,0,da48ef6c,d0332d78) at
> glxsb_crypto_process+0xd4
> crypto_invoke(d6845068,24,d0690993,0) at crypto_invoke+0xbc
> crypto_thread(d6a0215c) at crypto_thread+0x38
> Bad frame pointer: 0xd08c7eb8
> End of stack trace.
> syncing disks... 22 22 21 19 15 9 2 1 1 1 1 1 1 1 1 1 1 1 1 1
> giving up
>
>
> It's a moderately loaded machine with approx. 40 ipsec
> tunnels active, this
> crash happened within an hour since my last reboot.
>
> Any hints on how to debug this? I'd settle for disabling the
> use of glxsb
> crypto acceleration if necessary, don't have that much ipsec
> traffic (yet).
>
>
> Regards, Mitja
>
> dmesg:
>
> OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Geode(TM) Integrated Processor by AMD PCS
> ("AuthenticAMD" 586-class)
> 500 MHz
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
> real mem = 536440832 (511MB)
> avail mem = 511070208 (487MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 20/70/19, BIOS32 rev. 0
> @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #1 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev
> 0x00: RNG AES
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:00:24:c8:de:2c
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96:
> irq 5, address
> 00:00:24:c8:de:2d
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96:
> irq 9, address
> 00:00:24:c8:de:2e
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
> address 00:00:24:c8:de:2f
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ppb0 at pci0 dev 14 function 0 "TI PCI2250 PCI-PCI" rev 0x02
> pci1 at ppb0 bus 1
> sis0 at pci1 dev 0 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq
> 10, address 00:00:24:c3:47:fc
> nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
> sis1 at pci1 dev 1 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq 7,
> address 00:00:24:c3:47:fd
> nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
> pcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01:
> DMA, channel 0
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 4-sector PIO, LBA, 977MB, 2001888 sectors
> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02:
> irq 15, version
> 1.0, legacy support
> ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB"
glxsb crypto crash
Not my day, obviously
On a net5501 machine that I just upgraded to 4.2 I experienced a sudden
reboot and found this in dmesg:
uvm_fault(0xd078d120, 0x0, 0, 1) -> e
fatal page fault (6) in supervisor mode
trap type 6 code 0 eip d03d4fab cs 8 eflags 10296 cr2 4 cpl 90
panic: trap type 6, code=0, pc=d03d4fab
Starting stack trace...
panic(0,d6a0215c,da48ed3c,0,d6a0215c) at panic+0x71
panic(d06a2ca7,6,0,d03d4fab,d067c27d) at panic+0x71
trap() at trap+0x119
--- trap (number 6) ---
swcr_authcompute(d6845068,d68440e0,0,d69a5900,2) at swcr_authcompute+0x33
glxsb_crypto_freesession(d6845068,d68440e0,0,d69a5900,90) at
glxsb_crypto_freese
ssion+0xe3
glxsb_crypto_process(d6845068,0,da48ef6c,d0332d78) at
glxsb_crypto_process+0xd4
crypto_invoke(d6845068,24,d0690993,0) at crypto_invoke+0xbc
crypto_thread(d6a0215c) at crypto_thread+0x38
Bad frame pointer: 0xd08c7eb8
End of stack trace.
syncing disks... 22 22 21 19 15 9 2 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
It's a moderately loaded machine with approx. 40 ipsec tunnels active, this
crash happened within an hour since my last reboot.
Any hints on how to debug this? I'd settle for disabling the use of glxsb
crypto acceleration if necessary, don't have that much ipsec traffic (yet).
Regards, Mitja
dmesg:
OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
500 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 536440832 (511MB)
avail mem = 511070208 (487MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/70/19, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:00:24:c8:de:2c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
00:00:24:c8:de:2d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address
00:00:24:c8:de:2e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
address 00:00:24:c8:de:2f
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ppb0 at pci0 dev 14 function 0 "TI PCI2250 PCI-PCI" rev 0x02
pci1 at ppb0 bus 1
sis0 at pci1 dev 0 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq
10, address 00:00:24:c3:47:fc
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci1 dev 1 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 7,
address 00:00:24:c3:47:fd
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
pcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 4-sector PIO, LBA, 977MB, 2001888 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version
1.0, legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: AMD EHCI root hub, rev 2.00/1.00, addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio0 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
usb1 at ohci0: USB revision 1.0
uhub1 at usb1: AMD OHCI root hub, rev 1.00/1.00, addr 1
biomask e145 netmask ffe5 ttymask ffe7
pctr: user-level cycle counter enabled
mtrr: K6-family MTRR support (2 registers)
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a swap on wd0b dump on wd0b
WARNING: / was not properly unmounted
ifconfig regress in combination with pppoe(4)
Hi all! I just found the hard way that my old hostname.pppoe0 file which used to work under 4.1 causes a spectacular failure on 4.2. # sh /etc/netstart pppoe0 ifconfig: SIOCSIFGENERIC(SPPPIOSDEFS): Device busy The reason turned out to be a whitespace character after the \ sign in hostname.pppoe0. Simplest way to recreate is to take the example from man and add a whitespace at the end of the first or second line after \. # cat hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE \ pppoedev vr2 authproto chap \ authname '' authkey '' up dest 0.0.0.1 Can somebody verify this? All my pppoe machines are remote. Thanks, Mitja
HP Proliant ML110
For the archives: HP Proliant ML110 will not boot bsd.rd unless the BIOS option "8042 Emulation Support" (which is enabled by default) is disabled. It will hang at the "entry point..." message indefinitely. Maybe this will save somebody half an hour of googling, tweaking bios etc Mitja
Re: weird ppp upgrade problems
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Otto Moerbeek
> Sent: Sunday, October 28, 2007 9:19 PM
> To: Mitja Mu>enih
> Cc: misc@openbsd.org
> Subject: Re: weird ppp upgrade problems
>
> On Sun, 28 Oct 2007, Mitja Mu>enih wrote:
>
> > I managed to narrow down this isssue significantly.
> >
> > My hardware setup on this box is a soekris 4801 board + a
> 4-port serial
> card
> > by Sunix (
> >
> http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_
> a_id=34&sid=36
> > 1 ), full dmesg at the end.
> >
> > The serial ports are:
> >
> > puc0 at pci0 dev 10 function 0 "Sunix 40XX" rev 0x01: ports: 4 com
> > pccom3 at puc0 port 0 irq 11: ti16750, 64 byte fifo
> > pccom4 at puc0 port 1 irq 11: ti16750, 64 byte fifo
> > pccom5 at puc0 port 2 irq 11: ti16750, 64 byte fifo
> > pccom6 at puc0 port 3 irq 11: ti16750, 64 byte fifo
>
> Can you try a more recent snap? It has fifo probe code enabled, and it
> is interesteing to see if the fifo probe reports a different depth.
>
> That commit was done to resolve an issue for a 2 port Sunix card. For
> this card (4036A) the actual fifo depth is 32 instead of 64.
Good catch!
...
puc0 at pci0 dev 10 function 0 "Sunix 40XX" rev 0x01: ports: 4 com
pccom3 at puc0 port 0 irq 11: ti16750, 64 byte fifo
pccom3: probed fifo depth: 32 bytes
pccom4 at puc0 port 1 irq 11: ti16750, 64 byte fifo
pccom4: probed fifo depth: 32 bytes
pccom5 at puc0 port 2 irq 11: ti16750, 64 byte fifo
pccom5: probed fifo depth: 32 bytes
pccom6 at puc0 port 3 irq 11: ti16750, 64 byte fifo
pccom6: probed fifo depth: 32 bytes
And guess what? The ppp modem connection now works!
Now, is there a way to add a quirk for this specific card for 4.2? Or should
I take my chances and uncomment com_fifo_probe() in the 4.2 source? I would
rather not run -current in production at this early stage of the development
cycle.
Regards, Mitja
>
> See
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/com_subr.
> c.diff?r1=1.10&
> r2=1.11
>
> -Otto
>
> > ...
> > pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> > pccom0: console
> > pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> > .
> >
> >
> > OpenBSD 3.6-3.8: modem comms using an ISDN modem over
> /dev/cua03 to cua06
> > work OK.
> >
> > OpenBSD 3.9 and later up to -current of a few days ago: using
> /dev/cua0[3,4]
> > fails, /dev/cua01 works OK. When I use the sunix ports, on
> the remote end
> it
> > appears that my ppp process is sending corrupted data mixed
> with valid data
> > fields in LCP proposals. The fact that the on-board
> isa-attached pccom1
> > works shows that userland ppp is not at fault for this breakage.
> >
> > So far everything points at the changes in puc(4) between
> 3.8 and 3.9.
> >
> > Before I start reverting the (luckily few) changes one by
> one, does anyone
> > have a better idea? Or a hint on how to debug this better.
> >
> >
> > Thanks, Mitja
> > (and apologies for not submiting a dmesg the first time,
> but I felt that
> the
> > original mail was long enough even without it)
> >
> >
> > OpenBSD 4.2-current (GENERIC) #10: Sat Oct 20 15:59:16 CEST 2007
> > [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: Geode(TM) Integrated Processor by National Semi
> ("Geode by NSC"
> > 586-class) 267 MHz
> > cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
> > cpu0: TSC disabled
> > real mem = 133787648 (127MB)
> > avail mem = 121565184 (115MB)
> > mainbus0 at root
> > bios0 at mainbus0: AT/286+ BIOS, date 20/70/08, BIOS32 rev.
> 0 @ 0xf7840
> > pcibios0 at bios0: rev 2.0 @ 0xf/0x1
> > pcibios0: pcibios_get_intr_routing - function not supported
> > pcibios0: PCI IRQ Routing information unavailable.
> > pcibios0: PCI bus #0 is the last bus
> > bios0: ROM list: 0xc8000/0x9000
> > cpu0 at mainbus0
> > pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> > pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
> > sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq
> > 10, address 00:00:24:c6:15:4c
> > nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
> > sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq
> > 10, address 00:00:24:c6:15:4d
> > nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
> > sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00,
> DP83816A: irq
> > 10, address 00:00:24:c6:15:4e
> > nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
> > puc0 at pci0 dev 10 function 0 "Sunix 40XX" rev 0x01: ports: 4 com
> > pccom3 at puc0 port 0 irq 11: ti16750, 64 byte fifo
> > pccom4 at puc0 port 1 irq 11: ti16750, 64 byte fifo
> > pccom5 at puc0 port 2 irq 11: ti16750, 64 byte fifo
> > pccom6 at puc0 port 3 irq 11: ti16750, 64 byte fifo
> > gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
> > gpio0 at gscpcib0: 64 pins
> > "NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured
> > pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01:
> DMA, channel
Re: weird ppp upgrade problems
I managed to narrow down this isssue significantly.
My hardware setup on this box is a soekris 4801 board + a 4-port serial card
by Sunix (
http://www.sunix.com.tw/it/en/Product_Detail.php?cate=2&class_a_id=34&sid=36
1 ), full dmesg at the end.
The serial ports are:
puc0 at pci0 dev 10 function 0 "Sunix 40XX" rev 0x01: ports: 4 com
pccom3 at puc0 port 0 irq 11: ti16750, 64 byte fifo
pccom4 at puc0 port 1 irq 11: ti16750, 64 byte fifo
pccom5 at puc0 port 2 irq 11: ti16750, 64 byte fifo
pccom6 at puc0 port 3 irq 11: ti16750, 64 byte fifo
...
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
.
OpenBSD 3.6-3.8: modem comms using an ISDN modem over /dev/cua03 to cua06
work OK.
OpenBSD 3.9 and later up to -current of a few days ago: using /dev/cua0[3,4]
fails, /dev/cua01 works OK. When I use the sunix ports, on the remote end it
appears that my ppp process is sending corrupted data mixed with valid data
fields in LCP proposals. The fact that the on-board isa-attached pccom1
works shows that userland ppp is not at fault for this breakage.
So far everything points at the changes in puc(4) between 3.8 and 3.9.
Before I start reverting the (luckily few) changes one by one, does anyone
have a better idea? Or a hint on how to debug this better.
Thanks, Mitja
(and apologies for not submiting a dmesg the first time, but I felt that the
original mail was long enough even without it)
OpenBSD 4.2-current (GENERIC) #10: Sat Oct 20 15:59:16 CEST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC"
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem = 133787648 (127MB)
avail mem = 121565184 (115MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/70/08, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq
10, address 00:00:24:c6:15:4c
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq
10, address 00:00:24:c6:15:4d
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq
10, address 00:00:24:c6:15:4e
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
puc0 at pci0 dev 10 function 0 "Sunix 40XX" rev 0x01: ports: 4 com
pccom3 at puc0 port 0 irq 11: ti16750, 64 byte fifo
pccom4 at puc0 port 1 irq 11: ti16750, 64 byte fifo
pccom5 at puc0 port 2 irq 11: ti16750, 64 byte fifo
pccom6 at puc0 port 3 irq 11: ti16750, 64 byte fifo
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 1:
wd0: 16-sector PIO, LBA, 5729MB, 11733120 sectors
wd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6
revision 3 wdstatus 0
ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 5,
version 1.0, legacy support
isa0 at gscpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Compaq OHCI root hub" rev 1.00/1.00 addr 1
biomask f3e5 netmask f7e5 ttymask ffe7
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a swap on wd0b dump on wd0b
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Mitja Mu>enih
> Sent: Saturday, October 20, 2007 1:41 PM
> To: misc@openbsd.org
> Subject: weird ppp upgrade problems
>
> Hi!
>
> I have a box with two external ISDN modems attached to it
> that acts as an
> outgoing modem pool to a number of remote located ISDN
> routers (zyxel P-202H
> Plus v2).
>
> Recently I was given the go-ahead to upgrade this 3.6 box so
> I swapped the
> disk with a new one with a fresh install of 4.1 (4.2 cds
> haven't yet arrived
> then). Unfortuantely, this upgrade caused the outgoing ppp
> connec
weird ppp upgrade problems
Hi! I have a box with two external ISDN modems attached to it that acts as an outgoing modem pool to a number of remote located ISDN routers (zyxel P-202H Plus v2). Recently I was given the go-ahead to upgrade this 3.6 box so I swapped the disk with a new one with a fresh install of 4.1 (4.2 cds haven't yet arrived then). Unfortuantely, this upgrade caused the outgoing ppp connections to fail. My initial investigation didn't show me a clear reason for this so I went back to 3.6 and then upgraded version by version, until I found the moment when the unchanged very simple ppp.conf (at the bottom of this mail) didn't work anymore. To cut a long story shirt, something happened between 3.8 and 3.9 that changes the behaviour of the LCP negotiation protocol in my specific case: 3.8: Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: deflink: LayerStart Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: ACFCOMP[2] Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: PROTOCOMP[2] Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: ACCMAP[6] 0x Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: MRU[4] 1500 Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: MAGICNUM[6] 0x434b14d1 Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: deflink: State change Stopped --> Req-Sent Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: deflink: RecvConfigRej(1) state = Req-Sent Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: PROTOCOMP[2] Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: ACFCOMP[2] Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: deflink: SendConfigReq(2) state = Req-Sent Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: ACCMAP[6] 0x Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: MRU[4] 1500 Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: MAGICNUM[6] 0x434b14d1 Oct 18 16:29:27 ringie ppp[11094]: tun0: LCP: deflink: RecvConfigAck(2) state = Req-Sent 3.9: Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: deflink: LayerStart Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: ACFCOMP[2] Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: PROTOCOMP[2] Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: ACCMAP[6] 0x Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: MRU[4] 1500 Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: MAGICNUM[6] 0x1c0be38b Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: deflink: State change Stopped --> Req-Sent Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: deflink: RecvConfigReq(235) state = Req-Sent Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: MRU[4] 1524 Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: MAGICNUM[6] 0x4b27d550 Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: ACFCOMP[2] Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: MRRU[4] 1524 Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: ENDDISC[9] MAC 00:13:49:33:c8:84 Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: LDBACP[4] 002b Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: ACCMAP[6] 0x Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: deflink: SendConfigRej(235) state = Req-Sent Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: MRRU[4] 1524 Oct 18 16:28:45 ringie ppp[6602]: tun0: LCP: LDBACP[4] 002b Under 3.8, my end makes some proposals, the remote end rejects a couple of them and eventually we reach an agreement. Under 3.9 and all the later versions including -current, we send the exactly same proposals but the remote end instead of replying to them, sends its own set of proposals - which we ultimately find unnacceptable as we cannot grok LDBACP. Under 3.8 the flow goes: SendConfigReq -> RecvConfigRej -> SendConfigReq -> RecvConfigAck. Under 3.9 the flow goes: SendConfigReq -> RecvConfigReq -> SendConfigRej -> RecvConfigReq -> SendConfigRej ... The funny part is that our config file and proposal remain the same during the OS version change, even the physical bits being pushed through the serial port seem not to have changed except for MAGICNUM - so what makes the remote router change its behaviour??? What makes Zyxel react differently? cvs diff on /usr/src/usr.sbin/ppp/ppp between 3.8 and 3.9 shows a good 2k lines have changed, but it seems to be mostly the inclusion of radius support and some ipv6-related work, nothing that even remotely appears to be involved in LCP. Out of desperation I have tried to build 3.8's ppp sources on a 3.9 system, but surprisingly the resulting ppp gave the 3.9 behaviour. Could this mean that change was caused by kernel or other system components? Regards, Mitja --- default: set log Phase Chat LCP IPCP CCP tun command set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" disable ipv6cp enable mssfixup stpn: set device /dev/cua03 set phone 004912345678901 set login set authname xx set authkey yy set ifaddr 0.0.0.0/16 10.
Re: vr driver trouble on Soekris 5501
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Christian Plattner > Sent: Friday, October 12, 2007 4:43 PM > To: misc@openbsd.org > Subject: Re: vr driver trouble on Soekris 5501 > > > Not sure if related, but something similar has been fixed in > > 4.2-current already. > > This was also the first thing that came into my mind, however, I don't > think it is related. VR_STICKHW is only written erroneously during > attach, and since my machine runs now for several weeks without any > problem, I doubt that the observed stall has something to do > with this. > > Opinions by the vr maintainers? Anything I can do to debug > the problem > when it occurs next time? For what it's worth, I experienced the same problem caused by attaching and detaching a (short) crossover cable multiple times on a vr interface in soekris net5501 running 4.1-stable. As it was on a production firewall I didn't troubleshoot much, tcpdump didn't show any incoming traffic on that interface - then I went for a quick reboot that obviously fixed things. Let me see if I can replicate it in lab. Mitja
Re: IPSec Keylifetime using ipsecctl and ipsec.conf?
Coincidentally I have exactly same symptoms connecting 4.1-stable (using isakmpd.conf and AES SHA1) to an unknown remote Firebox VPN gateway running "firebox software 8.3" (very sketchy information because I had to prie it out of the IT people at the remote end). Rekeying occasionaly fails, Phase 2 is down but Phase 1 SA remains active. The Firebox side does not reply to my Phase 2 proposals until I manually kill the Phase 1 SA on my end and reestablish everything. I'm inclined to assume the problem lies at Firebox's end. But I have no access to Watchguard's support pages to see if it is a known problem. Mitja > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, July 26, 2007 10:05 AM > To: misc@openbsd.org > Subject: IPSec Keylifetime using ipsecctl and ipsec.conf? > > Hi, > > I am using ipsecctl and /etc/ipsec.conf to create an IPSec > tunnel to a > WatchGuard Firebox X700 in my company. It works fine, but the > re-keying always makes some trouble, it does not always work. My > question now is, how can I set the keylifetimes for phase 1 and 2 in > /etc/ipsec.conf? Is there a way to do this? The manpage does > not give > any more info... > > I am running an OpenBSD 4.1 current. My ipsec.conf file looks > like this: > > ike esp from 10.240.1.0/24 to 192.168.128.0/24 \ >peer 1.2.3.4 \ >main auth hmac-sha1 enc 3des group modp1024 \ >quick auth hmac-sha1 enc 3des group none \ >psk "" > > Regards, > James
Re: wifi signal triangulation
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Reyk Floeter > Sent: Monday, December 18, 2006 11:22 AM > To: Jacob Yocom-Piatt > Cc: misc@openbsd.org > Subject: Re: wifi signal triangulation > > On Sun, Dec 17, 2006 at 12:09:12PM -0600, Jacob Yocom-Piatt wrote: > > only today have i tried out hostapd, it is quite neat. > while adding a 2nd AP to > > my network a thought occurred to me: if you had >3 APs that > were sufficiently > > spread out and had tightly synced clocks you could likely > triangulate the source > > of a wifi signal with a fair deal of accuracy. > > > > is this doable? > > > > yes > > but it needs some heavy math ;). you can get some results by using the > signal strength, but it is probably better if you also use the round > trip time and some low level information. I'm curious about this, especially about the final triangulation resolution. The wifi signal propagates at the speed of light, 300k km/s, so to get a (relatively poor) distance resolution of 1 km, one would need to be able to reliably clock times smaller than (1 km) / (300k km/s) = 3 * 10^-6 s, or in other words, less than three microseconds. GSM does something similar - since GSM is using TDMA, the signal from a mobile terminal have to reach the base station during a specific timeframe slot. On the mobile terminal there is a parameter called TA (for Timing Advance) that shows the timing correction factor because of the distance to the BTS, and if I recall correctly, it is possible to get a 250m resolution out of TA. But GSM hardware is probably more suitable for this than regular PC hardware. > > once we implemented it with hostapd, a sql patch (to allow the central > hostapd sensor to log into a postgresql database), some gps > coordinates, and a hacked psql script to directly query the > triangulated results from the database. a guy from the ccc implemented > a php frontend to draw the station coodinates on an area map, but i > would prefer an implementation using svg and firefox without the need > of a server-side scripting language now ;). Do you happen to have a screen capture of the result? > > unfortunately, our code got lost after the experiment, but i may still > find the hostapdsql diff. > > reyk > Mitja
Re: VPN interoperability problem with Symantec Enterprise Firewall [solved]
Found a solution of sort - downgrade the phase 2 transform from AES to 3DES. Even if offically SEF 7.0.4 supports AES for phase 2 and it accepts it during IKE negotiation, the tunnel fails immediately with a misleading error message on SEF. Given the age of Symantec Enterprise Firewall 7.0.4 (released in 2001? ) and the standardisation year of AES (2002) I think the SEF AES algorhytm is simply broken. Beware. HJ, thanks for help! Regards, Mitja > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Hans-Joerg Hoexer > Sent: Wednesday, October 18, 2006 12:11 PM > To: Mitja Mu?eni? > Cc: misc@openbsd.org > Subject: Re: VPN interoperability problem with Symantec > Enterprise Firewall > > Hi, > > could you please provide a pcap of such an exchange? > Thanks, > HJ. > > On Wed, Oct 18, 2006 at 11:57:53AM +0200, Mitja Mu?eni? wrote: > > > > Just a quick question if anybody has had the same problem, > or contrary, if > > anybody has a success story with SEF. I'm trying to > establish an IPsec > > tunnel between OpenBSD 3.9 and Symantec Enterprise Firewall > 7.0.4 (NT/2k) > > which is not under my control. > > > > The negotiation goes through normally, but immediately > afterwards the remote > > end sends a "DELETE" notification. The tunnel is still up > on OpenBSD's end, > > but no traffic ever reaches the destination. > > > > The remote end (Symantec) spits out (obfuscated to protect > the innocent): > > > > "VPN packet dropped (213.aaa.bbb.ccc->217.ddd.eee.fff: > Protocol=IPSEC-ESP > > spi=0xa0723686): Received IPCOMP packet on a tunnel that > was not configured > > for compression (tunnel [EMAIL PROTECTED] > )" > > > > > > This error message is funny because as far as I know, > OpenBSD does not > > support IPCOMP in automatic IKE through isakmpd. Any idea > why Symantec would > > believe that we are sending it IPCOMP traffic? > > > > > > I even checked that net.inet.ipcomp.enable=0 - not that I > know if it's > > applicable to IPsec at all. I suspect this is a bug in SEF, > but can't find > > anything on google or mailing list archives. Nothing special in my > > isakmpd.conf, I have multiple tunnels working to other > vendors' VPN peers. > > > > > > Regards, > > > > Mitja
Re: OpenBSD dedicated hosting
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Gilles Chehade > Sent: Thursday, October 19, 2006 12:02 AM > To: [EMAIL PROTECTED] > Cc: misc@openbsd.org > Subject: Re: OpenBSD dedicated hosting > [...] > I have then tried LayeredTech as suggested by someone on the > list and I am > very happy with it. The only negative point so far was that > they advertised > OpenBSD 3.x, and it turned out x really meant 5. I spent about an hour > upgrading from OpenBSD 3.5 up to 3.9-stable. Ok I confess, I > actually found > that fun since I never did in-place upgrades ;) I'm running a box with LayeredTech too I also got and old version, but first thing I ordered a KVM/IP extender (30$ for 24h, but I had it much longer than that), sent their staff cdrom39.iso to burn and insert into the drive and did a clean fresh install of 3.9. Only problem I had was that on the hardware I have with them RAID_AUTOCONFIG hangs during boot. I tried to get my hands on identical hardware to test and debug but on mine it didn't hang. There is a patch floating around this list that most likely fixes that (no need for RAID_AUTOCONFIG to probe cd drives for RAID components, right?) but I can't test it now as the box is in heavy production. Any San Antonio Spurs' fans out there, you will know the place. :) > > ++ Gilles > Mitja
VPN interoperability problem with Symantec Enterprise Firewall
Hi! Just a quick question if anybody has had the same problem, or contrary, if anybody has a success story with SEF. I'm trying to establish an IPsec tunnel between OpenBSD 3.9 and Symantec Enterprise Firewall 7.0.4 (NT/2k) which is not under my control. The negotiation goes through normally, but immediately afterwards the remote end sends a "DELETE" notification. The tunnel is still up on OpenBSD's end, but no traffic ever reaches the destination. The remote end (Symantec) spits out (obfuscated to protect the innocent): "VPN packet dropped (213.aaa.bbb.ccc->217.ddd.eee.fff: Protocol=IPSEC-ESP spi=0xa0723686): Received IPCOMP packet on a tunnel that was not configured for compression (tunnel [EMAIL PROTECTED] )" This error message is funny because as far as I know, OpenBSD does not support IPCOMP in automatic IKE through isakmpd. Any idea why Symantec would believe that we are sending it IPCOMP traffic? I even checked that net.inet.ipcomp.enable=0 - not that I know if it's applicable to IPsec at all. I suspect this is a bug in SEF, but can't find anything on google or mailing list archives. Nothing special in my isakmpd.conf, I have multiple tunnels working to other vendors' VPN peers. Regards, Mitja
Re: Oldest Server you run
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Falk Husemann > Sent: Thursday, October 12, 2006 8:55 PM > To: misc@openbsd.org > Subject: Oldest Server you run > > Hello List! > We're trying to put an old server to good use again and would > like to > know what's exactly the oldest machine running OpenBSD? > > > As machine we defined something with processor, ram, network, hard > disk and a connection to the internet. So no Newton or toaster (at > least not if there's no disk being toasted). > > > Thank you in advance, > Falk I had a vintage 486/33 with 24Mb RAM and an 850Mb HDD running as a wireless ap on my parents' attic until last storm a couple weeks ago. It caught a lighting bolt and turned into toast, though, so no dmesg. Was my first 486 workstation, so it must have been from 1993 or so. I also have an industrial 386SX with 32Mb RAM that used to run 3.1 or 3.2, back in the day when FPU emulation still kinda worked. It was useless as a box and dog slow, I have it for sheer geek factor only. :) Regards, Mitja
Re: RAID on 3.9 hangs
As you referenced my post - I never solved that. It was just too painful to seriously debug it over a rented KVM from half the world away and requiring me to open a trouble ticket for every reboot. I even tried to replicate the problem locally on supposedly same hardware (HP Compaq dc5100 + 2x SATA HDDs) but here I couldn't get it to hang on raidframe. I did manage to consistently hang it by enabling the front two USB ports, tough. Eventually I had to abandon the idea of root-on-raid and use raid1 just for the data set (without RAID_AUTOCONFIG it works for me). Let me point out for the archives that this machine seems very weird in many subtle ways, so I do not reccomend it for [OpenBSD|serious use]. Can you show a dmesg? I'm still working up the nerve to upgrade another remote server (with totally different hardware, but still) with root-on-raid. Regards, Mitja > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Simon Vallet > Sent: Sunday, June 04, 2006 3:26 PM > To: misc@openbsd.org > Subject: RAID on 3.9 hangs > > Hi, > > I'm just in the process of upgrading to 3.9 from a root-on-RAID 3.8 > -stable install. I fetched the sources from the CD, built a > RAID-enabled kernel, and rebooted : the kernel hangs after issuing > "Kernelized RAIDframe activated" and won't go further. > > Browsing through the archives, I notice this is the exact same problem > as described here : > http://archives.neohapsis.com/archives/openbsd/2006-05/0535.html > > Does any of you know what's the cause of this ? > > Simon
Re: 3.9-stable+ raidframe hangs on boot
This is a fresh install on a supposedly virgin HDD set, but since it's a
hosting server, don't know exactly if they aren't simply recycled.
I did make some progress a few minutes after posting the initial mail. The
hang happens only with option RAID_AUTOCONFIG. If I boot a kernel with
RAIDframe but no RAID_AUTOCONFIG, it does not hang and it boots normally.
I assumed there was something on the disk that confuses RAID_AUTOCONFIG, so
I booted a kernel without it and created a raid set by the book, and set it
to autoconfig = yes.
But surprisingly, next reboot with GENERIC + RAIDframe + RAID_AUTOCONFIG
hangs again!
Regards, Mitja
> -Original Message-
> From: Gustavo A. Baratto [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 05, 2006 9:47 PM
> To: Mitja Mu>enih
> Cc: misc@openbsd.org
> Subject: Re: 3.9-stable+ raidframe hangs on boot
>
> Was that an upgrade? When you do a fresh 3.9 install on a box that
> already had a RAID partition built for an older version, once
> you reboot
> into the GENERIC.RAID kernel, the system will come up using the older
> OS installed in the RAID partition.
>
> If that's the case, reboot with GENERIC, make sure you change the type
> of the partition from RAID to 4.2BSD (disklabel -E wd0. then choose m
> option. I guess you have to do this on wd1 as well. not sure).
>
> Then reboot into GENERIC.RAID, change the type of the partition again
> with disklabel from 4.2BSD to RAID, and configure your raid normally
>
> Let me know if this helps... I'm curious.
>
> Cheers
>
>
> Mitja Mu>enih wrote:
> > Hi!
> >
> > Yet another one of those weird things. HP Compaq dc5100, a
> couple thousand
> > km away from me, I've got a KVM/IP and a 3.9 cd stuck in the drive.
> >
> > Installed -release, rebooted, cvs'd to 3.9-stable, built
> GENERIC.RAID,
> > rebooted. GENERIC.RAID = GENERIC + option RAID_AUTOCONFIG +
> pseudo device
> > raid 4.
> >
> > The boot stops at
> >
> > biomask e7fd netmask effd ttymask
> > pctr: user-level cycle counter enabled
> > Kernelized RAIDframe activated
> >
> > and hangs here until the on-site person reboots it. I still
> have console
> > scrollback at that point.
> >
> > Where should I start looking?
> >
> > I noticed that "biomask..." line is slightly different from
> the GENERIC
> > kernel. Does anybody see anything peculiar in this dmesg?
> >
> >
> > Thanks, Mitja
> >
> >
> > OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
> > [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel"
> 686-class) 3 GHz
> > cpu0:
> >
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,P
> SE36,CFLUSH,AC
> > PI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,EST,CNXT-ID
> > cpu0: Enhanced SpeedStep disabled by BIOS
> > real mem = 3212353536 (3137064K)
> > avail mem = 2923577344 (2855056K)
> > using 4278 buffers containing 160718848 bytes (156952K) of memory
> > mainbus0 (root)
> > bios0 at mainbus0: AT/286+(5f) BIOS, date 08/25/05, BIOS32
> rev. 0 @ 0xeb520
> > pcibios0 at bios0: rev 2.2 @ 0xeb520/0x4ae0
> > pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4c00/256 (14 entries)
> > pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801FB
> LPC" rev 0x00)
> > pcibios0: PCI bus #3 is the last bus
> > bios0: ROM list: 0xc/0xa800! 0xca800/0x1000 0xcb800/0x2000
> > 0xdd600/0xc800!
> > cpu0 at mainbus0
> > pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> > pchb0 at pci0 dev 0 function 0 "Intel 82915G/P/GV Host" rev 0x04
> > vga1 at pci0 dev 2 function 0 "Intel 82915G/P/GV Video" rev
> 0x04: aperture
> > at 0xcfd0, size 0x1000
> > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> > wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> > ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03
> > pci1 at ppb0 bus 1
> > ppb1 at pci0 dev 28 function 1 "Intel 82801FB PCIE" rev 0x03
> > pci2 at ppb1 bus 2
> > bge0 at pci2 dev 0 function 0 "Broadcom BCM5751" rev 0x01,
> BCM5750 A1
> > (0x4001): irq 5, address 00:16:35:79:a0:29
> > brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> > ppb2 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xd3
> > pci3 at ppb2 bus 3
> > ichpcib0 at pci0 dev 31 function 0 "Intel 82801FB LPC" rev
> 0x03: PM disabled
> > pciide0 at pci0 dev 31 function 1 "Intel 82801FB IDE" rev
> 0x03: 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: 1.03> SCSI0
> > 5/cdrom removable
> > cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 3
> > pciide0: channel 1 disabled (no drives)
> > pciide1 at pci0 dev 31 function 2 "Intel 82801FB SATA" rev
> 0x03: DMA,
> > channel 0 configured to native-PCI, channel 1 configured to
> native-PCI
> > pciide1: using irq 5 for native-PCI interrupt
> > wd0 at pciide1 channel 0 drive 0:
> > wd0: 16-sector PIO, LBA48, 76319
3.9-stable+ raidframe hangs on boot
Hi!
Yet another one of those weird things. HP Compaq dc5100, a couple thousand
km away from me, I've got a KVM/IP and a 3.9 cd stuck in the drive.
Installed -release, rebooted, cvs'd to 3.9-stable, built GENERIC.RAID,
rebooted. GENERIC.RAID = GENERIC + option RAID_AUTOCONFIG + pseudo device
raid 4.
The boot stops at
biomask e7fd netmask effd ttymask
pctr: user-level cycle counter enabled
Kernelized RAIDframe activated
and hangs here until the on-site person reboots it. I still have console
scrollback at that point.
Where should I start looking?
I noticed that "biomask..." line is slightly different from the GENERIC
kernel. Does anybody see anything peculiar in this dmesg?
Thanks, Mitja
OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,AC
PI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,EST,CNXT-ID
cpu0: Enhanced SpeedStep disabled by BIOS
real mem = 3212353536 (3137064K)
avail mem = 2923577344 (2855056K)
using 4278 buffers containing 160718848 bytes (156952K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(5f) BIOS, date 08/25/05, BIOS32 rev. 0 @ 0xeb520
pcibios0 at bios0: rev 2.2 @ 0xeb520/0x4ae0
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4c00/256 (14 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801FB LPC" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc/0xa800! 0xca800/0x1000 0xcb800/0x2000
0xdd600/0xc800!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82915G/P/GV Host" rev 0x04
vga1 at pci0 dev 2 function 0 "Intel 82915G/P/GV Video" rev 0x04: aperture
at 0xcfd0, size 0x1000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801FB PCIE" rev 0x03
pci2 at ppb1 bus 2
bge0 at pci2 dev 0 function 0 "Broadcom BCM5751" rev 0x01, BCM5750 A1
(0x4001): irq 5, address 00:16:35:79:a0:29
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb2 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xd3
pci3 at ppb2 bus 3
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FB LPC" rev 0x03: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801FB IDE" rev 0x03: 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: SCSI0
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 3
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801FB SATA" rev 0x03: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using irq 5 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide1 channel 1 drive 0:
wd1: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
ichiic0 at pci0 dev 31 function 3 "Intel 82801FB SMBus" rev 0x03: irq 5
iic0 at ichiic0
isa0 at ichpcib0
isadma0 at isa0
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
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask ef6d netmask ef6d ttymask ffef
pctr: user-level cycle counter enabled
dkcsum: wd0 matches BIOS drive 0x80
wd1: no disk label
dkcsum: wd1 matches BIOS drive 0x81
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
isakmpd - DPD stops working
I'm debbuging something weird here. Before I put together a full and sanitized error report, just a quick question: is anybody else seeing DPD to just stop working after a couple of hours, or is it just me & my setup? I have some pre-3.9 -current (mid March or so) machines running some IPsec tunnels, and from the IKE dump it appears that after two hours both ends suddenly stop sending DPD R_U_THERE requests, even if the tunnel is totally idle (for example, if I down the interface connecting the hosts). The tunnnel never dies so the traffic for the other network goes into a black hole. Regards, Mitja
Re: pppoe loopback
> Today one of my clients' firewall lost its pppoe connection
3.8-stable, dmesg follows:
OpenBSD 3.8-stable (GENERIC) #0: Wed Nov 30 15:41:10 CET 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 349 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 133787648 (130652K)
avail mem = 115462144 (112756K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 07/19/01, BIOS32 rev. 0 @ 0xfd801
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1c50/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:02:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 1 function 0 "S3 Trio3D AGP" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 2 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 2 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel
0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 6149MB, 12594960 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom
removable
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
cd0(pciide0:0:1): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
uhci0 at pci0 dev 2 function 2 "Intel 82371AB USB" rev 0x01: 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
"Intel 82371AB Power" rev 0x02 at pci0 dev 2 function 3 not configured
fxp0 at pci0 dev 3 function 0 "Intel 82557" rev 0x05, i82558: irq 11,
address 00:04:ac:d9:eb:b5
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
rl0 at pci0 dev 20 function 0 "Realtek 8139" rev 0x10: irq 10 address
00:40:f4:b4:0d:86
rlphy0 at rl0 phy 0: RTL internal phy
isa0 at pcib0
isadma0 at isa0
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
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
isapnp0 at isa0 port 0x279: read port 0x203
wss1 at isapnp0 "Crystal Audio, CSC0100, , WSS/SB" port
0x534/4,0x388/4,0x220/16 irq 5 drq 1,0: CS4236/CS4236B (vers 0)
audio0 at wss1
"Crystal Audio, CSC010F, , Disabled" at isapnp0 not configured
"Crystal Audio, CSC0110, , CTRL" at isapnp0 port 0x120/8 not configured
biomask eb45 netmask ef45 ttymask ffc7
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
WARNING: / was not properly unmounted
pppoe0: phase establish
pppoe0: phase authenticate
pppoe0: phase network
pppoe0: phase terminate
pppoe0: phase dead
pppoe0: phase establish
pppoe0: phase dead
pppoe0: phase establish
pppoe0: up
pppoe0: phase authenticate
pppoe0: phase terminate
pppoe0: phase authenticate
pppoe0: phase terminate
pppoe0: phase authenticate
pppoe0: phase network
pppoe0: LCP keepalive timeout<6>pppoe0: phase terminate
pppoe0: phase establish
pppoe0: phase dead
pppoe0: phase establish
pppoe0: up
pppoe0: phase authenticate
pppoe0: phase network
pppoe0: phase terminate
pppoe0: phase dead
pppoe0: phase establish
pppoe0: phase authenticate
pppoe0: phase network
pppoe0: LCP keepalive timeout<6>pppoe0: phase terminate
pppoe0: phase establish
pppoe0: phase dead
pppoe0: phase establish
pppoe0: up
pppoe0: phase authenticate
pppoe0: phase network
pppoe0: loopback
pppoe0: phase terminate
pppoe0: phase dead
pppoe0: phase establish
pppoe0: phase authenticate
pppoe0: phase network
pppoe loopback
Hi!
Today one of my clients' firewall lost its pppoe connection and had to be
manually restarted (ifconfig pppoe0 down/up). The funny thing was this log
message:
Feb 2 04:57:08 wall /bsd: pppoe0: loopback
Feb 2 04:57:08 wall /bsd: pppoe0: phase terminate
Feb 2 04:57:08 wall /bsd: pppoe0: phase dead
I traced the "loopback" message to the state engine in
/usr/src/sys/net/if_spppsubr.c
if (nmagic == sp->lcp.magic) {
/* Line loopback mode detected. */
printf(SPP_FMT "loopback\n", SPP_ARGS(ifp));
/* Shut down the PPP link. */
lcp.Close(sp);
break;
}
Can in this case the link be reinitialized automatically or at least retry a
couple of times?
Regards, Mitja
Winbond PC87591 on i2c?
Hi!
In the light of recent activity on i2c sensors, is anybody working on
Winbond (ex NS) PC87591 ?
As far as I can tell there is documentation available at
http://www.winbond.com.tw/E-WINBONDHTM/partner/apc_002.html and I believe
this is the sensor in at least one IBM Thinkpad model (A31p in my case).
The i2c master, though unsupported in 3.8, has appeared after I updated the
laptop to -current:
ichiic0 at pci0 dev 31 function 3 "Intel 82801CA/CAM SMBus" rev 0x02: irq 11
iic0 at ichiic0
Regards, Mitja
OpenBSD 3.9-beta (GENERIC) #595: Mon Jan 30 12:13:55 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz ("GenuineIntel"
686-class) 2 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,AC
PI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
real mem = 535863296 (523304K)
avail mem = 481943552 (470648K)
using 4278 buffers containing 26894336 bytes (26264K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(fb) BIOS, date 04/06/05, BIOS32 rev. 0 @ 0xfd7e0
apm0 at bios0: Power Management spec V1.2
apm0: battery life expectancy 100%
apm0: AC on, battery charge high
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xfd770/0x890
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdeb0/256 (14 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #4 is the last bus
bios0: ROM list: 0xc/0x1 0xdc000/0x4000! 0xe/0x1
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82845 Host" rev 0x04
ppb0 at pci0 dev 1 function 0 "Intel 82845 AGP" rev 0x04
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x4c58 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 82801CA/CAM USB" rev 0x02: 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 82801CA/CAM USB" rev 0x02: irq 11
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 82801CA/CAM USB" rev 0x02: 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
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x42
pci2 at ppb1 bus 2
cbb0 at pci2 dev 0 function 0 "Ricoh 5C476 CardBus" rev 0xa8: irq 11
cbb1 at pci2 dev 0 function 1 "Ricoh 5C476 CardBus" rev 0xa8: irq 11
"Ricoh 5C552 Firewire" rev 0x00 at pci2 dev 0 function 2 not configured
wi0 at pci2 dev 2 function 0 "Intersil PRISM2.5" rev 0x01: irq 11
wi0: PRISM2.5 ISL3874A(Mini-PCI) (0x8013), Firmware 1.1.0 (primary), 1.4.9
(station), address 00:02:6f:05:ce:9d
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x42, i82562: irq 11,
address 00:02:8a:96:ab:78
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x0, lattimer 0xb0
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 4 device 0 cacheline 0x0, lattimer 0xb0
pcmcia1 at cardslot1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801CAM LPC" rev 0x02: SpeedStep
pciide0 at pci0 dev 31 function 1 "Intel 82801CAM IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 38154MB, 78140160 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA, 38154MB, 78140160 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1(pciide0:0:1): 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: SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
ichiic0 at pci0 dev 31 function 3 "Intel 82801CA/CAM SMBus" rev 0x02: irq 11
iic0 at ichiic0
auich0 at pci0 dev 31 function 5 "Intel 82801CA/CAM AC97" rev 0x02: irq 11,
ICH3 AC97
ac97: codec id 0x41445348 (Analog Devices AD1881A)
ac97: codec features headphone, Analog Devices Phat Stereo
audio0 at auich0
"Intel 82801CA/CAM Modem" rev 0x02 at pci0 dev 31 function 6 not configured
isa0 at ichpcib0
isadma0 at isa0
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
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt2 at isa0 port 0x3bc/4: polled
npx0 at isa0 port 0xf0/16: using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask effd netmask effd ttymask
pctr: user-level cycle counter
max preshared key length in isakmpd?
Does anyone know what is the max length of the preshared key in Authentication= field? A pointer to a IKE RFC would be also nice, if the key size is defined somewhere. Google told me some Ciscos accept up to 48 characters as PSK, but couldn't find anything more specific. I'm trying to connect to a wise guy who wants me to use a 140+ characters string as PSK. I'm looking for stronger aguments than "that's ridiculous". Thanks, Mitja
Re: [OT]: good home switch?
> I've had one of these since 2002 or 2003 and it has worked > solidly ever > since. Of course, it'd be weird if such a simple device had any > problems. You'd be surprised how often and in how weird ways such simple devices can fail. A couple of months ago at a client's site a cheapo Jaht switch had decided to lose every 5th packet or so. Broke the network in many interesting ways. The fact that I was on a business trip on the other side of the globe at that time didn't help, nor the fact that in phone bills and time spent debugging I could have probably bought a gold plated switch in the first place. I've seen even 4-port 100Mb hubs - the dumbest devices of them all - hanging up and requiring a reset (3Com OfficeConnect of undetermined vintage). Moral of the story - even switches and hubs should come under suspcion when you are debugging your network. Regards, Mitja
Re: Moving from 3.7-release to -stable: make build fails (i386)
> > > # export CFLAGS='-O3 -mcpu=athlon-xp -march=athlon-xp -mmmx > > > -msse -m3dnow > > > -mfpmath=sse' [...] > I could do just 'make obj build' or something like that, but > I wanted to make clear that I'm not skipping any steps which > are required at the first rebuild, as it could be definitely > expected from a newbie in the field. I even wrote all those > 'cd ...'s to filter out notes like "do you really stick to > the intructions in the FAQ?" and similar BFU-typical errors > (which are generally assumed vey well possible in someone who > stamps themselves as a "new user"). > > In reality I just wipe obj, then make obj build, sure. So please tell us, where in FAQ it says to use those CFLAGS? Or any compiler flags at all? Regards, Mitja
SOLVED: RE: isakmpd: section has no "ID-type" tag
It turns out that I did some copy&paste action when I was creating the [peer-ID] section. And even if there were no extra blank characters anywhere (I was careful to check that multiple times), somehow something was still messing with the parser. Brackets or =, something must have looked fine on screen yet the character code or something was wrong. I didn't follow through on that. The solution? Delete the whole section and retype it again exactly the way it was - by hand. Grrr, wasted 5 hours on this. Thanks for all suggestions off-list. Regards, Mitja > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Mitja Mu>enih > Sent: Tuesday, August 30, 2005 11:41 AM > To: misc@openbsd.org > Subject: Re: isakmpd: section has no "ID-type" tag > > I don't want to be annoying but I have people breathing down my back. > > Does anyone at all have a working [peer-ID] section in isakmpd.conf? > > I mean something similar to: > > [ABCD-peer] > Phase=1 > Transport=udp > Address=aaa.bbb.ccc.ddd > Configuration=ABCD-main-mode > ID=ABCD-ID > Authentication= > > [ABCD-ID] > ID-type=USER_FQDN > Name=yy > > No matter what I put in ID-type tag, I get > > 001543.959050 Default ipsec_id_size: section ABCD-ID has no > "ID-type" tag > > No spaces or other additional characters anywhere. Is this a > bug in parser? > > > i386, on 3.6-stable and -current.
Re: isakmpd: section has no "ID-type" tag
I don't want to be annoying but I have people breathing down my back. Does anyone at all have a working [peer-ID] section in isakmpd.conf? I mean something similar to: [ABCD-peer] Phase=1 Transport=udp Address=aaa.bbb.ccc.ddd Configuration=ABCD-main-mode ID=ABCD-ID Authentication= [ABCD-ID] ID-type=USER_FQDN Name=yy No matter what I put in ID-type tag, I get 001543.959050 Default ipsec_id_size: section ABCD-ID has no "ID-type" tag No spaces or other additional characters anywhere. Is this a bug in parser? i386, on 3.6-stable and -current. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Mitja Mu>enih > Sent: Tuesday, August 30, 2005 12:31 AM > To: misc@openbsd.org > Subject: isakmpd: section has no "ID-type" tag > > I've been working on this for hours after an already long > day, so I'm tired. > What am I missing here? > > 001543.953108 Misc 95 conf_get_str: [ABCD-peer]:ID->ABCD-ID > 001543.956103 Misc 95 conf_get_str: configuration value not found > [ABCD-ID]:ID-type > 001543.959050 Default ipsec_id_size: section ABCD-ID has no > "ID-type" tag > 001543.962081 Default exchange_run: doi->initiator (0x8abf3400) failed > > # cat isakmpd.conf > [Phase 1] > aaa.bbb.ccc.ddd=ABCD-peer > > [Phase 2] > Connections=ABCD-conn > > [ABCD-peer] > Phase=1 > Transport=udp > Address=aaa.bbb.ccc.ddd > Configuration=ABCD-main-mode > ID=ABCD-ID > Authentication= > > [ABCD-ID] > ID-type=USER_FQDN > Name=yy > > [ABCD-conn] > Phase=2 > Configuration=ABCD-quick-mode > ISAKMP-peer=ABCD-peer > Local-ID=default-route > Remote-ID=ABCD-net > > [default-route] > ID-type=IPV4_ADDR_SUBNET > Network=192.168.123.0 > Netmask=255.255.255.0 > > [KLNR-net] > ID-type=IPV4_ADDR_SUBNET > Network=aaa.bbb.eee.0 > Netmask=255.255.255.0 > > [ABCD-main-mode] > DOI=IPSEC > EXCHANGE_TYPE= AGGRESSIVE > Transforms= 3DES-SHA > > [ABCD-quick-mode] > DOI=IPSEC > EXCHANGE_TYPE= QUICK_MODE > Suites= QM-ESP-3DES-SHA-SUITE > > > Sorry for the obfuscation, had to. No additional characters > at the end of > the lines in [ABCD-ID] section. > > Tried on 3.6-stable and latest snapshot, i386. > > > Regards, Mitja
isakmpd: section has no "ID-type" tag
I've been working on this for hours after an already long day, so I'm tired. What am I missing here? 001543.953108 Misc 95 conf_get_str: [ABCD-peer]:ID->ABCD-ID 001543.956103 Misc 95 conf_get_str: configuration value not found [ABCD-ID]:ID-type 001543.959050 Default ipsec_id_size: section ABCD-ID has no "ID-type" tag 001543.962081 Default exchange_run: doi->initiator (0x8abf3400) failed # cat isakmpd.conf [Phase 1] aaa.bbb.ccc.ddd=ABCD-peer [Phase 2] Connections=ABCD-conn [ABCD-peer] Phase=1 Transport=udp Address=aaa.bbb.ccc.ddd Configuration=ABCD-main-mode ID=ABCD-ID Authentication= [ABCD-ID] ID-type=USER_FQDN Name=yy [ABCD-conn] Phase=2 Configuration=ABCD-quick-mode ISAKMP-peer=ABCD-peer Local-ID=default-route Remote-ID=ABCD-net [default-route] ID-type=IPV4_ADDR_SUBNET Network=192.168.123.0 Netmask=255.255.255.0 [KLNR-net] ID-type=IPV4_ADDR_SUBNET Network=aaa.bbb.eee.0 Netmask=255.255.255.0 [ABCD-main-mode] DOI=IPSEC EXCHANGE_TYPE= AGGRESSIVE Transforms= 3DES-SHA [ABCD-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-SUITE Sorry for the obfuscation, had to. No additional characters at the end of the lines in [ABCD-ID] section. Tried on 3.6-stable and latest snapshot, i386. Regards, Mitja
Re: network traffic monitoring
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Monday, August 22, 2005 6:34 PM > To: petra merjasec > Cc: misc@openbsd.org > Subject: Re: network traffic monitoring > > If you just want a simple realtime monitor, I'd suggest pftop. > > Teren Sapp Which reminds me - is there a reason why pftop couldn't get imported in base? It complements pfctl very nicely, it's small, good at what it does and written by a OBSD developer (canacar@). Regards, Mitja
Accoom Networks T1/E1
Call me stupid but is there a link for this card? Google doesn't know anything useful about "Accoom" alone, even less for "Accoom Networks" and all the obvious spelling variations ([Acom, Accom, Accomm] + [PCI,E1,T1,card]). Or is it something not produced yet? Regards, Mitja > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Claudio Jeker > Sent: Sunday, August 14, 2005 12:50 AM > To: [EMAIL PROTECTED] > Subject: CVS: cvs.openbsd.org: src > > CVSROOT: /cvs > Module name: src > Changes by: [EMAIL PROTECTED] 2005/08/13 16:49:48 > > Added files: > sys/dev/pci: bt8370.c bt8370reg.h if_art.c if_art.h > musycc.c >musycc_obsd.c musyccreg.h musyccvar.h > > Log message: > Driver for the Accoom Networks Artery T1/E1 PCI cards. > deraadt@ "yeah, put it in."
pccom on cardbus not in GENERIC
A quicker question (a subset of my lenghty mail on tech@): why is pccom at cardbus not included in GENERIC? Does com_cardbus still have issues, is it lack of testing or any other reasons? The reason I'm asking this is that I'm struggling with a cardbus serial device (a GPRS/EDGE data card that is meant to work under OS != Windows) and would like to narrow down the problem. Regards, Mitja
