Re: soekris + openbsd server buy question

2010-12-04 Thread Pierre Lamy
I've run both, and agree with this. The Soekris isn't built with very 
good parts (== unstable over time), the Lanner box is a solid performer. 
I'm going to try out the 7535 soon.


Pierre

On 12/4/2010 5:21 PM, Martin Schrvder wrote:

2010/12/3:

Hello, I'm considering buying a Soekris net5501-70 and install OpenBSD on it
to make myself a small server and use it as a proxy (ssh tunnel), it might

Forget Soekris. Get a Lanner FW7530 or similar.

Best
Martin




Re: OpenBGP: announcing network to different peers

2009-03-12 Thread Pierre Lamy
It's really easy, you can send some of the 1's and 0s to peer 21, and 
some 1's and 0's to peer2.


Assuming the halves are contiguous, you would probably announce 2x /21's.

You could also really try and be very specific and announce them as a 
bunch of /32's, this would give you the granularity you are perhaps 
looking for.


In the end, which of the above options you select is based on your 
experience and mad skillz.


Pierre

Eduardo Meyer wrote:

Hello,

I have a /20 and I want a announce half of it to peer21 and the other
half to peer2 only. How am  I expected to do so? Using filters?

Can anyone please mention a working example?




Re: pf does not log all block

2009-03-09 Thread Pierre Lamy
Without the "quick" keyword, pf evaluates all of your rules and if a 
more-permissive rule exists to match the traffic flow, it is used. This 
is different than some commercial firewalls such as Check Point which 
stop when the traffic matches a rule, and the rules are processed in order.


It's common in a pf setup, to block all at the beginning of the security 
rules, without the quick keyword, and then add the pass rules 
afterwards. Anything not matching a pass rule would by default hit your 
first block all rule.


If you are very used to an in-order-stop-when-match firewall then using 
quick on every rule will be more familiar to you, and your block quick 
log all should be at the bottom of your rulebase after the pass rules.


Pierre

patrick keshishian wrote:

On Sun, Mar 8, 2009 at 11:12 AM, Maxx Twayne  wrote:
  

Hi,

I would like to see all blocked packets with pf. And i used this :

block in log on $ext_if all
block out log all

But when i read on pflog0 on the pflog file, i didn't got any blocked
packets.
Only the logged pass that i asked.

Is there any kind of protection, or i did something wrong ?



hard to tell with the small snippet of your pf.conf you included. It
could be a problem with your rule-set that allows everything to pass.
can't tell with the info you provided.

--patrick




Re: high load irq trouble

2008-02-07 Thread Pierre Lamy

Look at everything on interrupt queue 10.

pciide1: using irq 10 for native-PCI interrupt
bge1 at pci3 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
(0x4101): irq 10, address 00:17:08:2c:2a:76
em2 at pci7 dev 6 function 0 "Intel PRO/1000MT QP (82546GB)" rev 0x03: 
irq 10,

address 00:13:21:78:0f:2e
ohci0 at pci0 dev 2 function 0 "NVIDIA nForce4 USB" rev 0xa2: irq 10, 
version


Move bge1 and em2 to different interrupts. And follow Johan's directions...

Pierre

[EMAIL PROTECTED] wrote:

dmesg

