Re: LCP keepalive timeout for PPPOE

[Tom Murphy]

On 2020-01-03, jrmu  wrote:
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev cpsw0 authproto pap \
> authname '12345...@isp.net' authkey 'abcd1234' up
> dest 0.0.0.1
> #inet6 eui64
> !/sbin/route add default -ifp pppoe0 0.0.0.1
> #!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0

I had major problems with using 'dest' in hostname.pppoe0.
I ended up having to do something like:

inet 0.0.0.0 255.255.255.255 0.0.0.1 \
pppoedev re0 authproto chap
authname '' authkey ''

etc..

For whatever reason, using 'inet 0.0.0.0 255.255.255.255 NONE \
dest 0.0.0.1' would use this ifconfig command:

ifconfig pppoe0 inet 0.0.0.0 netmask 255.255.255.255  pppoedev re0 authproto 
chap

Where as if you replaced the NONE with 0.0.0.1 and removed the 'dest 0.0.0.1' 
line, it would
run:

ifconfig pppoe0 inet 0.0.0.0 netmask 255.255.255.255 broadcast 0.0.0.1 pppoedev 
re0 authproto chap

And that seemed to make my connection work. I'm not sure why, but it had to do 
something with my side
not accepting the peer's IP.

-Tom

BSD User Groups update

[Tom Murphy]

Hi,

  I was informed back on the 11th March 2019 from Sam Smith that
the Manchester BSD user group ended a few years ago.

  Attached is a diff to groups.dat to remove it from the list.

  Is this OK?

  Thanks,
  Tom

Index: build/groups.dat
===
RCS file: /cvs/www/build/groups.dat,v
retrieving revision 1.143
diff -u -p -u -p -r1.143 groups.dat
--- build/groups.dat2 Oct 2019 20:09:52 -   1.143
+++ build/groups.dat17 Oct 2019 13:08:08 -
@@ -400,15 +400,6 @@ N OpenBSD
 # Start of United Kingdom
 0
 C United Kingdom
-T Manchester
-O Manchester BSD User Group
-I Sam Smith
-U http://www.bsdgroups.org.uk/manchester
-F Usually the second week of each month
-N *BSD
-
-0
-C United Kingdom
 P Greater London
 T London
 O London *BSD Meetup

Re: SSH segfault when SendEnv is used in .ssh/config

[Tom Murphy]

On 06/14/18 05:38, Darren Tucker wrote:
> On 10 June 2018 at 17:43, Tom Murphy  wrote:
>>   I upgraded to the June 9th snapshot and noticed ssh segfaults
>> when I make connections. After a bit of checking in my .ssh/config,
>> I discovered the SendEnv directive is making is segfault. Not sure
>> if it has to do with the changes made 2 days ago?
> This may have been fixed:
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c?rev=1.291=text/x-cvsweb-markup
>
> If not, could you please share the fragment of your config that triggers it?
>
Hi Darren,

  Yes thanks it's been fixed!

SSH segfault when SendEnv is used in .ssh/config

[Tom Murphy]

Hi,

  I upgraded to the June 9th snapshot and noticed ssh segfaults
when I make connections. After a bit of checking in my .ssh/config,
I discovered the SendEnv directive is making is segfault. Not sure
if it has to do with the changes made 2 days ago?

Thanks,
Tom


OpenBSD 6.3-current (GENERIC.MP) #91: Sat Jun  9 20:57:09 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17040445440 (16251MB)
avail mem = 16383688704 (15624MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b288000 (41 entries)
bios0: vendor American Megatrends Inc. version "1.05.07" date 09/29/2017
bios0: PC Specialist LTD N13xWU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET UEFI SSDT SSDT SSDT 
DBGP DBG2 DMAR BGRT ASF! WSMT
acpi0: wakeup devices PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) 
PXSX(S4) RP20(S4) PXSX(S4) RP21(S4) PXSX(S4) RP22(S4) PXSX(S4) RP23(S4) 
PXSX(S4) RP24(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.47 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.07 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.07 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz
cpu5: 

Re: PPPoE disconnecting frequently

[Tom Murphy]

Hi,

  Another thing to check is whether the PPPoE tunnel is trying to negotiate
IPv6. I had this happen with my ISP. I was disconnecting every 5-6 minutes.
I ended up changing my hostname.pppoe0 to:

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev re0 authproto chap \
authname 'u...@example.com' up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::


  It stopped disconnecting me every 5 minutes after that. Even though it's
still using IPv4, something on the other end wasn't liking the fact that I 
"had no IPv6 support" on my side.

Hope this helps,

Tom

802.11n hostap - latency and timeouts

[Tom Murphy]

Hi,

  I'm running my athn(4) device in hostap mode. I noticed, when it's set to
802.11n, I get higher latency (pinging the OpenBSD AP) and disconnections
every few minutes. The Wifi clients are Linux-based (Android and Debian). 

  When I set it back to 802.11g (mode 11g) it's fine again.

  I have athn0 using powersave on too, and when the client has powersave mode
on, the latency goes up and network performance also drops. As soon as I turn
powersave mode off on the client, it goes from being anywhere between
600-1000 ms per ping, to 1-2ms per ping.

  Is there some issue with 802.11n clients when OpenBSD is in hostap 11n mode?
Also is powersave mode a problem. Has anyone tested these and come up with
a good solution? I've tried different channels (can't try 5 GHz because none
of my devices support it except the hostap device)

  Relevant bits from dmesg:

athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:32:ef:9a


  ifconfig athn0

athn0: flags=8843 mtu 1500
lladdr 04:f0:21:32:ef:9a
description: Wifi AP
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect hostap (autoselect mode 11n hostap)
status: active
ieee80211: nwid OpenBSD chan 6 bssid 04:f0:21:32:ef:9a wpakey 
0x0bfuscated wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp 
powersave on (100ms sleep) inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255

  Is there anything I can try to get 802.11n stable?

 Thanks,
  Tom

Re: Can OpenBSD do mixed b/g/n mode in hostap?

[Tom Murphy]

Hi Stefan,

  Many thanks for that explanation! It makes sense. You're right, some
low level code is really difficult to debug!

Kind regards,
Tom

On 07/02/17 20:41, Stefan Sperling wrote:
> On Tue, Feb 07, 2017 at 08:16:10PM +0000, Tom Murphy wrote:
>> Hi Stefan,
>>
>>   I upgraded my kernel to 24 January 2017 and every once in a while I get:
>>
>>   athn0: device timeout
>>
>>   I've gotten 3 of these in 12 days. Running:
>>
>>   ifconfig athn0 down; sh /etc/netstart athn0 
>>
>>   fixes this, but not had this on mode 11g. Could it be something in the 11n
>> hostap code?
>>
> 
> This was already hapening a long time before 11n mode was implemented.
> There is no reason to worry about this message if the AP works otherwise.
> 
> Below I'm quoting my reply to this same question I wrote to somebody
> else a few weeks ago, who also noted that the BUGS section of the
> athn($) man page says that a device timeout "should not happen".
> 
> [[[
> It means we asked the device to transmit a frame, and 5 seconds or so
> later we still did not receive a notification from the device that it
> is done transmitting the frame, as it would normally send us.
> 
> We then assume the device is wedged and reset it. This is mostly
> transparent since the upper layer interface state does not change
> (or changes only briefly).
> 
> So, it should not happen. But it does, and there's no easy way to fix
> it short of debugging this stuff at a very low level, which takes a
> lot of time and effort.
> 
> The simple fact is that the driver isn't perfect.
> ]]]

Re: Can OpenBSD do mixed b/g/n mode in hostap?

[Tom Murphy]

Hi Stefan,

  I upgraded my kernel to 24 January 2017 and every once in a while I get:

  athn0: device timeout

  I've gotten 3 of these in 12 days. Running:

  ifconfig athn0 down; sh /etc/netstart athn0 

  fixes this, but not had this on mode 11g. Could it be something in the 11n
hostap code?

  Thanks,
  Tom

On Wed, Jan 25, 2017 at 10:39:08AM +0100, Stefan Sperling wrote:
> On Tue, Jan 24, 2017 at 09:00:26PM +0000, Tom Murphy wrote:
> > Hi Stefan,
> > 
> >   I've done some more testing. I managed to get 802.11n working in
> > hostap mode for a while but then it crashed (not a kernel panic but the
> > driver dropped into ddb mode). Not sure if these help:
> > 
> > ddb{0}> trace
> > ieee80211_input_ba() at ieee80211_input_ba+0x1af
> > ar5008_rx_intr() at ar5008_rx_intr+0x2de
> > ar5008_intr() at ar5008_intr+0x22d
> > intr_handler() at intr_handler+0x67
> > Xintr_ioapic_level23() at Xintr_ioapic_level23+0xcd
> > --- interrupt ---
> > acpicpu_idle() at acpicpu_idle+0x13c
> > cpu_idle_cycle() at cpu_idle_cycle+0x10
> > end trace frame: 0x0, count: -7
> 
> PLease update to the latest snapshot and try again.
> This particular crash should be fixed as of this commit:
> https://marc.info/?l=openbsd-cvs=148455934902163=2

Re: Can OpenBSD do mixed b/g/n mode in hostap?

[Tom Murphy]

On 15/01/17 20:13, Stefan Sperling wrote:
> On Sun, Jan 15, 2017 at 01:53:41PM +0000, Tom Murphy wrote:
>> Hi,
>>
>>   I was wondering if OpenBSD had a way to do mixed b/g/n mode with hostap?
>> Recently 802.11n support was added for athn(4). I have 4 802.11n devices,
>> but 1 device which only does 802.11g. If I use 'mode 11n' or even -mode,
>> the hostap is in 802.11n-only mode and the 802.11g device cannot connect.
>> Is it possible to do a mixed mode?
>>
>>   Also, is powersave working in hostap mode yet?
>>
>>  Thanks,
>>   Tom
>>
>> athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
>> athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx
> 
> I did test an OpenBSD 11g-only device against my 11n AP. It worked.
> We always have compat with 11a/b/g enabled.
> There is no way to make OpenBSD run as 11n-only as far as I know.
> Perhaps your 11g device does not support WPA2?
> Try again after 'ifconfig athn0 wpaprotos wpa1,wpa2', and understand
> that running this command means your AP is using broken crypto.
> 
> Regarding your second question, yes, athn(4) does support power saving.
> 

Hi Stefan,

  I've done some more testing. I managed to get 802.11n working in
hostap mode for a while but then it crashed (not a kernel panic but the
driver dropped into ddb mode). Not sure if these help:

ddb{0}> trace
ieee80211_input_ba() at ieee80211_input_ba+0x1af
ar5008_rx_intr() at ar5008_rx_intr+0x2de
ar5008_intr() at ar5008_intr+0x22d
intr_handler() at intr_handler+0x67
Xintr_ioapic_level23() at Xintr_ioapic_level23+0xcd
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: -7

ddb{0}> show panic
the kernel did not panic

ddb{0}> show registers
rdi   0x80a10840
rsi   0x80a10080
rbp   0x80002202cc78
rbx   0x80a10808
rdx0
rcx0x588hib_hlt_real+0x283
rax0x588hib_hlt_real+0x283
r80x80a10870
r9  0x80mptramp_gdt32_desc+0x5e
r10   0x80a1
r11   0xff00099ca002
r120
r13   0x80a10080
r140x8bbhib_hlt_real+0x5b6
r15   0x8071e048
rip   0x81235a9fieee80211_input_ba+0x1af
cs   0x8
rflags   0x10206mptramp_longmode+0x15e
rsp   0x80002202cc18
ss  0x10
ieee80211_input_ba+0x1af:   cmpq$0,0(%rax)

hostname.athn0:

inet 10.0.0.1 255.255.255.0 NONE media autoselect mediaopt hostap nwid
MyHome
wpa wpakey 'redacted' description "Wifi AP"

ifconfig athn0:

athn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 04:f0:21:14:c5:07
description: Wifi AP
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect hostap)
status: active
ieee80211: nwid MyHome chan 1 bssid 04:f0:21:14:c5:07 wpakey
0xdeadbeef


dmesg:
OpenBSD 6.0-current (GENERIC.MP) #134: Fri Jan 13 07:10:19 MST 2017
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error
ff<clock_battery,ROM_cksum,config_unit,memory_size,fixed_disk,invalid_time>
real mem = 4246003712 (4049MB)
avail mem = 4112740352 (3922MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3)
UOH3(S3) UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.14 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: TSC frequency 1000140300 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
c

Can OpenBSD do mixed b/g/n mode in hostap?

[Tom Murphy]

Hi,

  I was wondering if OpenBSD had a way to do mixed b/g/n mode with hostap?
Recently 802.11n support was added for athn(4). I have 4 802.11n devices,
but 1 device which only does 802.11g. If I use 'mode 11n' or even -mode,
the hostap is in 802.11n-only mode and the 802.11g device cannot connect.
Is it possible to do a mixed mode?

  Also, is powersave working in hostap mode yet?

 Thanks,
  Tom

athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx

Re: httpd, SlowCGI, POST_MAX and 413 Payload Too Large

[Tom Murphy]

There seems to be an inherit problem with httpd.conf.

Say you have two servers:

server foo.net {
  listen on egress port 80
  root /foo_net
  ...
  Other options here
  ...
}

server bar.foo.net {
  listen on egress port 80
  root /bar_foo_net

  connection { max request body 8388608 }
}

When httpd.conf parses this config, it believes foo.net is the parent.
But since foo.net has no connection { max request body  } parameter,
it uses the #define SERVER_MAXREQUESTBODY value which is 1048576.

However, if you add connection { max request body 8388608 } to the
server foo.net stanza, all of the sudden the max request body works
for bar.foo.net.. however, if will ONLY use what foo.net has.
You can't override it with a different value for bar.foo.net.

I believe this is down to the behavior in config.c, line 454, in function
config_getserver_config:

srv_conf-maxrequestbody = parent-maxrequestbody;

It is always set to the parent's maxrequestbody.

Is this by design?

Thanks,
Tom

Re: i386 or amd64?

[Tom Murphy]

On 2011-08-06, Stuart Henderson wrote:
 On 2011-08-05, System Administrator wrote:
 Looking to build a firewall for a fairly busy (25+mb) site. Hardware is 
 Dell PE2850, 2 Xeon 64-bit CPUs, 4GB RAM, 6 em(4) interfaces. Software 
 is primarily pf(4) and relayd(8).

 Not so long ago the recommendation was to use the i386 build for a 
 slight perfomance and stability benefit. Is that still the case? What 
 are the advantages and shortcomings of amd64?

 Thanks in advance.



25Mb/s isn't much for the hardware you have. If you're really bothered
then benchmark/test it *in your setup* but either will probably work fine.

We run sustained 30 MBits/sec (with spikes up to 80-100 Mbits/sec) on a pair
of Dell R200s with no problems.

em0 at pci2 dev 0 function 0 Intel PRO/1000 PT (82571EB) rev 0x06: apic 2 int 
16 (irq 15)
em1 at pci2 dev 0 function 1 Intel PRO/1000 PT (82571EB) rev 0x06: apic 2 int 
17 (irq 14)
bge0 at pci3 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1 (0x4201): 
apic 2 int 16 (irq 15)\
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
bge1 at pci4 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1 (0x4201): 
apic 2 int 17 (irq 14)
brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0