OpenBSD 4.2-stable (fw) #0: Wed Dec 12 13:37:05 CET 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/fw
real mem = 2146136064 (2046MB)
avail mem = 2075025408 (1978MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.34 @ 0xf10c0 (45 entries)
bios0: vendor HP version "2.17  " date 09/26/2006
bios0: HP ProLiant DL145 G2
acpi0 at mainbus0: rev 0
acpi0: tables DSDT FACP SSDT SRAT SPCR APIC MCFG BOOT
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpi device at acpi0 from table DSDT not configured
acpi device at acpi0 from table FACP not configured
acpi device at acpi0 from table SSDT not configured
acpi device at acpi0 from table SRAT not configured
acpi device at acpi0 from table SPCR not configured
acpi device at acpi0 from table APIC not configured
acpi device at acpi0 from table MCFG not configured
acpi device at acpi0 from table BOOT not configured
acpiprt at acpi0 not configured
acpiprt at acpi0 not configured
acpiprt at acpi0 not configured
acpiprt at acpi0 not configured
acpiprt at acpi0 not configured
acpiprt at acpi0 not configured
acpiprt at acpi0 not configured
acpicpu0 at acpi0 PSS
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpibtn0 at acpi0: PWRB
ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Opteron(tm) Processor 246, 2000.23 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: AMD erratum 89 present, BIOS upgrade may be required
cpu0: Cool'n'Quiet K8 2000 MHz: speeds: 2000 1800 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1
"NVIDIA nForce4 DDR" rev 0xa3 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 "NVIDIA nForce4 ISA" rev 0xa3
nviic0 at pci0 dev 1 function 1 "NVIDIA nForce4 SMBus" rev 0xa2
iic0 at nviic0: disabled to avoid ipmi0 interactions
iic1 at nviic0: disabled to avoid ipmi0 interactions
ohci0 at pci0 dev 2 function 0 "NVIDIA nForce4 USB" rev 0xa2: irq 10, version
1.0, legacy support
ehci0 at pci0 dev 2 function 1 "NVIDIA nForce4 USB" rev 0xa3: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1
pciide0 at pci0 dev 6 function 0 "NVIDIA nForce4 IDE" rev 0xa2: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 8 function 0 "NVIDIA nForce4 SATA" rev 0xa3: DMA
pciide1: using irq 10 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
ppb0 at pci0 dev 9 function 0 "NVIDIA nForce4 PCI-PCI" rev 0xa2
pci1 at ppb0 bus 1
vga1 at pci1 dev 5 function 0 "NVIDIA GeForce2 MX" rev 0xb2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb1 at pci0 dev 12 function 0 "NVIDIA nForce4 PCIE" rev 0xa3
pci2 at ppb1 bus 2
bge0 at pci2 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
(0x4101): irq 11, address 00:17:08:2c:2a:77
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb2 at pci0 dev 13 function 0 "NVIDIA nForce4 PCIE" rev 0xa3
pci3 at ppb2 bus 3
bge1 at pci3 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
(0x4101): irq 10, address 00:17:08:2c:2a:76
brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb3 at pci0 dev 14 function 0 "NVIDIA nForce4 PCIE" rev 0xa3
pci4 at ppb3 bus 4
pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00pci5 at
pchb0 bus 128
ppb4 at pci5 dev 1 function 0 "AMD 8132 PCIX" rev 0x12
pci6 at ppb4 bus 129
ppb5 at pci6 dev 1 function 0 "Pericom PI7C21P100 PCIX-PCIX" rev 0x01
pci7 at ppb5 bus 130
em0 at pci7 dev 4 function 0 "Intel PRO/1000MT QP (82546GB)" rev 0x03: irq 7,
address 00:13:21:78:0f:2c
em1 at pci7 dev 4 function 1 "Intel PRO/1000MT QP (82546GB)" rev 0x03: irq 5,
address 00:13:21:78:0f:2d
em2 at pci7 dev 6 function 0 "Intel PRO/1000MT QP (82546GB)" rev 0x03: irq 10,
address 00:13:21:78:0f:2e
em3 at pci7 dev 6 function 1 "Intel PRO/1000MT QP (82546GB)" rev 0x03: irq 11,
address 00:13:21:78:0f:2f
"AMD 8132 PCIX IOAPIC" rev 0x

Re: date -u gives wrong timezone output?

2007-04-11 Thread Pierre Lamy
UTC aka Coordinated Universal Time, is the "right now is right now for 
all of us" time, and is coordinated among several entities, irregardless 
of the timezone the parties are in. GMT is a timezone with an offset of 
zero. All timezones are differentials off of UTC; you couldn't just say 
that in parts of England, you don't have a timezone - everyone has a 
timezone. So GMT exists with an offset of zero.


To some people it's just semantics, to others it has great importance. I 
think it's only important to know the difference. But then, I work 
overnights and don't really care that the sun should come up "sooner" 
during summer months, or what day of the week it is.


I think the man page as it stands is fine if the quote below is accurate 
- display or set the time without a zone adjustment.


Pierre

Markus Bergkvist wrote:

So, the man page should say 'Display the UTC in GMT time'?

If I understand it correctly, UTC is the timezone
http://en.wikipedia.org/wiki/ISO_8601#UTC

/Markus

Pierre Lamy wrote:

GMT is the timezone, UTC is the time.

P

jared r r spiegel wrote:

On Tue, Apr 10, 2007 at 06:17:58PM -0400, Nick ! wrote:
 

On 4/10/07, Markus Bergkvist <[EMAIL PROTECTED]> wrote:
   

Hi,

'date -u' on a 4.0 -stable will give something like
Tue Apr 10 22:03:24 GMT 2007
but shouldn't it be
Tue Apr 10 22:03:24 UTC 2007
  

UTC = GMT for all that we care about.
[[http://en.wikipedia.org/wiki/Coordinated_Universal_Time]]


  i could be wrong here, but perhaps he is not suggesting
  that there is any wallclock difference between GMT and UTC,
  but rather that the manpage for date(1) says:

---
 -u  Display or set the date in UTC (Coordinated Universal) 
time.

---

  as opposed to "... date in GMT ...", also as implied by how it is
  '-u' and not '-g'

  least, that was my reaction to his post?




Re: date -u gives wrong timezone output?

2007-04-11 Thread Pierre Lamy
GMT is the timezone, UTC is the time.

P

jared r r spiegel wrote:
> On Tue, Apr 10, 2007 at 06:17:58PM -0400, Nick ! wrote:
>   
>> On 4/10/07, Markus Bergkvist <[EMAIL PROTECTED]> wrote:
>> 
>>> Hi,
>>>
>>> 'date -u' on a 4.0 -stable will give something like
>>> Tue Apr 10 22:03:24 GMT 2007
>>> but shouldn't it be
>>> Tue Apr 10 22:03:24 UTC 2007
>>>   
>> UTC = GMT for all that we care about.
>> [[http://en.wikipedia.org/wiki/Coordinated_Universal_Time]]
>> 
>
>   i could be wrong here, but perhaps he is not suggesting
>   that there is any wallclock difference between GMT and UTC,
>   but rather that the manpage for date(1) says:
>
> ---
>  -u  Display or set the date in UTC (Coordinated Universal) time.
> ---
>
>   as opposed to "... date in GMT ...", also as implied by how it is
>   '-u' and not '-g'
>
>   least, that was my reaction to his post?



Re: Odd issue - in kernel pppoe

2006-12-06 Thread Pierre Lamy

Just to follow up

I was on the right track and with the help of Claudio and Michael was 
able to significantly improve my transfer speeds, latency and my game works.


My additions to pf.conf are

scrub out on $ext_if no-df random-id max-mss 1452
scrub on !$ext_if no-df random-id max-mss 1452

Though I should note that setting just max-mss 1440 did work.

Thanks guys!

Pierre

Pierre Lamy wrote:
Last night I wanted to try out the kernel pppoe rather than userland 
pppoe, on 4.0 GENERIC/i386.


Took me a few minutes but I was able to setup a stable connection, 
surf the net etc. Many thing worked, but one thing didn't. I play an 
online game called Eve Online, and while using in-kernel pppoe I 
wasn't able to log in. pfctl -s showed an established connection 
bidirectionally, but data transfer wasn't happening. My pf rules 
didn't change except to change my ext_if to the pppoe0 connection. 
Here is what my connections look like when they're up


pppoe0: flags=8851 mtu 1492
  dev: de0 state: session
  sid: 0x1c12 PADI retries: 5 PADR retries: 0 time: 00:22:51
  sppp: phase network authproto pap authname "[EMAIL PROTECTED]"
  groups: pppoe egress
  inet6 fe80::2e0:18ff:fea8:9d3a%pppoe0 ->  prefixlen 64 scopeid 0x7
  inet 216.106.102.33 --> 209.87.255.1 netmask 0x

tun0: flags=8051 mtu 1500
  groups: tun egress
  inet6 fe80::2e0:18ff:fea8:9d3a%tun0 ->  prefixlen 64 scopeid 0x8
  inet 216.106.102.33 --> 209.87.255.1 netmask 0x

The only difference I can spot is the MTU, which would actually be 
1492 on tun0 as well, it just isn't reflected in the ifconfig. The 
rest of my internal network is 1500. Should I try playing with my 
internal MTUs, pf rules or something else? Just looking for ideas on 
things to try. Is it possible that my packets are getting fragged on 
the way out, and the remote end drops them?


What did work:

Web, http, smtp, imap, squid, torrents.

I did not test ftp but might do that tonight. Does the in-kernel pppoe 
mangle packets differently than the userland? Is there some odd 
fragmentation code that is different? Should I set my internal network 
to 1492 to prevent any frags from being generated?


Cheers,

Pierre Lamy

-=-

My relevent pf entries

# macros
int_if = "fxp0"
#ext_if = "pppoe0"
ext_if = "tun0"

# options
set skip on lo
set block-policy return
set loginterface $ext_if

# scrub
scrub in all

nat on $ext_if from $int_if:network to any -> ($ext_if)

#Allow pings
pass in quick inet proto icmp all icmp-type $icmp_types keep state

#Pass packets from my allowed array
pass in from $machines to any keep state
pass in from any to $machines keep state
pass out from any to $machines keep state
pass out from $machines to any keep state

#Allow all outgoing connections
pass out on $ext_if proto tcp all keep state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state

And my dmesg

OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 128KB L2 cache) 568 
MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE 


real mem  = 402214912 (392788K)
avail mem = 358699008 (350292K)
using 4256 buffers containing 20213760 bytes (19740K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(aa) BIOS, date 03/03/00, BIOS32 rev. 0 @ 
0xf0520

apm0 at bios0: Power Management spec V1.2 (BIOS mgmt disabled)
apm0: APM power management enable: unrecognized device ID (9)
apm0: APM engage (device 1): power management disabled (1)
apm0: AC on, battery charge unknown
apm0: flags b0102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xda2
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0d10/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:04: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 0 function 0 "ATI Mach64 GW" rev 0x7a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 3 function 0 "Intel 8255x" rev 0x05, i82558: irq 10, 
address 00:e0:18:a8:9d:3a

inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
pcib0 at pci0 dev 4 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 4 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, 19546MB, 40031712 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 

Odd issue - in kernel pppoe

2006-12-05 Thread Pierre Lamy
Last night I wanted to try out the kernel pppoe rather than userland 
pppoe, on 4.0 GENERIC/i386.


Took me a few minutes but I was able to setup a stable connection, surf 
the net etc. Many thing worked, but one thing didn't. I play an online 
game called Eve Online, and while using in-kernel pppoe I wasn't able to 
log in. pfctl -s showed an established connection bidirectionally, but 
data transfer wasn't happening. My pf rules didn't change except to 
change my ext_if to the pppoe0 connection. Here is what my connections 
look like when they're up


pppoe0: flags=8851 mtu 1492
  dev: de0 state: session
  sid: 0x1c12 PADI retries: 5 PADR retries: 0 time: 00:22:51
  sppp: phase network authproto pap authname "[EMAIL PROTECTED]"
  groups: pppoe egress
  inet6 fe80::2e0:18ff:fea8:9d3a%pppoe0 ->  prefixlen 64 scopeid 0x7
  inet 216.106.102.33 --> 209.87.255.1 netmask 0x

tun0: flags=8051 mtu 1500
  groups: tun egress
  inet6 fe80::2e0:18ff:fea8:9d3a%tun0 ->  prefixlen 64 scopeid 0x8
  inet 216.106.102.33 --> 209.87.255.1 netmask 0x

The only difference I can spot is the MTU, which would actually be 1492 
on tun0 as well, it just isn't reflected in the ifconfig. The rest of my 
internal network is 1500. Should I try playing with my internal MTUs, pf 
rules or something else? Just looking for ideas on things to try. Is it 
possible that my packets are getting fragged on the way out, and the 
remote end drops them?


What did work:

Web, http, smtp, imap, squid, torrents.

I did not test ftp but might do that tonight. Does the in-kernel pppoe 
mangle packets differently than the userland? Is there some odd 
fragmentation code that is different? Should I set my internal network 
to 1492 to prevent any frags from being generated?


Cheers,

Pierre Lamy

-=-

My relevent pf entries

# macros
int_if = "fxp0"
#ext_if = "pppoe0"
ext_if = "tun0"

# options
set skip on lo
set block-policy return
set loginterface $ext_if

# scrub
scrub in all

nat on $ext_if from $int_if:network to any -> ($ext_if)

#Allow pings
pass in quick inet proto icmp all icmp-type $icmp_types keep state

#Pass packets from my allowed array
pass in from $machines to any keep state
pass in from any to $machines keep state
pass out from any to $machines keep state
pass out from $machines to any keep state

#Allow all outgoing connections
pass out on $ext_if proto tcp all keep state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state

And my dmesg

OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 128KB L2 cache) 568 MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE

real mem  = 402214912 (392788K)
avail mem = 358699008 (350292K)
using 4256 buffers containing 20213760 bytes (19740K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(aa) BIOS, date 03/03/00, BIOS32 rev. 0 @ 0xf0520
apm0 at bios0: Power Management spec V1.2 (BIOS mgmt disabled)
apm0: APM power management enable: unrecognized device ID (9)
apm0: APM engage (device 1): power management disabled (1)
apm0: AC on, battery charge unknown
apm0: flags b0102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xda2
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0d10/144 (7 entries)
pcibios0: PCI Interrupt Router at 000:04: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 0 function 0 "ATI Mach64 GW" rev 0x7a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 3 function 0 "Intel 8255x" rev 0x05, i82558: irq 10, 
address 00:e0:18:a8:9d:3a

inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
pcib0 at pci0 dev 4 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 4 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, 19546MB, 40031712 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
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, DMA mode 2
uhci0 at pci0 dev 4 function 2 "Intel 82371AB USB" rev 0x01: irq 10
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
piixpm0 at pci0 dev 4 function 3 "In

Re: OpenBSD 4.0 -current + cups-1.2.5p0

2006-12-01 Thread Pierre Lamy

Hint: Try setting the LogLevel to "debug" to find out more.

James Turner wrote:
Well I fixed the permissions problem by chgrp /dev/ulpt0 to _cups. 
However now when I try to print there are no errors and nothing is 
sent to the printer.  This might be my filters problem.  I have a 
MFC-210C and the only "drivers" available are linux ones, but they are 
just a lpr and cups-wrapper shell script.  If anyone has any other 
reasons why it won't print other then the filter I'd appreciate the 
suggestions.




Re: PF/rdr/nat

2006-11-16 Thread Pierre Lamy

Send us a dmesg. How much memory does the box have?

If it will legitimately serve that much traffic, try lowering the Apache 
timeouts to lower than the default (iirc 60 seconds?). Then match those 
timeouts to pf.


Are you using source-hash in the config? That will create a state table 
of already established connections, to bypass cpu-intensive lookups when 
existing connection state sources send more packets.


I think you're on the right track with timeouts, and a little bit of 
tuning should do the trick. If nothing you do is able to mitigate the 
slowdowns, consider using carp to load-balance the traffic.


A couple other things to check which may or may not help: logs for 
system errors, ethernet interface stats (errors etc), MTU size, ethernet 
cable length, free memory stats, other running processes, upgrading to 
the latest version of OpenBSD - I don't know what version you are 
running, and the webserver itself which out of scope for OpenBSD 
problems :)


Have a great day,

Pierre

Sylwester S. Biernacki wrote:

Hi all,

  I was looking for any idea how to tune OBSD with PF, rdr & nat.
  I use rdr round-robin of port 80 to backend webservers using private
  adress space. When packets go back to clients watching webpage PF
  makes nat on them.

  Anyway, if I check it with ~100Mbps of traffic everything goes
  slower and slower and after few minutes clients sees that webserver
  is responding with very long delay to client's requests. However
  after ~15 seconds everything works well for another minute...

  I was reading OpenBSD/PF FAQ, trying to change limits in PF but
  problem still exists.

  After pfctl -x misc the following comes to logs:

Nov 16 08:06:30 ungabunga /bsd: pf: BAD state: TCP 10.0.0.1:80
1.1.1.1:80 2.2.2.23:5027 [lo=1659423809 high=1659488734 win=16384 modulator=0]
[lo=1312540182 high=1312540506 win=65535 modulator=0] 4:4 A seq=1312540182
ack=1659423809 len=1460 ackskew=0 pkts=3188:5511 dir=out,rev

Doest anyone have an idea what I should look for to find what should
be tuned up?


other info:

there are ~2500 state entries.

TIMEOUTS:
tcp.first   120s
tcp.opening  30s
tcp.established   86400s
tcp.closing 900s
tcp.finwait  45s
tcp.closed   90s
tcp.tsdiff   30s
udp.first60s
udp.single   30s
udp.multiple 60s
icmp.first   20s
icmp.error   10s
other.first  60s
other.single 30s
other.multiple   60s
frag 15s
interval 10s
adaptive.start24000 states
adaptive.end  48000 states
src.track 0s

LIMITS:
stateshard limit4
src-nodes hard limit4
frags hard limit4
tableshard limit 1000
table-entries hard limit   10




Re: Bge nic and ifconfig mtu ?

2006-11-14 Thread Pierre Lamy

Your card is not supported in 4.0-release

bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 
(0x4101): apic 4 int 16 (irq 12), address 00:30:48:88:6c:ac


From the bge man page...

The BCM5700, BCM5701, BCM5703 and BCM5704 are capable of supporting 
Jumbo
frames, which can be configured via the interface MTU setting.  
Selecting
an MTU larger than 1500 bytes with the ifconfig(8) utility 
configures the

adapter to receive and transmit Jumbo frames.  Using Jumbo frames can
greatly improve performance for certain tasks, such as file 
transfers and

data streaming.

Cheers,

Pierre

Xavier Beaudouin wrote:

Hello there,

I am trying to change MTU of a bge interface :

# ifconfig bge1 mtu 1504
ifconfig: SIOCSIFMTU: Invalid argument

(MTU is 1504 because some 3550 EMI are in the near of this marchine 
and needs same MTU everywhere to exchange OSPF packets).



Is this normal of does bge interface doesn't support mtu > 1500 ?

Dmesg:

OpenBSD 4.0-current (GENERIC.MP) #944: Tue Sep 26 21:55:34 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,CNXT-ID,CX16 


real mem  = 2144817152 (2094548K)
avail mem = 1948323840 (1902660K)
using 4256 buffers containing 107343872 bytes (104828K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(45) BIOS, date 02/27/06, BIOS32 rev. 0 @ 
0xfa000, SMBIOS rev. 2.3 @ 0xf0800 (49 entries)

bios0: Supermicro P8SCT
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 3.0 @ 0xf/0xcb84
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfca20/336 (19 entries)
pcibios0: PCI Exclusive IRQs: 5 7 10 12
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801FB LPC" rev 0x00)
pcibios0: PCI bus #6 is the last bus
bios0: ROM list: 0xc/0x9400! 0xcc000/0x4000! 0xd/0x3c00!
mainbus0: Intel MP Specification (Version 1.4) (OEM0 PROD)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199 MHz
mainbus0: bus 0 is type PCI
mainbus0: bus 1 is type PCI
mainbus0: bus 2 is type PCI
mainbus0: bus 3 is type PCI
mainbus0: bus 4 is type PCI
mainbus0: bus 5 is type PCI
mainbus0: bus 6 is type PCI
mainbus0: bus 7 is type ISA
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
ioapic1 at mainbus0: apid 5 pa 0xfec84400, version 20, 24 pins
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7221 MCH Host" rev 0x05
ppb0 at pci0 dev 1 function 0 "Intel E7221 PCIE" rev 0x05
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci2 at ppb1 bus 2
ppb2 at pci2 dev 1 function 0 "DEC 21152 PCI-PCI" rev 0x03
pci3 at ppb2 bus 3
ste0 at pci3 dev 4 function 0 "D-Link Systems 550TX" rev 0x12: apic 5 
int 0 (irq 12), address 00:05:5d:e6:1d:ad
ukphy0 at ste0 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 
0x000885, model 0x0023
ste1 at pci3 dev 5 function 0 "D-Link Systems 550TX" rev 0x12: apic 5 
int 1 (irq 5), address 00:05:5d:e6:1d:ae
ukphy1 at ste1 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 
0x000885, model 0x0023
ste2 at pci3 dev 6 function 0 "D-Link Systems 550TX" rev 0x12: apic 5 
int 2 (irq 7), address 00:05:5d:e6:1d:af
ukphy2 at ste2 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 
0x000885, model 0x0023
ste3 at pci3 dev 7 function 0 "D-Link Systems 550TX" rev 0x12: apic 5 
int 3 (irq 10), address 00:05:5d:e6:1d:b0
ukphy3 at ste3 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 
0x000885, model 0x0023

"Intel IOxAPIC" rev 0x09 at pci1 dev 0 function 1 not configured
vga1 at pci0 dev 2 function 0 "Intel E7221 Video" rev 0x05: aperture 
at 0xd040, size 0x800

wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb3 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03
pci4 at ppb3 bus 4
bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 
(0x4101): apic 4 int 16 (irq 12), address 00:30:48:88:6c:ac

brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb4 at pci0 dev 28 function 1 "Intel 82801FB PCIE" rev 0x03
pci5 at ppb4 bus 5
bge1 at pci5 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 
(0x4101): apic 4 int 17 (irq 5), address 00:30:48:88:6c:ad

brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 4 
int 23 (irq 10)

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 82801FB USB" rev 0x03: apic 4 
int 19 (irq 10)

usb1 at uhci1: USB revision 1.0
uhub1 

Re: group ownership of /var/mail

2005-11-26 Thread Pierre Lamy
The problem is that a non-MTA is trying to write something to /var/mail, 
which is bad.

The OpenBSD developers can't account for every third party's wierd way 
of doing things; you did the right thing by mailing the developer, but 
if they can't help you maybe you should switch to a different pop3 
server. You're not going to get any constructive answers here that will 
satisfy you.

J Moore wrote:

>On Sat, Nov 26, 2005 at 04:51:38PM -0700, the unit calling itself Theo de 
>Raadt wrote:
>
>  
>
>>>This leads me to a two-part question:
>>>1. Is there an advantage to assigning group ownership of /var/mail to
>>>"wheel", or was this choice simply arbitrary?
>>>
>>>2. To get akpop3d running should I change group ownership of 
>>>/var/mail to "mail" (rather than giving akpop3d the '-g wheel'
>>>option)?
>>>  
>>>
>
>  
>
>>Locking should (safely) be done by spawing a copy of mail.local
>>for the duration of the operation.  This is designed to be safe
>>even when using NFS spools.
>>
>>NFS spools are the reason people kept running into trouble
>>trying to design something safe.  A few years ago we settled
>>on this method which is safe.
>>
>>Lots of mailer programs want direct access to the spool, and will
>>do it wrong.  Proper locking in an NFS directory like that is hard.
>>This makes it easier.
>>
>>
>
>Let me see if I've got this straight:
>
>sendmail uses mail.local to deliver mail to the user's mail spool, and 
>mail.local uses lock files of the form "username.lock" while it does its 
>thing with the spool file.
>
>However, akpop3d doesn't appear to use this form of the lockfile. If 
>that's the case I don't get the relevance of mail.local.
>
>I can appreciate that file locking in an NFS directory is hard to do; I 
>gather then that the answer to Q 1. is that the choice was not 
>arbitrary. 
>
>If ownership of /var/mail by group "wheel" is not arbitrary, then it 
>would seem that the answer to Q 2. is to run akpop3d with the option 
>'-g wheel'. I would have thought that was not the "best" choice as it 
>entrusts akpop3d with the ability to write anywhere "wheel" is able to - 
>rather than just /var/mail.
>
>Analysis, comments?
>
>Thnx,
>Jay 

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]