This is 4.9-RELEASE and i386 (box had i386 4.4 on already, prior to upgrade
so I thought no need to install amd64 on it as it only has 2G of RAM on it.

In addition, that box happily can do up to 200k packets/sec as well.

I think a PE2850 with 4G of RAM for a firewall is overkill for 25 Megabits/s.

Tom


Tom

Re: splassert: assertwaitok: want -1 have 1 (bnx)

[Tom Murphy]

On Wed, Jun 29, 2011 at 08:27:24PM -0400, Ted Unangst wrote:
 On Thu, 30 Jun 2011, David Gwynne wrote:
 
   This driver is filled with bad juju.  This changes all the waitoks to not 
   ok, so they are interrupt safe.  It already appears to handle the failure 
   case.  The rwlock is also totally unsafe and unnecessary.
  
  the issue is that bnx_init is called from softclock when it looks like bnx 
  doesnt get any interrupts (so it doesnt do tx completions). i assumed 
  bnx_init was only called from the ioctl paths which have process context.
  
  this diff is also unsafe because you still init the pool with the nointr 
  allocator, but you're trying to fix the code so bnx_alloc_pkts via bnx_init 
  is ok to call from interrupt context.
  
  a simpler fix would be to have bnx_watchdog use the system workq to call 
  bnx_init to reset the chip.
 
 as you wish...  :) I agree it's much simpler.  Still needs testing.
 
 Index: if_bnx.c
 ===
 RCS file: /home/tedu/cvs/src/sys/dev/pci/if_bnx.c,v
 retrieving revision 1.95
 diff -u -r1.95 if_bnx.c
 --- if_bnx.c  22 Jun 2011 16:44:27 -  1.95
 +++ if_bnx.c  30 Jun 2011 00:25:38 -
 @@ -5125,7 +5125,7 @@
  
   /* DBRUN(BNX_FATAL, bnx_breakpoint(sc)); */
  
 - bnx_init(sc);
 + workq_add_task(NULL, 0, (workq_fn)bnx_init, sc, NULL);
  
   ifp-if_oerrors++;
  }

Ted -

   Would this diff work against 4.9-RELEASE? Or do I need to be running
current? It only appears to happen on bnx0. I have 3 other bnx interfaces
and they don't trigger this.

   Tom

Re: splassert: assertwaitok: want -1 have 1 (bnx)

[Tom Murphy]

Here are my vmstat -iz and pcidump -vxx outputs:

vmstat -iz:

interrupt   total rate
irq0/clock1481628  399
irq0/ipi41235   11
irq144/acpi000
irq112/ppb0 00
irq112/bnx0438325  118
irq113/bnx1 00
irq96/ehci0210
irq112/bnx2   9178557 2477
irq113/bnx3   9804951 2646
irq96/ehci1470
irq97/ahci0 122933
irq145/com0 00
irq146/com1 00
Total20957057 5656

pcidump -vxx:

Domain /dev/pci0:
 0:0:0: Intel Core DMI
0x: Vendor ID: 8086 Product ID: d130
0x0004: Command:  Status ID: 0010
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 11
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 10
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1028 Product ID: 02a5
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0x0060: Capability 0x05: Message Signaled Interrupts (MSI)
0x0090: Capability 0x10: PCI Express
Link Speed: 2.5 / 2.5 Gb/s Link Width: x4 / x4
0x00e0: Capability 0x01: Power Management
0x: d1308086 0010 0611 0010
0x0010:    
0x0020:    02a51028
0x0030:  0060  
0x0040:    
0x0050: fed18001   
0x0060: 01029005   
0x0070:    
0x0080:    
0x0090: 0041e010 8020 000e 00393c41
0x00a0: 3041  07c0 0006
0x00b0:  003e 000a 
0x00c0: 0001   
0x00d0:    
0x00e0: c8030001 0008  
0x00f0:    
 0:3:0: Intel Core PCIE
0x: Vendor ID: 8086 Product ID: d138
0x0004: Command: 0147 Status ID: 0010
0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 11
0x000c: BIST: 00 Header Type: 01 Latency Timer: 00 Cache Line Size: 10
0x0010: 
0x0014: 
0x0018: Primary Bus: 0 Secondary Bus: 1 Subordinate Bus: 1
Secondary Latency Timer: 00
0x001c: I/O Base: f0 I/O Limit: 00 Secondary Status: 2000
0x0020: Memory Base: d400 Memory Limit: d9f0
0x0024: Prefetch Memory Base: fff1 Prefetch Memory Limit: 0001
0x0028: Prefetch Memory Base Upper 32 Bits: 
0x002c: Prefetch Memory Limit Upper 32 Bits: 
0x0030: I/O Base Upper 16 Bits:  I/O Limit Upper 16 Bits: 
0x0038: Expansion ROM Base Address: 
0x003c: Interrupt Pin: 01 Line: 00 Bridge Control: 0007
0x0040: Capability 0x0d: PCI-PCI
0x0060: Capability 0x05: Message Signaled Interrupts (MSI)
0x0090: Capability 0x10: PCI Express
Link Speed: 5.0 / 5.0 Gb/s Link Width: x4 / x16
0x00e0: Capability 0x01: Power Management
0x: d1388086 00100147 06040011 00010010
0x0010:   00010100 20f0
0x0020: d9f0d400 0001fff1  
0x0030:  0040  00070100
0x0040: 600d 02a51028  
0x0050:    
0x0060: 01029005   
0x0070:    
0x0080:    
0x0090: 0142e010 8021 0001002f 01393d02
0x00a0: 30420040 00080c80 03e8 0001000f
0x00b0:  003e 000a 
0x00c0: 0002   
0x00d0:    
0x00e0: c8030001 0008  
0x00f0:    
 0:8:0: Intel Core Management
0x: Vendor ID: 8086 Product ID: d155
0x0004: Command:  Status ID: 0010
0x0008: Class: 08 Subclass: 80 Interface: 00 Revision: 11
0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 10
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
   

Re: splassert: assertwaitok: want -1 have 1 (bnx)

[Tom Murphy]

On Wed, Jun 29, 2011 at 08:27:24PM -0400, Ted Unangst wrote:
 On Thu, 30 Jun 2011, David Gwynne wrote:
 
   This driver is filled with bad juju.  This changes all the waitoks to not 
   ok, so they are interrupt safe.  It already appears to handle the failure 
   case.  The rwlock is also totally unsafe and unnecessary.
  
  the issue is that bnx_init is called from softclock when it looks like bnx 
  doesnt get any interrupts (so it doesnt do tx completions). i assumed 
  bnx_init was only called from the ioctl paths which have process context.
  
  this diff is also unsafe because you still init the pool with the nointr 
  allocator, but you're trying to fix the code so bnx_alloc_pkts via bnx_init 
  is ok to call from interrupt context.
  
  a simpler fix would be to have bnx_watchdog use the system workq to call 
  bnx_init to reset the chip.
 
 as you wish...  :) I agree it's much simpler.  Still needs testing.
 
 Index: if_bnx.c
 ===
 RCS file: /home/tedu/cvs/src/sys/dev/pci/if_bnx.c,v
 retrieving revision 1.95
 diff -u -r1.95 if_bnx.c
 --- if_bnx.c  22 Jun 2011 16:44:27 -  1.95
 +++ if_bnx.c  30 Jun 2011 00:25:38 -
 @@ -5125,7 +5125,7 @@
  
   /* DBRUN(BNX_FATAL, bnx_breakpoint(sc)); */
  
 - bnx_init(sc);
 + workq_add_task(NULL, 0, (workq_fn)bnx_init, sc, NULL);
  
   ifp-if_oerrors++;
  }

With the above patch, the splasserts go away. However, the device still goes 
into a weird stats where it
says it's active but no interrupts are generated. When I run ifconfig bnx0 
down; ifconfig bnx0 up, it comes
back fine for a while, but goes down after an unspecified amount of time.

Tom

splassert: assertwaitok: want -1 have 1 (bnx)

[Tom Murphy]

Hi,

  I'm getting the following messages on a network interface:

/bsd: bnx0: Watchdog timeout occurred, resetting!
/bsd: splassert: assertwaitok: want -1 have 1
/bsd: Starting stack trace...
/bsd: assertwaitok() at assertwaitok+0x1c
/bsd: pool_get() at pool_get+0x95
/bsd: bnx_alloc_pkts() at bnx_alloc_pkts+0x31
/bsd: bnx_init_tx_chain() at bnx_init_tx_chain+0x13
/bsd: bnx_init() at bnx_init+0x18c
/bsd: bnx_watchdog() at bnx_watchdog+0x4d
/bsd: if_slowtimo() at if_slowtimo+0x5c
/bsd: softclock() at softclock+0x291
/bsd: softintr_dispatch() at softintr_dispatch+0x5d
/bsd: Xsoftclock() at Xsoftclock+0x2d
/bsd: --- interrupt ---
/bsd: end trace frame: 0x0, count: 247
/bsd: 0x8:
/bsd: End of stack trace.
/bsd: splassert: assertwaitok: want -1 have 1
/bsd: Starting stack trace...
/bsd: assertwaitok() at assertwaitok+0x1c
/bsd: malloc() at malloc+0x3c2
/bsd: _bus_dmamap_create() at _bus_dmamap_create+0x53
/bsd: bnx_alloc_pkts() at bnx_alloc_pkts+0x6b
/bsd: bnx_init_tx_chain() at bnx_init_tx_chain+0x13
/bsd: bnx_init() at bnx_init+0x18c
/bsd: bnx_watchdog() at bnx_watchdog+0x4d
/bsd: if_slowtimo() at if_slowtimo+0x5c
/bsd: softclock() at softclock+0x291
/bsd: softintr_dispatch() at softintr_dispatch+0x5d
/bsd: Xsoftclock() at Xsoftclock+0x2d
/bsd: --- interrupt ---
/bsd: end trace frame: 0x0, count: 246
/bsd: 0x8:
/bsd: End of stack trace.

(repeats the above with exactly the same messages 2 or 3 times more)

bnx0 is plugged directly into an em0 on another machine. The two machines 
exchange
pfsync packets over those interfaces. Machine is a Dell PowerEdge R210 running 
4.9-RELEASE.
Could it be bad network cable or bad hardware?

Here's my dmesg:

OpenBSD 4.9 (GENERIC.MP) #819: Wed Mar  2 06:57:49 MST 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3210317824 (3061MB)
avail mem = 3110838272 (2966MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xbf79c000 (63 entries)
bios0: vendor Dell Inc. version 1.5.2 date 10/18/2010
bios0: Dell Inc. PowerEdge R210
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DM__ MCFG WD__ SLIC ERST HEST BERT EINJ 
TCPA SSDT
acpi0: wakeup devices PCI0(S5) USBA(S0) USBB(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2394.31 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT
T,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 132MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2393.99 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT
T,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2393.98 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT
T,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2393.98 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HT
T,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (LYD0)
acpiprt2 at acpi0: bus -1 (LYD2)
acpiprt3 at acpi0: bus -1 (HVD0)
acpiprt4 at acpi0: bus -1 (HVD2)
acpiprt5 at acpi0: bus 2 (PEX0)
acpiprt6 at acpi0: bus -1 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpiprt8 at acpi0: bus 3 (COMP)
acpicpu0 at acpi0: C3, C1
acpicpu1 at acpi0: C3, C1
acpicpu2 at acpi0: C3, C1
acpicpu3 at acpi0: C3, C1
ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca8/8 spacing 4
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core DMI rev 0x11
ppb0 at pci0 dev 3 function 0 Intel Core PCIE rev 0x11: apic 0 int 16 (irq 0)
pci1 at ppb0 bus 1
bnx0 at pci1 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 16 (irq 
15)
bnx1 at pci1 dev 0 function 1 Broadcom BCM5709 rev 0x20: apic 0 int 17 (irq 
10)
Intel Core Management rev 0x11 at pci0 dev 8 function 0 not configured
Intel Core Scratch rev 0x11 at pci0 dev 8 function 1 not configured
Intel Core Control rev 0x11 at pci0 dev 8 function 2 not configured
Intel Core Misc rev 0x11 at pci0 dev 8 function 3 not configured
Intel Core QPI Link rev 0x11 at 

Re: Need some input about: OpenBSD 4.9/amd64 and Dell PowerEdge Server R210,R410,R610,R710

[Tom Murphy]

I run a firewall that sustains anywhere from 10-50 megabits/sec on it 
on a pair of R210 machines. Both are running 4.9-RELEASE amd64 MP just
fine. I did tweak some stuff in the BIOS, namely, I disabled 
virtualization and set the IRQs to default in it. Though I believe
the work in the area of interrupts has been improved in -current.
5.0 should run even more smoothly. I had no problems with these R210s
except for when pfsync was up but one of the interfaces on the CARP
backup had no link. The master CARP machine sort of fell over, but I
was unable to get a trace. I've had no problems since, however.

Tom

Re: altq cripples other connections as well

[Tom Murphy]

Can someone recommend what the qlimit and tbr should be when throttling
a connection to just under 100 megabits?

One of my concerns is we have an OpenVPN running with UDP. Lots of
dropped packets would be rather catastrophic for it.

Thanks,
Tom

altq cripples other connections as well

[Tom Murphy]

I had set up ALTQ on a 4.9 firewall box as a box in our network needed
its sending throttled, but I noticed that while the firewall was
throttling this machine in question, ALL connections going through the
machine were adversely affected and slow. Interactive SSH sessions had
sometimes 1-2 seconds up to 10 seconds before keystrokes showed up.

Once the machine had stopped sending all its traffic, things were fine
again.

I am not sure if the hotplug ppb and em(4) / bge(4) issue of shared
interrupts could be applied here or not. The box happily forwards
traffic without lag if I turn ALTQ off on it. However, this is not
an option as we cannot go past 100 megabits on our connection.

I also noticed I had to jack qlimit up to 8000 to stop getting lots of
packets being dropped. 

Machine is a Dell PowerEdge R210. It's running amd64. I tried i386 on it
and it was unstable, so switched it to amd64. 

Yes, it has ipmi enabled, but ipmi does not appear to cause any issues.
It's only when ALTQ is enabled.

Any ideas? Would this stuff be fixed in -current? I'd try -current on
it, but need to convince management.

Thanks,
Tom

The altq line in /etc/pf.conf:

altq on em0 priq bandwidth 95Mb qlimit 8000 queue { bulk, std, mail,
ssh, web, vpn, dns, ack }


dmesg:

OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar  2 07:19:02 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (GenuineIntel
686-class) 2.21 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM
real mem  = 1071947776 (1022MB)
avail mem = 1044254720 (995MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/24/07, BIOS32 rev. 0 @ 0xfadd0,
SMBIOS rev. 2.5 @ 0x3ff9c000 (46 entries)
bios0: vendor Dell Inc. version 1.0.0 date 10/24/2007
bios0: Dell Inc. PowerEdge R200
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT
EINJ SSDT SSDT SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (GenuineIntel
686-class) 2.21 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (SBE0)
acpiprt3 at acpi0: bus 3 (SBE4)
acpiprt4 at acpi0: bus 4 (SBE5)
acpiprt5 at acpi0: bus 5 (COMP)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
bios0: ROM list: 0xc/0x9000 0xec000/0x4000!
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca8/8 spacing 4
cpu0: Enhanced SpeedStep 2201 MHz: speeds: 2200, 2000, 1800, 1600, 1400,
1200 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
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: apic 2
int 16 (irq 15)
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: apic 2 int
16 (irq 15)
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 Intel PRO/1000 PT (82571EB) rev 0x06:
apic 2 int 16 (irq 15), address 00:15:17:6c:c7:a2
em1 at pci2 dev 0 function 1 Intel PRO/1000 PT (82571EB) rev 0x06:
apic 2 int 17 (irq 14), address 00:15:17:6c:c7:a3
ppb2 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02
pci3 at ppb2 bus 3
bge0 at pci3 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1
(0x4201): apic 2 int 16 (irq 15), address 00:19:b9:fa:59:20
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb3 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02
pci4 at ppb3 bus 4
bge1 at pci4 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1
(0x4201): apic 2 int 17 (irq 14), address 00:19:b9:fa:59:21
brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
uhci0 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 2 int
21 (irq 11)
uhci1 at pci0 dev 29 function 1 Intel 82801I USB rev 0x02: apic 2 int
20 (irq 10)
uhci2 at pci0 dev 29 function 2 Intel 82801I USB rev 0x02: apic 2 int
21 (irq 11)
ehci0 at pci0 dev 29 function 7 Intel 82801I USB rev 0x02: apic 2 int
21 (irq 11)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x92
pci5 at ppb4 bus 5
vga1 at pci5 dev 5 function 0 ATI ES1000 rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 19 (irq 

Re: altq cripples other connections as well

[Tom Murphy]

Stuart Henderson wrote:
 Watch 'systat q' or 'pfctl -vvsq' and check that packets are being
 assigned to the expected queues..

I get this (sorry for the wonky formatting):

QUEUE BW SCH  PRIO PKTSBYTES DROP_P   
DROP_B QLEN BORROW SUSPEN P/S B/S
bulk priq   1333079 1611153K 000
std  priq2 29649766   27725M 30364 40897687 
   0
mail priq9 79223719   88413M 5363  7279626  
  0
ssh  priq   10  1420163  103931K 000
web  priq   12  2650944 3078267K 72956180
vpn  priq   13 11907422 9255256K 000
dns  priq   14 11147040  982677K 000
ack  priq   15 48287941 2899340K 000

The offending machine that was sending out a ton of traffic had been
relegated to the bulk queue that had the lowest priority.

Despite that, ssh connections were stuttering, even though they had
higher priority.

Tom

Re: pfsync bulk transfer performance

[Tom Murphy]

Kapetanakis Giannis wrote:
 Hi,

 I'd like to ask if it's normal for pfsync bulk transfer to take 5-15
 minutes to end for 60k states.

 pfsync is on a dedicated gigabit interface on both firewalls.

I've seen this too. On a pair of 4.9-release firewalls. If I reboot the
master, it can take up to 15 minutes for it (which is the preferred master)
to become master again.

Another thing I found was, if the backup goes down.. the master goes a bit
crazy and was livelocking on me. I don't know if that was down to pfsync
being strange or something else. I'd test it again, but these are 
production machines and I have no way of simulating 50-60k states being
transferred between machines, otherwise I'd set up two test machines with
that.

Tom

lii(4) causes panic when attempting to nfs_boot

[Tom Murphy]

While attempting to network boot my Asus EEE with its lii(4) wired ethernet, I 
get an error and panic
when it attempts to boot via nfs_boot.

When I hook the network cable up to a switch to watch the link, it stays on 
until the kernel boots,
then goes off during the devices detection, then goes back on briefly, then 
turns off before it
tries to do the nfs_mount root.

Thinking it could be a slow PHY, I modified line 1020 in netinet/if_ether.c to 
read:
result = tsleep((caddr_t)myip, PSOCK, revarp, hz*20);

However, all this did was make the kernel wait forever at the nfs_boot: line. 
I watched
for link light again, and it stayed off almost the whole time, flickered for 
about quarter
of a second, then went out again.

For comparison, I hooked up another laptop (an Acer TravelMate with a bce(4) 
ethernet device)
and attempted to boot diskless with it with the same kernel and config (except 
for changing
the MAC address in /etc/ethers and dhcpd.conf) and it worked fine.

I'm thinking it could have something to do with the lii(4) driver. Attached is 
the panic
with trace and ps as well as a dmesg of the machine when it boots normally 
(with the kernel
on a USB stick.)

Tom


PXE boot MAC address 00:22:15:14:89:d6, interface lii0
nfs_boot: using interface lii0, with revarp  bootparams
panic: reverse arp not answered by rarpd(8) or dhcpd(8)
Stopped at  Debugger+0x4:   popl%ebp
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING WITHOUT INCLUDING THAT INFORMATION!
ddb trace
Debugger(d08dea35,d0ba3cd4,d08d2434.d0ba3cd4,d156a094) at Debugger+0x4
panic(d08d2434,d156a094,d0ba3d18,d0a2f500,746f6f) at panic+0x5d
nfs_boot_init(d0ba3df0,d0a2f500,128,d03ec0f9,a) at nfs_boot_init+0x3ca
nfs_mountroot(d08b4257,0,d08b9faa,0,0) at nfs_mountroot+0x4c
main(d02004ba,d02004c2,0,0,0) at main+0x57b
ddb ps
   PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
10  0  0  0  30x100200  bored crypto
 9  0  0  0  30x100200  pftm  pfpurge
 8  0  0  0  30x100200  usbtskusbtask
 7  0  0  0  30x100200  usbatsk   usbatsk
 6  0  0  0  30x100200  bored intelrel
 5  0  0  0  30x100200  acpi0 acpi0
 4  0  0  0  30x100200  bored syswq
 3  0  0  0  30x100200idle0
 2  0  0  0  3  0x40100200  kmalloc   kmthread
 1  0  0  0  30x100200  initexec  swapper
*0 -1  0  0  7 0x80200swapper


OpenBSD 4.9-current (GENERIC) #0: Thu Apr 28 21:01:49 BST 2011
r...@jera.pertho.net:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) M processor 900MHz (GenuineIntel 686-class) 631 MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF
real mem  = 527527936 (503MB)
avail mem = 508755968 (485MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/11/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS 
rev. 2.5 @ 0xf06e0 (37 entries)
bios0: vendor American Megatrends Inc. version 1302 date 03/11/2009
bios0: ASUSTeK Computer INC. 701
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC OEMB MCFG
acpi0: wakeup devices P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) MC97(S4) 
USB1(S3) USB2(S3) USB3(S3) USB4(S3) EUSB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 70MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P0P3)
acpiprt2 at acpi0: bus 3 (P0P5)
acpiprt3 at acpi0: bus 1 (P0P6)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2
acpitz0 at acpi0: critical temperature 90 degC
acpibat0 at acpi0: BAT0 model 701 serial   type LION oem ASUS
acpiac0 at acpi0: AC unit online
acpiasus0 at acpi0
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
acpivideo0 at acpi0: VGA_
bios0: ROM list: 0xc/0xf800! 0xcf800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82915GM Host rev 0x04
vga1 at pci0 dev 2 function 0 Intel 82915GM Video rev 0x04
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 1 int 16
drm0 at inteldrm0
Intel 82915GM Video rev 0x04 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801FB HD Audio rev 0x04: apic 1 int 
16
azalia0: codecs: Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x04: apic 1 int 16
pci1 at ppb0 bus 4
ppb1 at pci0 dev 28 function 1 Intel 

Re: network bandwith with em(4)

[Tom Murphy]

I fixed my issue. I demoted the OpenBSD 4.4 machine so the 4.8 one took 
over as CARP master, downed pfsync0 on both machines and now the 4.8
box is happily passing tons of packets. It was pfsync0 that was messing
up 4.8 even with defer: off it was struggling.

Going to test it for about a week, then upgrade the remaining 4.4 box
to 4.8. Thank goodness it wasn't a hardware issue.

Tom

Re: network bandwith with em(4)

[Tom Murphy]

Hi,

  I had a pair of Dell PowerEdge R200s that have both em(4) and bge(4)s 
in them, however, it's the em(4) doing the heavy lifting. Roughly 30-40 
megabits/s sustained and doing anywhere between 3000-4000 packets/s.

  On OpenBSD 4.4, it happily forwards packets along. I upgraded one of 
the firewalls to 4.8 and switched CARP over to it (yes, I know the 
redundancy is broken anyway now.) and it couldn't seem to handle the 
traffic. Any inbound connections would stall and I have no idea why.

  There were no net.inet.ip.ifq.drops, but I noticed 10 livelocks when
running systat mbufs (on em0). Could MCLGETI be hindering performance?
Is there anything I can try?

   Tom

OpenBSD 4.8 (GENERIC) #136: Mon Aug 16 09:06:23 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (GenuineIntel 686-class) 
2.21 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST
,TM2,SSSE3,CX16,xTPR,PDCM
real mem  = 1071947776 (1022MB)
avail mem = 1044451328 (996MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/24/07, BIOS32 rev. 0 @ 0xfadd0, SMBIOS 
rev. 2.5 @ 0x3ff9c000 (46 entries)
bios0: vendor Dell Inc. version 1.0.0 date 10/24/2007
bios0: Dell Inc. PowerEdge R200
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ SSDT 
SSDT SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 200MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (SBE0)
acpiprt3 at acpi0: bus 3 (SBE4)
acpiprt4 at acpi0: bus 4 (SBE5)
acpiprt5 at acpi0: bus 5 (COMP)
acpicpu0 at acpi0: PSS
bios0: ROM list: 0xc/0x9000 0xec000/0x4000!
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2201 MHz: speeds: 2200, 2000, 1800, 1600, 1400, 1200 
MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
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: apic 2 int 16 
(irq 15)
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: apic 2 int 16 (irq 
15)
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 Intel PRO/1000 PT (82571EB) rev 0x06: apic 2 int 
16 (irq 15), address 00:15:17:6c:c7:a2
em1 at pci2 dev 0 function 1 Intel PRO/1000 PT (82571EB) rev 0x06: apic 2 int 
17 (irq 14), address 00:15:17:6c:c7:a3
ppb2 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02
pci3 at ppb2 bus 3
bge0 at pci3 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1 (0x4201): 
apic 2 int 16 (irq 15), address 00:19:b9:fa:59:20
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb3 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02
pci4 at ppb3 bus 4
bge1 at pci4 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1 (0x4201): 
apic 2 int 17 (irq 14), address 00:19:b9:fa:59:21
brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
uhci0 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 2 int 21 (irq 
11)
uhci1 at pci0 dev 29 function 1 Intel 82801I USB rev 0x02: apic 2 int 20 (irq 
10)
uhci2 at pci0 dev 29 function 2 Intel 82801I USB rev 0x02: apic 2 int 21 (irq 
11)
ehci0 at pci0 dev 29 function 7 Intel 82801I USB rev 0x02: apic 2 int 21 (irq 
11)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x92
pci5 at ppb4 bus 5
vga1 at pci5 dev 5 function 0 ATI ES1000 rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 2 int 19 (irq 5)
drm0 at radeondrm0
ichpcib0 at pci0 dev 31 function 0 Intel 82801IR LPC rev 0x02: PM disabled
pciide0 at pci0 dev 31 function 2 Intel 82801I SATA rev 0x02: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 2 int 23 (irq 6) for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: WDC WD1601ABYS-18C0A0
wd0: 16-sector PIO, LBA48, 152587MB, 31250 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: HL-DT-ST, CDRW/DVD GCCT10N, A102 ATAPI 5/cdrom 
removable
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
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 revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at ichpcib0

Re: network bandwith with em(4)

[Tom Murphy]

Ryan McBride wrote:
 On Thu, Mar 10, 2011 at 12:18:32PM +, Tom Murphy wrote:
I had a pair of Dell PowerEdge R200s that have both em(4) and bge(4)s 
  in them, however, it's the em(4) doing the heavy lifting. Roughly 30-40 
  megabits/s sustained and doing anywhere between 3000-4000 packets/s.
 
   On OpenBSD 4.4, it happily forwards packets along. I upgraded one of 
 the firewalls to 4.8 and switched CARP over to it (yes, I know the 
 redundancy is broken anyway now.) and it couldn't seem to handle the 
 traffic. Any inbound connections would stall and I have no idea why.

I assume that you don't have the 'defer' option set on your pfsync
interface (it would be broken until you upgrade both firewalls)

  Correct. The defer option is off by default and when I looked at
pfsync0 on the 4.8 box it said:

  pfsync: syncdev: bge1 maxupd: 128 defer: off

   There were no net.inet.ip.ifq.drops, but I noticed 10 livelocks when
 running systat mbufs (on em0). 


I think in 4.8 systat mbufs is showing the total number of livelocks
ever, and 10 is a tiny number. On a system nearing it's limit you could
expect the livelocks counter to get hit a few times a second, but if
it's getting hit 50 times per second you're way over capacity.

 Yeah I only had 10 after about 3-4 hours and the number did not increase.

Note you can also look at 'sysctl kern.netlivelocks' which is a little 
less ambiguous, and shows the total number of livelocks since boot.
 
 Thanks! I will bear that in mind.

 Could MCLGETI be hindering performance?  

I'm doing a lot of testing in this area these days on a broad range of 
hardware, and I have yet to find a case where MCLGETI does not improve 
a system's ability to handle load. If anything MCLGETI needs to be more 
aggressive, and we're looking at ways to do that.

  I notice the machines are mostly idle.. between 90-95%. They also use
very little memory (top reports 15-18M of memory used). The 4.8 box
only has 1 gig of RAM, whereas the 4.4 box has 2 gig. It doesn't seem
to make much of a difference in this case. Whichever firewall is active
can handle upwards to about 62000 states during peak times.

  Would it be worth just shutting down pfsync(4) on both machines to
test performance? I wouldn't want pfsync getting in the way since
pfsync is broken anyway. It would be one more variable to remove from
the equation.

  Tom

Re: rum(4) ohci scheduling overruns in current/i386

[Tom Murphy]

Jacob Meuser wrote:
 you're not even using the ohci (i.e. this is most likely bad/dying
 hardware)

On Sat, Dec 04, 2010 at 11:55:49PM +0100, Mattieu Baptiste wrote:
 Hi all,

 I decided to upgrade my soekris net5501 (from a snapshot around
 september 7) to -current. I had in the past random ohci scheduling
 overruns, resulting in an unusable rum(4). But ifconfig down/up solves
 the problem.

 Now I have a lot of ohci scheduling overruns just after boot and my
 rum(4) isn't usable. Here is a dmesg:


Jacob  Mattieu,
  
I get these from time to time on my Soekris net5501 too. A reboot seems
to fix the problem. It is not dying hardware. If it was, I wouldn't
continue to
use the machine.

   Tom

Re: scrotwm hangs X after update to 4.8

[Tom Murphy]

Hi,

  This might be a bit of a long shot, but try:

  Option FramebufferCompression False

  It fixed inteldrm0: gpu hung! messages on my Acer's Intel 845GM
chipset. It might keep it from hanging in yours?

  Tom

Re: PF synproxy - never worked?

[Tom Murphy]

Synproxy only appears to work on the interface with the default gateway
(egress). I could never make it work on a firewall with more than 1
external interface properly.

I don't know if this is a bug or by design.

Tom

Re: openbsd 4.7 pf + route-to question

[Tom Murphy]

I think you need to specify the gateway. On a host I set up
that uses DSL (pppoe(4) so the gw is 0.0.0.1):

pass out on $ext_if1 from $ext_if2 to any route-to ($ext_if2 0.0.0.1)
pass out on $ext_if2 from $ext_if1 to any route-to ($ext_if1 0.0.0.1)

I don't know if your omission of 'to any' affects it, but it could also
be matching a packet further down the list.

I'd stick the route-to at the very bottom of your ruleset, or if you
group them by direction/interface, at the bottom of the pass out on external
interfaces and see if that helps?

Tom

Re: Perl problems in -current

[Tom Murphy]

On Wed, Jul 21, 2010 at 09:32:50PM -0700, Philip Guenther wrote:
 Sounds like it.  Have you checked the release notes/change log for
 versions of mod_perl after the one included in OpenBSD?  Is there a
 newer version in ports (though it would probably require a different
 apache too)?  If so, have you tried that one?
 
 
 Philip Guenther

Well, updating to latest snapshot and pkg_add -u -D update -D updatedepends
seems to have fixed it. Quite possibly there was an issue in base that was
resolved. Anyway, it all works now, thankfully!

Tom

Re: Perl problems in -current

[Tom Murphy]

On Tue, Jul 20, 2010 at 07:01:20PM -0700, Philip Guenther wrote:
 I think I was a bit misleading in my suggestion.  I think you should
 scan the *entire* kdump output to see if it's calling chroot(), for
 example, which will completely screw the lazy-loading used by Carp.pm
 for Carp/Heavy.pm.
 
 ...
   2037 httpdCALL  stat(0x8325f480,0xcfbdac90)
   2037 httpdNAMI  /usr/libdata/perl5/Carp/Heavy.pmc
   2037 httpdRET   stat -1 errno 2 No such file or directory
 
 You confirm that that file exists when you check with the normal root
 directory, which suggests the process is running with some other root
 directory when it is doing the above, no?
 
 
 Philip Guenther

Hi Philip,

  Looking at the line numbering. chroot is called at line 153297 which
is after Exporter/Heavy.pm is read (line 13180) but Carp/Heavy.pm isn't
looked for until line 155196. So the chroot is taking place in between
those times.

  I have tried running apache without chroot, but I get the same error.
I wonder if there is something wrong with mod_perl itself?

  Tom

Re: Perl problems in -current

[Tom Murphy]

On Sun, Jul 11, 2010 at 06:27:41PM -0700, Philip Guenther wrote:
 When in doubt, use a bigger hammer.  You could try using 'ktrace' on
 the web server (probably with the -i option) to see exactly what is
 happening when perl tries to open the Carp/Heavy.pm file.
 
 
 Philip Guenther

Hi Philip,

  ktrace produces a rather large (6M) kdump file. I checked all the paths
below and the only place the file exists is at 
/usr/libdata/perl5/Carp/Heavy.pm. The permissions on the file are root:wheel
and 0444, so it should be readable by anyone. I am not sure why it can't
find this file at all. It seems to find Exporter/Heavy.pm further up in the
trace. Copying that file to one of the other places doesn't help.

  Here are the relevant bits from the trace:

  2037 httpdCALL  stat(0x8325d900,0xcfbdac90)
  2037 httpdNAMI  
/usr/local/lib/perl5/site_perl/5.10.1/i386-openbsd/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  
/usr/local/lib/perl5/site_perl/5.10.1/i386-openbsd/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f180,0xcfbdac90)
  2037 httpdNAMI  /usr/libdata/perl5/i386-openbsd/5.10.1/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /usr/libdata/perl5/i386-openbsd/5.10.1/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f780,0xcfbdac90)
  2037 httpdNAMI  
/usr/local/libdata/perl5/i386-openbsd/5.10.1/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  
/usr/local/libdata/perl5/i386-openbsd/5.10.1/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f480,0xcfbdac90)
  2037 httpdNAMI  /usr/libdata/perl5/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /usr/libdata/perl5/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f080,0xcfbdac90)
  2037 httpdNAMI  /usr/local/libdata/perl5/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /usr/local/libdata/perl5/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f7c0,0xcfbdac90)
  2037 httpdNAMI  
/usr/local/libdata/perl5/site_perl/i386-openbsd/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  
/usr/local/libdata/perl5/site_perl/i386-openbsd/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f580,0xcfbdac90)
  2037 httpdNAMI  /usr/libdata/perl5/site_perl/i386-openbsd/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /usr/libdata/perl5/site_perl/i386-openbsd/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f540,0xcfbdac90)
  2037 httpdNAMI  /usr/local/libdata/perl5/site_perl/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /usr/local/libdata/perl5/site_perl/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f280,0xcfbdac90)
  2037 httpdNAMI  /usr/libdata/perl5/site_perl/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /usr/libdata/perl5/site_perl/Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x88596f60,0xcfbdac90)
  2037 httpdNAMI  ./Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  ./Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x88596fa0,0xcfbdac90)
  2037 httpdNAMI  /var/www//Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpdNAMI  /var/www//Carp/Heavy.pm
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325f580,0xcfbdac90)
  2037 httpdNAMI  /var/www/lib/perl/Carp/Heavy.pmc
  2037 httpdRET   stat -1 errno 2 No such file or directory
  2037 httpdCALL  stat(0x8325d280,0xcfbdabf0)
  2037 httpd   

Re: Perl problems in -current

[Tom Murphy]

Carp/Heavy.pm is actually part of base.
It doesn't make sense that the file is in @INC and still perl cannot find it.

Tom

- Original message -
 On Tue, 06 Jul 2010 11:26:42 +0100 Tom Murphy open...@pertho.net
 wrote:
  
  This error does not occur in 4.7-release. Has there been something up
  with the Perl packages in -current lately?
 
 Marc Espie (espie@) has been doing tons and tons of work on the ports
 system. The packages in question are actually parts of the ports system.
 
 -- 
 The OpenBSD Journal - http://www.undeadly.org

Perl problems in -current

[Tom Murphy]

I'm running the June 20 2010 snapshot on a webserver and was attempting
to get Blogsum
up and running, but I get this error in the log:

[Tue Jul  6 11:21:47 2010] [error] PerlRun: `Can't locate Carp/Heavy.pm
in @INC (@INC contains:
/usr/local/lib/perl5/site_perl/5.10.1/i386-openbsd
/usr/libdata/perl5/i386-openbsd/5.10.1
/usr/local/libdata/perl5/i386-openbsd/5.10.1 /usr/libdata/perl5
/usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd
/usr/libdata/perl5/site_perl/i386-openbsd
/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl .
/var/www/ /var/www/lib/perl) at /usr/libdata/perl5/Carp.pm line 39.\n'

I've tried non-chrooting the web server and the message does not change.
I've checked the file and it does exist and is there. If I run perl on
the command-line, it can see that file just fine. The @INC includes the
file in its paths.

This error does not occur in 4.7-release. Has there been something up
with the Perl packages in -current lately?

Thanks,
Tom

Broken scrub/max-mss in -current

[Tom Murphy]

Hi,

  I just upgraded from June 20th snap to July 5th snap, and noticed the
match ... scrub (max-mss ) lines are completely broken in pf.

  pfctl accepts them, but then I get all sorts of MTU problems. (Things
like ping working, but not http)
I took the lines out and then everything works fine, however, this rule
I had in for ages which had worked fine:

match in all scrub (max-mss 1440)

  With that rule in with the July 5th snap, tcpdump reports:

Jul 06 12:41:33.079144 00:00:24:cb:a6:64 00:90:d0:63:ff:3b 0800 74:
87.194.102.137.50087  195.47.247.250.80:S 1253821828:1253821828(0) win
5840 [bad opt] (DF)

  As soon as I remove the scrub rule out, it works fine again.

  This diff seems to be the culprit:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff?r1=1.121;r2=1.122;f=h

  Tom

Re: relayd to load balance xmpp/jabberd??

[Tom Murphy]

Aaron Martinez wrote:
Greetings everyone,

I am considering setting up a jabberd2 installation of maybe 4-5 servers
and since I haven't seen any built in cluster options I was thinking of
using relayd to load balance the systems.  I have a few questions that
hopefully the list gurus can help with.

I'm wondering  what the thoughts are about whether to use layer 3 vs.
layer 7 for this.

I would definitely want connections to be sticky and i like the route to
options in the layer 3 for this, but not familiar enough w/the xmpp
protocol to know if this is feasible.

Certainly feasible. I loadbalance xmpp with relayd using layer 3.

ext_if=em0
ext_xmpp_addr=aaa.bbb.ccc.ddd

table xmppServers { 192.168.1.1 192.168.1.2 192.168.1.3 }
redirect xmpp {
   listen on $ext_xmpp_addr port 5222 interface $ext_if
   tag xmpp
   forward to xmppServers port 5222 mode roundrobin sticky-address check tcp
}

pf:

pass in on $ext_if inet proto tcp from any to xmppServers port 5222 
pass tagged xmpp

Also, if one of the machines were to become unresponsive that had active
conversations going on, would there be any way to keep them alive and
move to another server?  CARP?? using proxy instead of direct to server?

Run CARP and set up relayd the same on each server. Shouldn't be any
problems.

Lastly, I see there are a few different ways to determine if the hosts
behind relayd are up, I'm wondering if there is any way to determine
this with snmp.  Could the check script directive run an snmpget and
look for some value?  How would relayd determine if the value was good
or bad?

relayd uses a simple TCP connect to check if the xmpp server is up.
If you need something more comprehensive, you might need to write
a script to query it and come back with some suitable result for relayd
to consider the host is up and happy.


Thanks in advance.

Aaron

Hope this helps!

Tom

Multipath with pppoe(4)? Is it possible?

[Tom Murphy]

I have an OpenBSD firewall with two external interfaces which are
pppoe(4). Is it possible to use multipath on them? I tried adding
two default routes with multipath but it would refuse. I don't think
it likes -ifp and 0.0.0.1 being the gateway.

In the meantime, I just have default route set on one of the pppoe(4)s
and use reply-to/route-to for loadbalancing in pf.conf instead.

Surely, there's an easier way to do all this? I can't use trunk(4)
since pppoe(4) is a virtual device.

Does anyone have any suggestions?

Thanks!

Tom

Re: 4.7: doesn't route IPSEC traffic very well

[Tom Murphy]

Toni -
 
   I had an issue like this with March 9 snapshot on one of my firewalls.
The tunnel would go up when I restarted isakmpd on both ends, but then
would stop for no reason. I upgraded to March 17 snapshot and it
seemed to be OK, but I had a nagging feeling it could have been
a routing issue as well.

   (I was using auth hmac-md5 enc aes group modp1536 for both main and
quick.)

   Tom

Re: PF cluestick please - low priority queue spills over into normal queue

[Tom Murphy]

Aaron -

  Not sure if this has been mentioned yet, but maybe you need to
match the inbound traffic so that the related traffic going back
out will fall into the proper queue?

  e.g.

  pass in on $wired_if to $chechemaru queued wired_lo

  I've found with BitTorrent, Soulseek and other P2P-like things, you need
to match the incoming packets as well as they set up related connections
(states) back out.

  Tom

Re: DVD burning software besides cdrecord/growisofs

[Tom Murphy]

See:

http://marc.info/?l=openbsd-portsm=125624603525294w=2

I made the diff orginally, may still apply.
There is also some code in growisofs that checks if you
are burning 4.2 gig or less on a dual-layer DVD and it
will fail because it thinks you are wasting a dual layer DVD
(which you are, actually.. they're expensive.)

cdrtools currently as it is in the tree does not create
.iso images larger than 4.2 gig. I had to hack it to the
latest cdrtools alpha version to make it work properly
for dual-layer DVDs.

Hope this helps!

T

Re: growisofs: more than 50% of space will be *wasted*!

[Tom Murphy]

James Hozier wrote:
 I'm trying to burn an iso image to a dual-layer DVD because that's
 all I have left and don't want to waste any more money than I
 already have with the recent DVD issues I've been having.
 
 How do I force the burning of this iso in growisofs to the DVD?

You will have to hack the growisofs port source code to have it
ignore the size of the image being burned onto the dual-layer
DVD. The author put it in the source code. There's only like
4 lines to change. I used to have a diff handy but it's out
of date now.

T

Re: growisofs: more than 50% of space will be *wasted*!

[Tom Murphy]

Here you go... have a diff. Happy New Year :)

T

--- growisofs_mmc.cpp.orig  Mon Dec 28 02:58:51 2009
+++ growisofs_mmc.cpp   Mon Dec 28 03:00:12 2009
@@ -1622,11 +1622,6 @@ static void plus_r_dl_split (Scsi_Command cmd,off64_t
 blocks = size/2048;
 blocks += 15, blocks = ~15;

-if (blocks = split)
-   fprintf (stderr,:-( more than 50%% of space will be *wasted*!\n
-   use single layer media for this recording\n),
-   exit (FATAL_START(EMEDIUMTYPE));
-
 blocks /= 16;
 blocks += 1;
 blocks /= 2;
@@ -2059,10 +2054,6 @@ pwrite64_t poor_mans_setup (void *fd,off64_t leadout)
layer_size |= dvd_10[4+14]8,
layer_size |= dvd_10[4+15];

-   if (data_size = layer_size)
-   fprintf (stderr,:-( more than 50%% of space will be 
*wasted*!\n
-   use single layer media for this 
recording\n),
-   exit(FATAL_START(EMEDIUMTYPE));
}
if (is_dao  leadout)
minus_r_reserve_track(cmd,leadout);

Re: [PATCH] Fix interrupt handling in ral(4) for RT2661 under load

[Tom Murphy]

I've applied Roland's patch and it works for my ral(4) device:

l0 at pci0 dev 14 function 0 Ralink RT2661 rev 0x00: irq 10, address 
00:14:85:d5:39:bb
ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR)

On my Soekris Net5501, ral0 in ap mode would hang after a while and be 
useless. Now it happily passes packets back and forth.

The only issues I have are this:

1) Wireless clients seem to regularly, randomly drop out for 20-25 
seconds. However, they do reconnect. This is annoying when I am 
ssh'd into the firewall itself as it breaks my ssh connection when
it happens. I've seen messages like these:

ral0: station 00:90:39:bb:00:90 disassociate (reason 7)
ral0: sending disassoc to 00:90:39:bb:00:90 on channel 7 mode 11g

I don't know how else to debug these. The clients happen to be Linux
machines. There seems no way to turn off their powersave mode with
iwconfig. (Two of the clients have rt2860 chips, one has an atheros
chip) I'm not sure if it is powersave in this case or not.

2) ARP packets not being passed between clients. I am able to fix
this by running 'ifconfig ral0 -nwflag nobridge', which resets ral0
and then the clients can see each other again.. until ral0 decides
to reset again.

3) I am seeing Ierrs and Oerrs on the ral0 interface:

NameMtu   Network Address  Ipkts IerrsOpkts Oerrs Colls
ral01500  Link  00:14:85:d5:39:bb  2171582 25832  3508310  2026 0

I'd love to test any further patches to fix the broadcast/multicast
issues. The patch actually makes my RT2661 card usable again which
is great!

Tom

Re: soekris 5501, ral(4) and 4.5-current

[Tom Murphy]

Markus Hennecke wrote:

On Tue, 28 Apr 2009, Tom wrote:


I took my RT2860 card (which likes to lock up the Soekris 5501 fairly
quickly), stuck it in an Openbsd 4.5-current (April 27 snap) and it
performed properly and didn't lock up. Mind you, the machine is amd64
and quite well powered. I transferred a lot of files with scp, got
about 1.2 MB/s on a single transfer which isn't that bad considering
there's about 4-5 access points around or in the building.

The caveat on the ral(4) man page:
   Some PCI ral adapters seem to strictly require a system supporting 
PCI
2.2 or greater and will likely not work in systems based on older 
revi-
sions of the PCI specification.  Check the board's PCI version 
before

purchasing the card.

Does the Soekris net5501-70 support PCI 2.2 or greater? (I couldn't
find anything in the specs or docs of it.)


Is this a PCI or a Mini PCI card? It should not matter, as Mini PCI is 
PCI 2.2. I don't see more than one PCI bus in my soekris dmesg, I 
would assume that the normal PCI connector is PCI 2.2 as well. 

Hi Markus,

   It's a PCI card.

ral0 at pci5 dev 9 function 0 Ralink RT2860 rev 0x00: apic 1 int 18 
(irq 11), address MAC address

ral0: MAC/BBP RT2860 (rev 0x0101), RF RT2820 (MIMO 2T3R)

Regards, 
Tom

Re: soekris 5501, ral(4) and 4.5-current

[Tom Murphy]

Alexander Hall wrote:


I'll second this; from a gw of mine:

$ sudo crontab -l | grep ral0
# Down and up ral0 on failure
*   *   *   *   *   ifconfig ral0 | grep -q OACTIVE  { 
ifconfig \
ral0; echo \n *\n; ifconfig ral0 down; sleep 1; ifconfig ral0 up; 
ifconfig \
ral0; }

/Alexander


Hi Alexander,

  What does the 'OACTIVE' mean? I put that crontab entry in and about 5 times 
already
it came up with OACTIVE in the ifconfig output and it downed the interface and 
brought it back up.
So far the machine has stayed up and hasn't locked up solid yet. Is downing the 
interface and bringing
it back up when it's 'OACTIVE' help prevent the box from locking up?

 Regards,
 Tom