Re: mutiple pptp pass-through PF

[Lars Noodén]

Beavis wrote:
> ... I'm trying to run multiple pptp
> connections behind my 2 PF/carp firewalls. ...

You should not be using PPTP.  You have your choice, IPsec with
encryption or SSL with encryption:
http://www.vpnc.org/vpn-standards.html

Allowing PPTP inside your LAN is to encourage use of insecure methods
and technologies that *cannot* be secured.

You've got to move to IPsec sometime, why not now?

If you are dealing with Apple, it may be helpful to reference earlier
bug reports regarding that serious security flaw.  I myself filed
problem ID #5517198, but that is marked as a duplicate of #4316417.

We'll see if they can be assed to fix the gaping holes in the system.

Regards,
-Lars

Re: Compromising a host with pf enabled?

[Clint Pachl]

Chris Zakelj wrote:

Greg Thomas wrote:


 It does say "single" rule.
Yes, but at that point it becomes a rather useless system. It's likely 
to break in curious ways, since anything using the 127.0.0.1 loopback 
will, I think, either become unresponsive or start throwing errors.


Ok, I'm in brainstorm/big-picture mode and wasn't concerning myself with 
the technical details, but I will clarify. pf will block all incoming 
external connections. All traffic will pass on the loopback.

Re: Compromising a host with pf enabled?

[Clint Pachl]

Chris Zakelj wrote:

Clint Pachl wrote:
Is it possible for a cracker to compromise or root a machine on a 
network that has pf enabled with the single rule "block all in"?
I suspect you're just fishing, but in the interests of spirited 
debate
- Is "block in all" the first rule, the last rule, or somewhere in 
between?  (Yes, it DOES matter)
- Does the cracker have alternate methods of entry (tty, ssh, console, 
etc)?




Not fishing, just thinking. I didn't want to get into too many 
non-OpenBSD details on MISC, but I will expound a little.


I'm trying to design a simple, but secure network with a couple of DMZs 
and a minimum of firewalls. Here is my initial thought.



   [Internet]
   |
   |
[DMZ_2]---[FW]---[DMZ_1]
   |
   |
 [LAN]

DMZ_1 => web servers
DMZ_2 => database servers
LAN   => servers like Kerberos, ntp, DNS, backup (dump via ssh), & 
engineering workstations


Traffic Flow

Internet -> DMZ_1 (people need web pages)
DMZ_1-> DMZ_2 (get data to populate the web pages)
DMZ_2-> LAN (for Kerberos, ntp, DNS, backup)
DMZ_1-> LAN (for Kerberos, ntp, DNS, backup)

Ok, so you're never supposed to let a server on a "public DMZ" access a 
server on your LAN. So I was thinking of creating a management subnet 
that would allow out-of-band services, such as backup, Kerberos, ntp, 
etc. To implement the out-of-band channel, each of the hosts on the DMZs 
would get an additional NIC for communicating on the management subnet. 
None of these hosts would allow packet forwarding and all would use the 
"block in" rule for that interface. There is no need to login to the 
hosts via ssh because they are automatically configured, pulling updates 
from a "golden" server. If a login is needed, it would be from the 
serial console.


Below is my topology re-design that implements the management subnet. 
The DMZs access the LAN directly via the management subnet for Kerberos, 
ntp, backup, and DNS service. I would probably put a network monitor on 
the management subnet to detect suspicious traffic. Is this topology 
insecure? Suggestions and criticisms are very welcome.


   [Internet]
   |
   |
[DMZ_2]---[FW]---[DMZ_1]
  ||   |
  ||   |
  -->[LAN]<-


In my DMZ research, some sources state that all services need to be 
replicated in each DMZ. Following that advice, I would have to setup 
Kerberos, ntp, backup, and DNS in each DMZ and the LAN; that sounds like 
a lot of work. What do you guys think?


-pachl

Re: Compromising a host with pf enabled?

[Chris Zakelj]

Greg Thomas wrote:


 It does say "single" rule.
Yes, but at that point it becomes a rather useless system. It's likely 
to break in curious ways, since anything using the 127.0.0.1 loopback 
will, I think, either become unresponsive or start throwing errors.



 Social engineering?  Usually the weakest point.

Agreed.

Re: Compromising a host with pf enabled?

[Greg Thomas]

On Nov 19, 2007 6:37 PM, Chris Zakelj <[EMAIL PROTECTED]> wrote:
> Clint Pachl wrote:
> > Is it possible for a cracker to compromise or root a machine on a
> > network that has pf enabled with the single rule "block all in"?
> I suspect you're just fishing, but in the interests of spirited debate
> - Is "block in all" the first rule, the last rule, or somewhere in
> between?  (Yes, it DOES matter)

It does say "single" rule.

> - Does the cracker have alternate methods of entry (tty, ssh, console, etc)?

Social engineering?  Usually the weakest point.

Greg
-- 
Ticketmaster and Ticketweb suck, but everyone knows that:
http://ticketmastersucks.org
Obsession in the low desert:  http://lodesertprotosites.org
Dethink to survive - Mclusky

ftp-proxy not working properly

[Jake Conk]

Hello Gurus,

I'm having a problem with ftp proxy... I am using the OpenBSD machine
as my router and I'm trying to connect to public ftp addresses which I
can but the problem is i cannot list, put, or get any files from any
remote hosts?? After I establish the connection to the remote server I
see ftp-proxy opened up more ports on my server but I can't get it to
list any files on the remote server, it just hangs and eventually
crashes... What is wrong with my ftp-proxy?

Here is my pf.conf:


# Macros: define common values, so they can be referenced and changed easily.

ext_if="bge0"   # External interface
ext_ip=""# External IP
ext_carp_if="carp0" # External carp interface
ext_carp_ip=""   # External carp IP
ext_ifs="{" $ext_if $ext_carp_if "}"# All external interfaces
int_if="bge1"   # Internal interface
int_carp_if0="carp1"# Internal carp interface 1
int_carp_if1="carp2"# Internal carp interface 2
carp_ifs="{" $ext_if $int_if "}"# Interfaces which do carp
loop_if="lo0"   # Loopback Interface
bridge_if="bridge0" # Brige Interface
tap_if="tap0"   # Tap Interface
pflog_if="pflog0"   # Pflog Interface
pfsync_if="xl0" # Pfsync infterface
int_ifs="{" $int_if $int_carp_if0 $int_carp_if1 \
 $loop_if $bridge_if $tap_if $pflog_if \
 $pfsync_if "}"# All internal interfaces
external_addr="192.168.1.1" # External Address
internal_net="192.168.10.0/24"  # Internal Network
icmp_types="{0, 3, 4, 8, 11, 12}"   # Allowed ICMP Types
no_route="{ 127.0.0.0/8, 192.168.0.0/24, \
   172.16.0.0/12, 10.0.0.0/8 }"# Non routable IPs

# SERVERS #
ftp_server="192.168.10.9"
mail_server="192.168.10.9"



# Tables: similar to macros, but more flexible for many addresses.
#table  { 10.0.0.0/8, !10.1.0.0/16, 192.168.0.0/24, 192.168.1.18 }




# Options: tune the behavior of pf, defaults given

set timeout { interval 10, frag 30 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }
set limit   {states 1, frags 5000}  # Sets hard limits
used on memory pools
set loginterface $ext_if# Which interface to log
set optimization normal # Optimize engine for network
set block-policy drop   # Default behavior of
block policy
set require-order yes   # Enforce ordering of statements
set fingerprints "/etc/pf.os"   # Fingerprints
set debug loud  # Level of debug
set skip on $loop_if# Disable pf on which devices



# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.

scrub in on $ext_ifs all fragment reassemble



# Queueing: rule-based bandwidth control.

#altq on $ext_if bandwidth 2Mb cbq queue { dflt, developers, marketing }
#queue dflt bandwidth 5% cbq(default)
#queue developers bandwidth 80%
#queue marketing  bandwidth 15%



# Translation: specify how addresses are to be mapped or redirected.


# NAT: packets going out through $ext_if with source address $internal_net will
# get translated as coming from the address of $ext_if, a state is created for
# such packets, and incoming packets will be redirected to the internal address.
nat on $ext_if inet from $int_if:network to any -

Re: Compromising a host with pf enabled?

[Chris Zakelj]

Clint Pachl wrote:
Is it possible for a cracker to compromise or root a machine on a 
network that has pf enabled with the single rule "block all in"?

I suspect you're just fishing, but in the interests of spirited debate
- Is "block in all" the first rule, the last rule, or somewhere in 
between?  (Yes, it DOES matter)

- Does the cracker have alternate methods of entry (tty, ssh, console, etc)?

Revision on Macbook Guide

[Aaron Hsu]

Hello everyone,

I have had quite a few requests to come up with a new guide for the Macbook 
and OpenBSD. I haven't really thought that there was that much to update, so 
I haven't been doing too much on it. However, since there is a new -RELEASE 
out, I figured that I ought to at least bring things up to speed with 
the latest released features. I also wanted to give people some information 
about what may or may not be available in 4.3.

Additionally, I wanted to make my pages a bit easier to access, so I have 
done this guide in plain text.

I was hoping that anyone who had anything to add to this guide, and/or 
who had any comments regarding form, style, and general method, would speak 
up. :-) 



-- 
((name "Aaron Hsu")
 (email/xmpp "[EMAIL PROTECTED]")
 (site "http://www.aaronhsu.com";))

Re: OpenCon broadcasting.

[Siju George]

On Nov 19, 2007 10:58 PM, Marc Balmer <[EMAIL PROTECTED]> wrote:
> Siju
>
>
> Papers and slides are usually made available on the OpenBSD website
> shortly after any conference, so you might try your luck there.
>

Thanks Marc, will do that :-)

kind regards

Siju

Re: can't change password with passwd comand

[Clint Pachl]

Jumping Mouse wrote:

When I try to change a user password I get an error.
I do this:

#  passwd  username
enter a new password and  get: pwd_mkdb:  corrupted entrypwd_mkdb: at line
#24pwd_mkdb: /etc/ptmp: Innapropriate file type or formatpasswd:
etc/master.passwd unchanged

how can I fix this?
  


# cd /etc
# cp -p spwd.db pwd.db passwd /root/  # backup
# rm spwd* pwd* passwd* ptmp
# pwd_mkdb /etc/master.passwd
# passwd   # try again

Compromising a host with pf enabled?

[Clint Pachl]

Is it possible for a cracker to compromise or root a machine on a 
network that has pf enabled with the single rule "block all in"?

Re: how best to handle DNS on firewalled home network?

[Stuart Henderson]

On 2007/11/19 23:46, Jonathan Thornburg wrote:
>   One person also mentioned that s/he uses uses opendns.com
>   instead of ISP nameservers.

N.B. by default they will return a positive response for non-
existent domains (for typo correction) and bogus responses to
provide warnings about phishing sites etc.

This might be acceptable (or maybe beneficial) for web browsers,
but can be a problem for other hosts (e.g. mail servers). You can
disable this per-IP-address if you create an account with them.

Re: how best to handle DNS on firewalled home network?

[Jonathan Thornburg]

In message ,
I wrote:
> I'm setting up a home firewall, intended to (try to) protect "client"
> machines (mostly family members' MS-Windoze laptops) from misc internet
> threats.
[[...]]
> My plan is to have the firewall run its own dhcpd on its inside interface,
[[...]]
> The purpose of this message is to ask for advice on how to handle
> DNS on the firewall.  I can see two basic options:
> (a) [[firewall gives out outside DNS server addresses to inside
> machines via dhcp]]
> (b) [[firewall tells inside machines that the
> firewall itself is a DNS server; firewall runs a DNS proxy to
> pass DNS requests on to outside DNS servers]]

I'd like to thank the many people who responded, both on the list and
by private E-mail.  Here's a synopsis of the replies:
* Opinion was unanimous that (b) is more secure, and generally better.
* OpenBSD's named will work fine as my "DNS proxy" (more accurately,
  recursive resolver) on the firewall; it should need very little
  configuration to do this, quite possibly just  named_flags=""  in
  /etc/rc.conf.local
* Several people mentioned that having the firewall's named *cacheing*
  DNS entries will also improved reliability (since ISP nameservers are
  often flakey).  One person also mentioned that s/he uses uses opendns.com
  instead of ISP nameservers.

Again, my thanks to all who responded.

ciao,

-- 
-- Jonathan Thornburg (remove -animal to reply) <[EMAIL PROTECTED]>
   School of Mathematics, U of Southampton, England
   "Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
  -- quote by Freire / poster by Oxfam

Re: securing OpenBSD wireless network

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/19/07 2:36 PM, Tonnerre LOMBARD wrote:
> Salut,
> 
> On Mon, Nov 19, 2007 at 02:20:54PM -0800, David Newman wrote:
>> There is some layer-2 stuff that happens before layer-3 handshaking
>> begins -- 802.11 association and deassociation, possibly layer-2
>> learning, and 802.1X authentication if that's used. IPSec will not and
>> cannot secure any of this.
> 
> Is there any need to secure that? In my local WLAN, you only have two
> ways of proceeding if you want internet access: a Tor router, or
> IPsec. 

Before either of those processes begin, I can associate like crazy to
your access point. That would ensure you never get Internet access, even
without my flinging a single IP packet at you.

I have a test tool that can associate 500 times to the same AP,
appearing as 500 unique clients. In my experience, most APs crash and
burn a long time before then -- and that's before seeing any IP traffic.

Even if your AP is robust enough to handle a huge number of client
associations, the chatty nature of the 802.11 protocol ensures the
medium will be so full of management frames that you won't be able to
send an IP packet. (I like to think of 802.11 as a technology that
combines the worst aspects of Ethernet and token ring...)

If you come in without IPsec, i.e. you cannot establish the IKE
> handshake, and if you don't us the Socks proxy Tor provides, you are
> trapped in a local network where noone except all of the laptops are.
> Sure thing, you can communicate with another unauthenticated laptop,
> but I don't care that much about this scenario, since it does not
> cause me any problems.

Does not cause *you* problems != no leakage at L2

>> Wireless LANs are a technology in which sensitive data may go in the
>> clear at L2 before L3 gets started. In this case L2 security mechanisms
>> such as WPA are appropriate, and do not rule out the use of
>> complementary mechanisms like IPSec or SSL.
> 
> What sensitive data do you see me exchange before IPsec connectivity
> is established?

Well, for starters every 802.11 AP broadcasts its availability 10 times
a second. And since 802.11 is a shared-access medium, you'll also see
the first packet of every client's 802.1X auth exchange, as well as
SSIDs of all available stations.

> 
>> Even if you don't care about authenticating or encrypting L2 data,
>> there's still the issue of bandwidth and resource consumption at L2.
>> 802.11 is extremely chatty. Using WPA or (if you must) WEP to keep the
>> airwaves free (well, to the extent possible) can help there.
> 
> With a, that's not that much of a problem usually

Probably true for your setup, definitely less true in other (and
arguably most other large-scale) setups.

Most APs consist of a dinky little CPU and a very little bit of memory,
both easily swamped by doing too much work *just at layer 2.*

Further, they have to contend for spectrum with other 802.11 stations,
microwave ovens, Bluetooth devices, cordless phones, ham radios (that's
for the far more popular 2.4-GHz spectrum used by 802.11b/g/n. The
5.8-GHz spectrum used by 802.11a/n is much better, though still hardly
pristine).

Anything you can do to keep your AP's RF section free and clear will
result in a better WLAN experience, where "better" means both "faster"
and "more secure."

dn
iD8DBQFHQhdsyPxGVjntI4IRAiehAJ48mn685Gk0VaQ/ui50Zg07LvpKTQCgsQaW
iEhNeWGoplX7tIAAMCYKKgc=
=/Guk
-END PGP SIGNATURE-

can't change password with passwd comand

[Jumping Mouse]

When I try to change a user password I get an error.
I do this:

#  passwd  username
enter a new password and  get: pwd_mkdb:  corrupted entrypwd_mkdb: at line
#24pwd_mkdb: /etc/ptmp: Innapropriate file type or formatpasswd:
etc/master.passwd unchanged

how can I fix this?
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: securing OpenBSD wireless network

[Christian Weisgerber]

Marco S Hyman <[EMAIL PROTECTED]> wrote:

> Very true.   The only time I consider turning on WEP is when I notice
> a neighbor is connecting to my net more often than not.  Yes, by accident.

And downloading his mail with unencrypted POP3 for all to see...

You can use IPsec to discourage that, too.  The pf configuration
on my home WLAN gateway passes *only* ISAKMP negotiation and ESP
packets from/to the gateway.  ESP packets that don't match an IPsec
association are dropped.  To get a valid IPsec association, a host
needs to sucessfully negotiate with isakmpd.  And for that it needs
to authenticate (host key or password).  Of course stations can
still talk on the WLAN itself, but neighbors tend to have little
interest in that niche use.

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]

Re: securing OpenBSD wireless network

[Tonnerre LOMBARD]

Salut,

On Mon, Nov 19, 2007 at 02:20:54PM -0800, David Newman wrote:
> There is some layer-2 stuff that happens before layer-3 handshaking
> begins -- 802.11 association and deassociation, possibly layer-2
> learning, and 802.1X authentication if that's used. IPSec will not and
> cannot secure any of this.

Is there any need to secure that? In my local WLAN, you only have two
ways of proceeding if you want internet access: a Tor router, or
IPsec. If you come in without IPsec, i.e. you cannot establish the IKE
handshake, and if you don't us the Socks proxy Tor provides, you are
trapped in a local network where noone except all of the laptops are.
Sure thing, you can communicate with another unauthenticated laptop,
but I don't care that much about this scenario, since it does not
cause me any problems.

> Wireless LANs are a technology in which sensitive data may go in the
> clear at L2 before L3 gets started. In this case L2 security mechanisms
> such as WPA are appropriate, and do not rule out the use of
> complementary mechanisms like IPSec or SSL.

What sensitive data do you see me exchange before IPsec connectivity
is established?

> Even if you don't care about authenticating or encrypting L2 data,
> there's still the issue of bandwidth and resource consumption at L2.
> 802.11 is extremely chatty. Using WPA or (if you must) WEP to keep the
> airwaves free (well, to the extent possible) can help there.

With a, that's not that much of a problem usually

Tonnerre

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: Hoststated and randomly dropped connections

[Preston Norvell]

Thanks much, 

I'll start digging into the sysctls.  I'm reasonably certain it isn't
something with the app servers, because in the tcpdump output I can see the
conversation between the load balancer and the app server complete
successfully (all aspects of the request/response even), it's just from the
load balancer to the client machines that gets tetchy.  I will try the retry
value though; it certainly wouldn't hurt and sounds like a good idea.

Thanks again,

;P mn


On 2007/11/19 2:20 AM, "Reyk Floeter" <[EMAIL PROTECTED]> muttered
eloquently:

> hi!
> 
> are you sure that the apaches are not dropping the connections when
> you reach a specific limit of max connections? i've seen problems like
> this with apache2+linux webservers.
> 
> - make sure that you tuned some sysctls for hoststated. for example
> kern.maxfiles, kern.somaxconn, kern.maxclusters,
> net.inet.ip.ifq.maxlen. you have to be very careful when tuning the
> sysctls, but you mostly always have to bump them up for L7 load
> balancing.
> 
> - try out the "retry" option in the table configuration. this is a
> work-around for buggy backends. i experienced that the _backend_
> servers sometimes drop the inbound connection attempts, so i added
> this option to immediatly retry it... which works very well.
> 
> table foo {
> real port 80
> check http '/ZendPlatform/client/getPing.php' code 200
> 
> host $www01 retry 2
> host $www02 retry 2
> host $www03 retry 2
> ...
> 
> demote carp
> }
> 
> reyk
> 
> On Mon, Nov 19, 2007 at 12:14:18AM -0800, Preston Norvell wrote:
>> We have been trying to migrate from an Apache proxy balancer to hoststated
>> and have run into a couple issues, one of which I have asked about and the I
>> write about now.
>> 
>> We are using 4.2-stable:
>> OpenBSD mesh1 4.2 GENERIC.MP#1378 amd64
>> 
>> This particular issue is rather odd, such that I'm afraid my description may
>> be somewhat confusing, but here goes...
>> 
>> We are doing layer 7 http load balancing for an application hosted on 8+
>> machines behind the hoststated box for clients on the Internet.  In our
>> testing, we seem to have an issue with hoststated somewhat randomly dropping
>> inbound connections to a resource behind it.  It is not exactly
>> deterministic, in that we cannot seem to generate a specific packet to make
>> the connection fail, but it's just about statistically guaranteed to fail.
>> The failure rate goes up as the traffic increases, though even a sequential
>> run of 1000 single connections is likely to fail once or twice.
>> 
>>> From a tcpdump standpoint, I see the connection established through the load
>> balancer.  The GET request is issued from the client machine, which is
>> delivered by hoststated to the server, which dutifully considers the request
>> and returns a valid response.  Oddly though, on the client-facing side of
>> the load balancer,  immediately after the GET request is received, a FIN is
>> sent from the load balancer itself.
>> 
>> As stated, the likelihood of this occurring goes up with more traffic, even
>> with low-bandwidth request/response sequences.  The only message of any
>> import in any log I've looked in is the following from /var/log/daemon:
>> 
>> Nov 18 17:17:02 mesh1 hoststated[1945]: relay appx, session 2948 (50
>> active), a.b.c.d -> 10.100.0.208:8080, session failed
>> 
>> There are no blocks in pf, and no errors as far as the app server is
>> concerned.  The connections work fine through a similarly configured OpenBSD
>> firewall without hoststated in the loop.
>> 
>> I'm not sure where to start looking next to narrow down the issue farther,
>> does anyone have any suggestions?
>> 
>> Thanks much,
>> 
>> ;P mn
>> 
>> --
>> Preston M Norvell <[EMAIL PROTECTED]>
>> Systems/Network Administrator
>> Serials Solutions 
>> Phone:  (866) SERIALS (737-4257) ext 1094
>> 

--
Preston M Norvell <[EMAIL PROTECTED]>
Systems/Network Administrator
Serials Solutions 
Phone:  (866) SERIALS (737-4257) ext 1094

Re: lost root account

[Jumping Mouse]

Ok the issue was solved!

mount -s -uw /

vipw

I typed the missing root account line back in and saved the file and can now
log back in as root.
this then invoked pwd_mkdb to do all the rest.

thanks everyone.

only issue now is that if I try to change another users account password I get
the following:

enter:   passwd  username
enter:  new password

get:

pwd_mkdb:  corrupted entry
pwd_mkdb: at line #24
pwd_mkdb: /etc/ptmp: Innapropriate file type or format
passwd: etc/master.passwd unchanged

Do you have any idea what could be causing this,  the user entery in
master.passwd looks fine. > From: [EMAIL PROTECTED]> To:
[EMAIL PROTECTED]; misc@openbsd.org> Subject: Re: lost root account>
Date: Mon, 19 Nov 2007 21:37:19 +0100> > Hi Marcus,> > I thought it was enough
to add the root account through vipw. that this edits> the master.passwd file
and would automatically update everything else?> how would I use pwd_mkdb, i
don't want to delete any other accounts from the> master.passwd file.> >
thanks> > > > > > > Date: Mon, 19 Nov 2007 17:41:01 -0200> From:
[EMAIL PROTECTED]> To:> [EMAIL PROTECTED]; misc@openbsd.org> Subject:
Re: lost root account> > Boot> your machine in single user mode (boot -s) and>
use plain vi and pwd_mkdb soon> after that.> > There's no need to use vipw
when running in boot -s.> > On Nov> 19, 2007 5:18 PM, Jumping Mouse
<[EMAIL PROTECTED]> wrote:> > Hi there, I> have inherited an openBSD machine
with no root account. When I> > boot up in> single user mode boot -s and do a
cat /etc/master.passwd | root> > the only> thing I get is:
daemon:*:1:1::0:0:The devil> > himself:/root:/sbin/nologin I> can't seem to
make changes to the master.passwd> > account by using vipw in> single
usermode. I get a message that the file is> > locked or busy. Can> anyone help
in what I can do next? How can I add the> > root account back to> the
master.passwd file. thanks.> >> > Express yourself instantly with MSN>
Messenger! MSN Messenger> >>
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/> >> >>
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/>
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: securing OpenBSD wireless network

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/19/07 8:16 AM, Tonnerre LOMBARD wrote:

> Personally, I use IPsec to secure my WLAN, and I can only recommend that
> to others. It is very effective.

IPSec can be an effective safeguard -- for IP headers and the
upper-layer protocols and payloads above them.

On the other hand it's a misconception to think IPSec will "secure my
WLAN." IPSec doesn't know and doesn't care what link layer it runs over.

There is some layer-2 stuff that happens before layer-3 handshaking
begins -- 802.11 association and deassociation, possibly layer-2
learning, and 802.1X authentication if that's used. IPSec will not and
cannot secure any of this.

Wireless LANs are a technology in which sensitive data may go in the
clear at L2 before L3 gets started. In this case L2 security mechanisms
such as WPA are appropriate, and do not rule out the use of
complementary mechanisms like IPSec or SSL.

Even if you don't care about authenticating or encrypting L2 data,
there's still the issue of bandwidth and resource consumption at L2.
802.11 is extremely chatty. Using WPA or (if you must) WEP to keep the
airwaves free (well, to the extent possible) can help there.

dn
iD8DBQFHQgxFyPxGVjntI4IRAnLAAJ0Ysf5O3t8To4QcUBibQ2Yih6QA1QCfX++A
9su1m/P6DfqsnyNlLCDy0oo=
=dfhp
-END PGP SIGNATURE-

Re: lost root account

[Jason McIntyre]

On Mon, Nov 19, 2007 at 04:20:22PM -0500, Nick Holland wrote:
> 
> /etc/ptmp isn't documented in vipw (it probably should be), but it is 
> covered in passwd(1).  It should also be documented in faq8.html, I'll 
> try to fix that this evening. :)
> 

cvs up!
that is to say, i agree, and just added it.

jmc

Re: securing OpenBSD wireless network

[Peter N. M. Hansteen]

Marco S Hyman <[EMAIL PROTECTED]> writes:

> Very true.   The only time I consider turning on WEP is when I notice
> a neighbor is connecting to my net more often than not.  Yes, by accident.
> Typically because their AP went down and needed to be reset and they hadn't
> noticed.

Not sure what the actual legal status is (to my knowledge nobody as
actually been sued over here for using somebody else's WiFI or at
least no cases decided yet), but I tend to say WEP is more like a
"KEEP OUT" sign.  It doesn't stop anybody who's willing to use a tiny
bit of energy on getting in, but it signals that you did not intend
for all the world to use your equipment.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: system not using second entry in $PKG_PATH

[Stuart Henderson]

On 2007/11/19 22:35, christian widmer wrote:
> ask yourself why do you use ':' as a separator? 

see pkg_add(8) about PKG_PATH

Re: system not using second entry in $PKG_PATH

[Juan Miscaro]

> On Monday 19 November 2007 14.21:17 Juan Miscaro wrote:
> > On two OpenBSD 4.2 systems I have a (master) system that contains
> two
> > repositories - one of regular packages and one of packages derived
> from
> > ports.  On the client (slave) system I have a script with a
> PKG_PATH
> > containing both repositories:
> >
> > PKG_PATH_LAN1=ftp://$MASTER/$VERSION/packages/
> > PKG_PATH_LAN2=ftp://$MASTER/$VERSION/packages/by_port/i386/all/
> > PKG_PATH=$PKG_PATH_LAN1:$PKG_PATH_LAN2
> >
> > However the second one (PKG_PATH_LAN2) is never consulted.  If I
> remove
> > the first one then packages are found and installed with no
> problem.


--- christian widmer <[EMAIL PROTECTED]> wrote:

> ask yourself why do you use ':' as a separator? 
> 
> you have ':' in you PKG_PATH_LAN1 and PKG_PATH_LAN2.
> this is by the way the reason why you can't do what you're trying to.

{ fixed top posting }

Well the pkg_add man page seems to disagree:

 If the given package names are not found in the current working
directo-
 ry, pkg_add will search for them in each directory named by the
PKG_PATH
 environment variable.  Since a few URL schemes contain colons,
pkg_add
 relies on each directory ending in a / to split the path
correctly.

// juan


  Instant Messaging, free SMS, sharing photos and more... Try the new 
Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/

Re: spamdb output

[Bob Beck]

* RW <[EMAIL PROTECTED]> [2007-11-11 22:39]:

> It seems that the migrated database works but new entries go on the end
> - no SORT of order, and SPAMTRAP entries (that I entered using a
> script) ended up showing in two bunches in the midst of other unordered
> entries.
> 
> My question is: Is this normal with spamd a la 4.2 or is it because I
> migrated a database?

This is normal in 4.2 - the change happened post 4.0 when
spamdb stopped using DB_BTREE

-Bob

Re: securing OpenBSD wireless network

[Marco S Hyman]

Tor Houghton writes:
 > On Mon, Nov 19, 2007 at 07:59:17AM -0800, David Newman wrote:
 > 
 > > > Well, if you want to prevent someone from accidentally connecting to your
 > > > network, yes.
 > > 
 > > WEP keys can be captured is less than one minute:
 > 
 > This fact is immaterial in context of my statement.

Very true.   The only time I consider turning on WEP is when I notice
a neighbor is connecting to my net more often than not.  Yes, by accident.
Typically because their AP went down and needed to be reset and they hadn't
noticed.

Maybe one of these days I'll turn it on...

// marc

Re: system not using second entry in $PKG_PATH

[christian widmer]

ask yourself why do you use ':' as a separator? 

you have ':' in you PKG_PATH_LAN1 and PKG_PATH_LAN2.
this is by the way the reason why you can't do what you're trying to.


On Monday 19 November 2007 14.21:17 Juan Miscaro wrote:
> On two OpenBSD 4.2 systems I have a (master) system that contains two
> repositories - one of regular packages and one of packages derived from
> ports.  On the client (slave) system I have a script with a PKG_PATH
> containing both repositories:
>
> PKG_PATH_LAN1=ftp://$MASTER/$VERSION/packages/
> PKG_PATH_LAN2=ftp://$MASTER/$VERSION/packages/by_port/i386/all/
> PKG_PATH=$PKG_PATH_LAN1:$PKG_PATH_LAN2
>
> However the second one (PKG_PATH_LAN2) is never consulted.  If I remove
> the first one then packages are found and installed with no problem.
>
> Why is this happening?
>
> // juan
>
>
>
>   Be smarter than spam. See how smart SpamGuard is at giving junk email
> the boot with the All-new Yahoo! Mail.  Click on Options in Mail and switch
> to New Mail today or register for free at http://mail.yahoo.ca

Re: securing OpenBSD wireless network

[Tor Houghton]

On Mon, Nov 19, 2007 at 07:59:17AM -0800, David Newman wrote:

> > Well, if you want to prevent someone from accidentally connecting to your
> > network, yes.
> 
> WEP keys can be captured is less than one minute:
> 

This fact is immaterial in context of my statement.

Tor

Re: lost root account

[Nick Holland]

Jumping Mouse wrote:

Hi there,  I have inherited an openBSD machine with no root account.  When I
boot up in single user mode   boot -s and do a   cat /etc/master.passwd | root


I presume there's a "grep" missing in there. :)


the only thing I get is:  daemon:*:1:1::0:0:The devil
himself:/root:/sbin/nologin I can't seem to make changes to the master.passwd
account by using vipw  in single usermode.   I get a message that the file is
locked or busy.  Can anyone help in what I can do next?  How can I add the
root account back to the master.passwd file.  thanks.


try doing a "rm /etc/ptmp" before vipw.
That's the lock file which apparently exists on the machine for some 
reason (i.e., someone was sitting in vipw when you powered down the 
machine).


/etc/ptmp isn't documented in vipw (it probably should be), but it is 
covered in passwd(1).  It should also be documented in faq8.html, I'll 
try to fix that this evening. :)


Nick.

Re: system not using second entry in $PKG_PATH

[Juan Miscaro]

--- Nick Guenther <[EMAIL PROTECTED]> wrote:

> On 11/19/07, Juan Miscaro <[EMAIL PROTECTED]> wrote:
> > --- Marc Espie <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Nov 19, 2007 at 08:21:17AM -0500, Juan Miscaro wrote:
> > > > However the second one (PKG_PATH_LAN2) is never consulted.  If
> I
> > > remove
> > > > the first one then packages are found and installed with no
> > > problem.
> > > >
> > > > Why is this happening?
> > >
> > > Because it's designed that way.
> > >
> > > The second entry is only consulted if a matching package is not
> found
> > > in
> > > the first repository. It works like a linker path: pkg_add only
> looks
> > > at entries while it did not find a suitable candidate.
> >
> >
> > But the first repository does not contain a candidate.  That's what
> I'm
> > saying.
> >
> >
> > > The intention is that you should put your preferred repository at
> the
> > > front,
> > > and less wanted stuff later: if pkg_add finds something in the
> > > preferred
> > > repository, it won't even look at the rest.
> >
> >
> > So something is apparently wrong then.
> 
> I saw this bug two years ago when I first started with OpenBSD. I
> assumed I was doing something wrong and forgot about it.
> 
> things to try: are you sure the second repository has the package you
> need?

Well like I posted, if I remove the first repository the package
installs fine.

// juan


  Get a sneak peak at messages with a handy reading pane with All new 
Yahoo! Mail: http://mail.yahoo.ca

Re: lost root account

[Jumping Mouse]

thanks Juan,  faq8.1  shows me how to reset my root passord but i could not
find anything on recreating the root account.
Perhaps I am missing something?



> Date: Mon, 19 Nov 2007 14:36:18 -0500> From: [EMAIL PROTECTED]> Subject: Re:
lost root account> To: [EMAIL PROTECTED]; misc@openbsd.org> > > --- Jumping
Mouse <[EMAIL PROTECTED]> wrote:> > > Hi there, I have inherited an openBSD
machine with no root account. > > When I> > boot up in single user mode boot
-s and do a cat> > /etc/master.passwd | root> > the only thing I get is:
daemon:*:1:1::0:0:The devil> > himself:/root:/sbin/nologin I can't seem to
make changes to the> > master.passwd> > account by using vipw in single
usermode. I get a message that the> > file is> > locked or busy. Can anyone
help in what I can do next? How can I> > add the> > root account back to the
master.passwd file. thanks.> > > There is FAQ 8.1 on that.> > // juan> > > Get
a sneak peak at messages with a handy reading pane with All new Yahoo! Mail:
http://mail.yahoo.ca
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: lost root account

[Jumping Mouse]

Hi Marcus,

I thought it was enough to add the root account through vipw.  that this edits
the master.passwd  file and would automatically update everything else?
how would I use pwd_mkdb, i don't want to delete any other accounts from the
master.passwd file.

thanks





> Date: Mon, 19 Nov 2007 17:41:01 -0200> From: [EMAIL PROTECTED]> To:
[EMAIL PROTECTED]; misc@openbsd.org> Subject: Re: lost root account> > Boot
your machine in single user mode (boot -s) and> use plain vi and pwd_mkdb soon
after that.> > There's no need to use vipw when running in boot -s.> > On Nov
19, 2007 5:18 PM, Jumping Mouse <[EMAIL PROTECTED]> wrote:> > Hi there, I
have inherited an openBSD machine with no root account. When I> > boot up in
single user mode boot -s and do a cat /etc/master.passwd | root> > the only
thing I get is: daemon:*:1:1::0:0:The devil> > himself:/root:/sbin/nologin I
can't seem to make changes to the master.passwd> > account by using vipw in
single usermode. I get a message that the file is> > locked or busy. Can
anyone help in what I can do next? How can I add the> > root account back to
the master.passwd file. thanks.> >> > Express yourself instantly with MSN
Messenger! MSN Messenger> >
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/> >> >
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: lost root account

[Juan Miscaro]

--- Jumping Mouse <[EMAIL PROTECTED]> wrote:

> Hi there,  I have inherited an openBSD machine with no root account. 
> When I
> boot up in single user mode   boot -s and do a   cat
> /etc/master.passwd | root
> the only thing I get is:  daemon:*:1:1::0:0:The devil
> himself:/root:/sbin/nologin I can't seem to make changes to the
> master.passwd
> account by using vipw  in single usermode.   I get a message that the
> file is
> locked or busy.  Can anyone help in what I can do next?  How can I
> add the
> root account back to the master.passwd file.  thanks.


There is FAQ 8.1 on that.

// juan


  Get a sneak peak at messages with a handy reading pane with All new 
Yahoo! Mail: http://mail.yahoo.ca

Re: system not using second entry in $PKG_PATH

[Nick Guenther]

On 11/19/07, Juan Miscaro <[EMAIL PROTECTED]> wrote:
> --- Marc Espie <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Nov 19, 2007 at 08:21:17AM -0500, Juan Miscaro wrote:
> > > However the second one (PKG_PATH_LAN2) is never consulted.  If I
> > remove
> > > the first one then packages are found and installed with no
> > problem.
> > >
> > > Why is this happening?
> >
> > Because it's designed that way.
> >
> > The second entry is only consulted if a matching package is not found
> > in
> > the first repository. It works like a linker path: pkg_add only looks
> > at entries while it did not find a suitable candidate.
>
>
> But the first repository does not contain a candidate.  That's what I'm
> saying.
>
>
> > The intention is that you should put your preferred repository at the
> > front,
> > and less wanted stuff later: if pkg_add finds something in the
> > preferred
> > repository, it won't even look at the rest.
>
>
> So something is apparently wrong then.

I saw this bug two years ago when I first started with OpenBSD. I
assumed I was doing something wrong and forgot about it.

things to try: are you sure the second repository has the package you need?

-Nick

Re: lost root account

[Marcus Andree]

Boot your machine in single user mode (boot -s) and
use plain vi and pwd_mkdb soon after that.

There's no need to use vipw when running in boot -s.

On Nov 19, 2007 5:18 PM, Jumping Mouse <[EMAIL PROTECTED]> wrote:
> Hi there,  I have inherited an openBSD machine with no root account.  When I
> boot up in single user mode   boot -s and do a   cat /etc/master.passwd | root
> the only thing I get is:  daemon:*:1:1::0:0:The devil
> himself:/root:/sbin/nologin I can't seem to make changes to the master.passwd
> account by using vipw  in single usermode.   I get a message that the file is
> locked or busy.  Can anyone help in what I can do next?  How can I add the
> root account back to the master.passwd file.  thanks.
>
> Express yourself instantly with MSN Messenger! MSN Messenger
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: lost root account

[Gilles Chehade]

On Mon, Nov 19, 2007 at 08:18:47PM +0100, Jumping Mouse wrote:
> Hi there,  I have inherited an openBSD machine with no root account.  When I
> boot up in single user mode   boot -s and do a   cat /etc/master.passwd | root
> the only thing I get is:  daemon:*:1:1::0:0:The devil
> himself:/root:/sbin/nologin I can't seem to make changes to the master.passwd
> account by using vipw  in single usermode.   I get a message that the file is
> locked or busy.  Can anyone help in what I can do next?  How can I add the
> root account back to the master.passwd file.  thanks.
> 

you are getting this message because / is mounted read-only in single user mode.
to use vipw you will have to manually mount / read/write and mount /usr if it is
on its own partition.

Gilles

-- 
Gilles Chehade
http://www.evilkittens.org/
http://www.evilkittens.org/blog/gilles/

Re: system not using second entry in $PKG_PATH

[Juan Miscaro]

--- Marc Espie <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 19, 2007 at 08:21:17AM -0500, Juan Miscaro wrote:
> > On two OpenBSD 4.2 systems I have a (master) system that contains
> two
> > repositories - one of regular packages and one of packages derived
> from
> > ports.  On the client (slave) system I have a script with a
> PKG_PATH
> > containing both repositories:
> > 
> > PKG_PATH_LAN1=ftp://$MASTER/$VERSION/packages/
> > PKG_PATH_LAN2=ftp://$MASTER/$VERSION/packages/by_port/i386/all/
> > PKG_PATH=$PKG_PATH_LAN1:$PKG_PATH_LAN2
> > 
> > However the second one (PKG_PATH_LAN2) is never consulted.  If I
> remove
> > the first one then packages are found and installed with no
> problem.
> > 
> > Why is this happening?
> 
> Because it's designed that way.
> 
> The second entry is only consulted if a matching package is not found
> in
> the first repository. It works like a linker path: pkg_add only looks
> at entries while it did not find a suitable candidate.


But the first repository does not contain a candidate.  That's what I'm
saying.


> The intention is that you should put your preferred repository at the
> front,
> and less wanted stuff later: if pkg_add finds something in the
> preferred
> repository, it won't even look at the rest.


So something is apparently wrong then.

// juan



  Be smarter than spam. See how smart SpamGuard is at giving junk email the 
boot with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New 
Mail today or register for free at http://mail.yahoo.ca 

lost root account

[Jumping Mouse]

Hi there,  I have inherited an openBSD machine with no root account.  When I
boot up in single user mode   boot -s and do a   cat /etc/master.passwd | root
the only thing I get is:  daemon:*:1:1::0:0:The devil
himself:/root:/sbin/nologin I can't seem to make changes to the master.passwd
account by using vipw  in single usermode.   I get a message that the file is
locked or busy.  Can anyone help in what I can do next?  How can I add the
root account back to the master.passwd file.  thanks.

Express yourself instantly with MSN Messenger! MSN Messenger
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: system not using second entry in $PKG_PATH

[Marc Espie]

On Mon, Nov 19, 2007 at 08:21:17AM -0500, Juan Miscaro wrote:
> On two OpenBSD 4.2 systems I have a (master) system that contains two
> repositories - one of regular packages and one of packages derived from
> ports.  On the client (slave) system I have a script with a PKG_PATH
> containing both repositories:
> 
> PKG_PATH_LAN1=ftp://$MASTER/$VERSION/packages/
> PKG_PATH_LAN2=ftp://$MASTER/$VERSION/packages/by_port/i386/all/
> PKG_PATH=$PKG_PATH_LAN1:$PKG_PATH_LAN2
> 
> However the second one (PKG_PATH_LAN2) is never consulted.  If I remove
> the first one then packages are found and installed with no problem.
> 
> Why is this happening?

Because it's designed that way.

The second entry is only consulted if a matching package is not found in
the first repository. It works like a linker path: pkg_add only looks
at entries while it did not find a suitable candidate.

The intention is that you should put your preferred repository at the front,
and less wanted stuff later: if pkg_add finds something in the preferred
repository, it won't even look at the rest.

Re: hoststated(8): DNS Relay uses unexpected source IP address

[Rolf Sommerhalder]

On Nov 19, 2007 6:35 PM, Reyk Floeter <[EMAIL PROTECTED]> wrote:
> please try to configure the following:
...
> so the proposed solution is to always use "listen on 0.0.0.0 port 53"
> with DNS relays for now.

Your proposal indeed solves the problem in my multi-homed setup, and
makes my work-around with source NAT rule obsolete! Thank you very
much.

In the long run, would it be feasible to extend relay_udp_bind() so
that its binds to the IP address of
the interface to which it will relay those DNS UDP packets (while also
observing the default route)?
Could this eliminate the implicit use of "spoofed" sender IP addresses
by the DNS relay on multi-homed hosts, without adding any knobs?

Rolf

Re: mount_cd9660 options

[Jason McIntyre]

On Mon, Nov 19, 2007 at 05:46:59PM +0100, frantisek holop wrote:
> 
> there are sub-headings in some man pages (e.g. ksh(1)), perhaps
> that could be doable, somewhere lower in DESCRIPTION, e.g.
> 
>A fitting subtitle
>   Certain filesystems acquire flags based on their type and
>   content which are not always controlled by flags passed to their
>   respective mount command and so on, and so on.
> 
>   mount_cd9660
>   norrip  No Rockridge extension
> 
>   mount_XXX
>   flagdescription
> 
> 
> or as Otto suggested, have it in the respective mount_XXX page.
> 

yeah. i am waiting for all those kernel janitors to mail me diffs...
jmc

Re: mutiple pptp pass-through PF

[Reyk Floeter]

hi!

On Mon, Nov 19, 2007 at 11:24:59AM -0600, Beavis wrote:
> hi folks,
> 
> any pf folks available? I'm trying to run multiple pptp
> connections behind my 2 PF/carp firewalls. i was only successful to
> pass just 1 client and the rest gets denied for some weird reason. my
> pf.conf is below
> 
> 
> nat on $exT_if inet from any to any -> $ext_if
> 
> block in all
> block out all
> 
> pass in quick on $int_if inet proto { tcp, udp } from any to any port 1723
> pass in inet proto gre from any to any
> pass out inet proto gre from any to any
> 
> am I missing some other config to let the rest go out?
> 
> 
> any comments would be awesomely appreciated.
> 

pptp does not work with NAT, you need a proxy application to assist pf
in handling multiple pptp sessions.

the only existing pptp proxy that i know about is the "frickin pptp
proxy" (http://frickin.sourceforge.net/) but you shouldn't use this
proxy. you have been warned.

reyk

Re: hoststated(8): DNS Relay uses unexpected source IP address

[Reyk Floeter]

On Sat, Nov 17, 2007 at 04:01:51PM +0100, Rolf Sommerhalder wrote:
> relay dnsRelay {
>  listen on $yellow port 53
>  protocol dnsProto
>  forward to $white port 53
>  #forward to $dnsHost port 53
>  timeout 60
> }
> 

as theo mentioned, the problem is related to the use of the bind()
call for the outbound udp socket. the code currently uses the same
socket for inbound and outbound datagrams, and it will bind() to the
address specified in the "listen on" directive. there is no easy
support to support multi-homed interfaces yet, because i need to
extends the hoststated relay code to allow multiple "listen on"
directives per relay first (in contrast to TCP streams, we need to
"listen" for UDP replies).

please try to configure the following:

1. use 0.0.0.0 as the "listen on" address; the relay will listen
  on "any" IP address for incoming DNS requests and the kernel
  will select the primary IP address of the outgoing interface
  with the specified source port automatically

protocol dnsProto {
protocol dns
}
relay domain {
listen on 0.0.0.0 port 53
forward to $dnsHost port 53
protocol dnsProto
}

2. because we do not bind to an explicit address, restrict DNS in pf

pass in on { fxp2, fxp3 } inet proto udp to port 53

so the proposed solution is to always use "listen on 0.0.0.0 port 53"
with DNS relays for now.

> relay nfOracleRelay {
>  listen on $yellow port 1521
>  protocol nfOracleProto
>  forward to $white port 1521
>  #forward to $ospHost port 1521
>  timeout 3600
> }
> 
> relay x11Relay {
>  listen on $yellow port 6000
>  protocol x11Proto
>  forward to $white port 6000
>  #forward to $x11Host port 6000
>  timeout 600
> }
> [EMAIL PROTECTED]:etc]#
> 
> 
> 
> [EMAIL PROTECTED]:etc]# hoststated -v -d
> startup
> init_filter: filter init done
> init_tables: created 0 tables
> relay_init: adding relay x11Relay
> protocol 3: name x11Proto
> flags: 0x0004
> type: tcp
> relay_init: adding relay nfOracleRelay
> protocol 2: name nfOracleProto
> flags: 0x0004
> type: tcp
> relay_init: adding relay dnsRelay
> protocol 1: name dnsProto
> flags: 0x0004
> type: dns
> relay_init: adding relay sshRelay
> protocol 0: name sshProto
> flags: 0x0004
> type: tcp
> relay_launch: running relay x11Relay
> relay_launch: running relay nfOracleRelay
> relay_launch: running relay dnsRelay
> relay_launch: running relay sshRelay
> 
> ---
> 
> A) DNS/UDP Example
> 
> Output of "hoststated -v -d" after issuing a DNS lookup on "orange":
> 
> relay_dns_log: session 1: request id 0xf4cc flags 0x1:0x0 qd 1 an 0 ns 0 ar 0
> relay dnsRelay, session 1 (1 active), 10.2.2.32 -> 10.1.1.30:53, udp timeout
> relay_dns_log: session 2: request id 0xf4cc flags 0x1:0x0 qd 1 an 0 ns 0 ar 0
> relay dnsRelay, session 2 (1 active), 10.2.2.32 -> 10.1.1.30:53, udp timeout
> 
> 
> hostated listens on the right NIC fxp3:
> 
> [EMAIL PROTECTED]:root]# tcpdump -i fxp3 -n
> tcpdump: listening on fxp3, link-type EN10MB
> 15:51:39.635373 10.2.2.32.32768 > 10.2.2.31.53: 51934+ A? orange. (24) (DF)
> 15:51:44.636459 10.2.2.32.32768 > 10.2.2.31.53: 51934+ A? orange. (24) (DF)
> 
> 
> hostated passes on the proxied requets to the left NIC fxp2, using the
> unexpected/wrong(?) source address of (fxp3)=10.2.2.31, instead of
> (fxp2)=10.1.1.31 as in the TCP example below:
> 
> [EMAIL PROTECTED]:root]# tcpdump -i fxp2 -n
> tcpdump: listening on fxp2, link-type EN10MB
> 15:42:13.565810 10.2.2.31.53 > 10.1.1.30.53: 5744+ A? orange. (24)
> 15:42:18.566692 10.2.2.31.53 > 10.1.1.30.53: 6135+ A? orange. (24)
> 
> 
> ---
> 
> B) TCP Example
> 
> Output of "hoststated -v -d" after "orange" opens and immediately
> closes again an X11 window on a remote X server to the left of
> "white":
> 
> relay x11Relay, session 5 (1 active), 10.2.2.32 -> 10.1.1.30:6000, done
> 
> 
> hostated listens on the right NIC fxp3:
> 
> [EMAIL PROTECTED]:root]# tcpdump -i fxp3 -n
> tcpdump: listening on fxp3, link-type EN10MB
> 15:49:36.359944 10.2.2.32.32770 > 10.2.2.31.6000: S
> 18518406:18518406(0) win 5840  0,nop,wscale 2> (DF) [tos 0x10]
> 15:49:36.360083 10.2.2.31.6000 > 10.2.2.32.32770: S
> 2569303658:2569303658(0) ack 18518407 win 65535  1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 2174965381
> 74716745> (DF)
> 15:49:36.360975 10.2.2.32.32770 > 10.2.2.31.6000: . ack 1 win 1460
>  (DF) [tos 0x10]
> 15:49:39.487031 10.2.2.32.32770 > 10.2.2.31.6000: P 1:3(2) ack 1 win
> 1460  (DF) [tos 0x10]
> 15:49:39.684656 10.2.2.31.6000 > 10.2.2.32.32770: . ack 3 win 33304
>  (DF)
> 15:49:43.873208 10.2.2.32.32770 > 10.2.2.31.6000: F 3:3(0) ack 1 win
> 1460  (DF) [tos 0x10]
> 15:49:43.873284 10.2.2.31.6000 > 10.2.2.32.32770: . ack 4 win 33304
>  (DF)
> 15:49:43.873720 10.2.2.31.6000 > 10.2.2.32.32770: F 1:1(0) ack 4 win
> 33304  (DF)
> 15:49:43.873928 10.2.2.32.1024 > 10.2.2.31.6000: . ack 2569303660 win
> 1460  (DF)
> 15:49:45.365551 10.2.2.31.6000 > 10.2.2.32.32770: F 1:1(0) ack 4 win
> 33304  (DF)
> 15

Re: securing OpenBSD wireless network

[Marc Balmer]

Tonnerre LOMBARD wrote:

Salut,

On Mon, Nov 19, 2007 at 07:59:17AM -0800, David Newman wrote:

OpenBSD supports WEP.


Does it even matter?


Well, if you want to prevent someone from accidentally connecting to your
network, yes.

WEP keys can be captured is less than one minute:

http://eprint.iacr.org/2007/120.pdf
http://tapir.cs.ucl.ac.uk/bittau-wep.pdf

WEP is certainly better than nothing if all you have is older hardware
that doesn't support WPA/WPA2, but that's about all. If your APs and
host adapters support WPA, use it, not WEP.


Think of WEP as an encoding. Just like all the others: ASCII, UTF-8,
DES[1], MD5, etc. They do not provide any security, as opposed to encryption
algorithms, such as AES, Twofish, EBCDIC, et cetera. ;-)


I have heard rumours that some indian researchers succeed at breaking
EBCDIC due to a newly discovered weakness is the orignal scheme.


Personally, I use IPsec to secure my WLAN, and I can only recommend that
to others. It is very effective.


I can only second that.  Even when the clients are Windows or Mac OS X.



Tonnerre

[1]: It's called Data Encoding Standard, after all ;-)

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: OpenCon broadcasting.

[Marc Balmer]

Siju


Is there any chance of broadcasting OpenCon 2007 through metabug (
http://metabug.org/ )?

It would be of great help for people who cannot make it to "Venice"
due to several reasons.
(Sadly I cannot afford that travel cost currently :-( so will be many )
As somebody struggling to "make sense" with porting software to
OpenBSD "OpenBSD Ports Tutorial by Bernd Ahlers" I guess is my wish
come true. :-)

Hope Marc and Jason and Mike would be able to do something about this :-)


I seriously doubt that we will have the technical ressources to
broadcast the talks - and personally I am no big fan of it either
(but that does not count here).

Papers and slides are usually made available on the OpenBSD website
shortly after any conference, so you might try your luck there.

- Marc Balmer

mutiple pptp pass-through PF

[Beavis]

hi folks,

any pf folks available? I'm trying to run multiple pptp
connections behind my 2 PF/carp firewalls. i was only successful to
pass just 1 client and the rest gets denied for some weird reason. my
pf.conf is below


nat on $exT_if inet from any to any -> $ext_if

block in all
block out all

pass in quick on $int_if inet proto { tcp, udp } from any to any port 1723
pass in inet proto gre from any to any
pass out inet proto gre from any to any

am I missing some other config to let the rest go out?


any comments would be awesomely appreciated.


thanks,
-b

Re: mount_cd9660 options

[frantisek holop]

hmm, on Tue, Nov 13, 2007 at 09:58:20AM +, Jason McIntyre said that
> On Mon, Nov 12, 2007 at 10:00:13PM +0100, frantisek holop wrote:
> > > 
> > > if you mount a cd9660 filesystem w/ -R (no rockridge extensions) you get
> > > norrip in the output. i don;t think you can specify this as a mount
> > > option though, so i'm not sure where we'd document this.
> > 
> > well, there might be a NOTE(S) section in mount_cd9660...
> > 
> 
> well we don;t have (officially) NOTES sections. it would have to be
> CAVEATS or BUGS, neither of which are suitable.

there are sub-headings in some man pages (e.g. ksh(1)), perhaps
that could be doable, somewhere lower in DESCRIPTION, e.g.

   A fitting subtitle
Certain filesystems acquire flags based on their type and
content which are not always controlled by flags passed to their
respective mount command and so on, and so on.

mount_cd9660
norrip  No Rockridge extension

mount_XXX
flagdescription


or as Otto suggested, have it in the respective mount_XXX page.


> > the disc in question is a dvd...  so it's udf and udf is
> > "considered to be a replacement of ISO 9660, and today is widely
> > used for (re)writable optical media."
> > 
> > so if cd9660 != udf and one is the replacement of the other,
> > i was wondering if mount_cd9660 might be overhauled a bit
> > to reflect this situation...
> > 
> 
> do you want to overhaul the functionality of mount_cd9660? in what way?

what i meant was to have a mount_udf which of course already exists.
which is strange because i have never used it before...  hm.

-f
-- 
2 wrongs don't make a right - but 3 lefts do!

Re: securing OpenBSD wireless network

[Marti Martinez]

In my state, WEP is useful as a legal matter -- "borrowing" unsecured
wireless connectivity is not illegal, whereas "stealing" secured
access is. Sometimes the technical issues are not the only important
ones.

Marti


On Nov 19, 2007 8:59 AM, David Newman <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On 11/19/07 3:18 AM, Tor Houghton wrote:
> > On Sun, Nov 18, 2007 at 10:51:49PM -0700, Clint Pachl wrote:
> >>> OpenBSD supports WEP.
> >>>
> >> Does it even matter?
> >>
> >
> > Well, if you want to prevent someone from accidentally connecting to your
> > network, yes.
>
> WEP keys can be captured is less than one minute:
>
> http://eprint.iacr.org/2007/120.pdf
> http://tapir.cs.ucl.ac.uk/bittau-wep.pdf
>
> WEP is certainly better than nothing if all you have is older hardware
> that doesn't support WPA/WPA2, but that's about all. If your APs and
> host adapters support WPA, use it, not WEP.
>
> dn
> iD8DBQFHQbLVyPxGVjntI4IRAj8xAKDHZGzDcfW/dPf4o1dnhKsAfMkDYACfc/dZ
> HIfCGJDx82X8sTsbq0p/rJA=
> =0EMg
> -END PGP SIGNATURE-
>
>



--
Systems Programmer, Principal
Electrical & Computer Engineering
The University of Arizona
[EMAIL PROTECTED]



-- 
Systems Programmer, Principal
Electrical & Computer Engineering
The University of Arizona
[EMAIL PROTECTED]

Re: securing OpenBSD wireless network

[Tonnerre LOMBARD]

Salut,

On Mon, Nov 19, 2007 at 07:59:17AM -0800, David Newman wrote:
> >>> OpenBSD supports WEP.
> >>>
> >> Does it even matter?
> >>
> >
> > Well, if you want to prevent someone from accidentally connecting to your
> > network, yes.
>
> WEP keys can be captured is less than one minute:
>
> http://eprint.iacr.org/2007/120.pdf
> http://tapir.cs.ucl.ac.uk/bittau-wep.pdf
>
> WEP is certainly better than nothing if all you have is older hardware
> that doesn't support WPA/WPA2, but that's about all. If your APs and
> host adapters support WPA, use it, not WEP.

Think of WEP as an encoding. Just like all the others: ASCII, UTF-8,
DES[1], MD5, etc. They do not provide any security, as opposed to encryption
algorithms, such as AES, Twofish, EBCDIC, et cetera. ;-)

Personally, I use IPsec to secure my WLAN, and I can only recommend that
to others. It is very effective.

Tonnerre

[1]: It's called Data Encoding Standard, after all ;-)

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: securing OpenBSD wireless network

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/19/07 3:18 AM, Tor Houghton wrote:
> On Sun, Nov 18, 2007 at 10:51:49PM -0700, Clint Pachl wrote:
>>> OpenBSD supports WEP.
>>>  
>> Does it even matter?
>>
> 
> Well, if you want to prevent someone from accidentally connecting to your
> network, yes.

WEP keys can be captured is less than one minute:

http://eprint.iacr.org/2007/120.pdf
http://tapir.cs.ucl.ac.uk/bittau-wep.pdf

WEP is certainly better than nothing if all you have is older hardware
that doesn't support WPA/WPA2, but that's about all. If your APs and
host adapters support WPA, use it, not WEP.

dn
iD8DBQFHQbLVyPxGVjntI4IRAj8xAKDHZGzDcfW/dPf4o1dnhKsAfMkDYACfc/dZ
HIfCGJDx82X8sTsbq0p/rJA=
=0EMg
-END PGP SIGNATURE-

OpenCon broadcasting.

[Siju George]

Hi,

Is there any chance of broadcasting OpenCon 2007 through metabug (
http://metabug.org/ )?

It would be of great help for people who cannot make it to "Venice"
due to several reasons.
(Sadly I cannot afford that travel cost currently :-( so will be many )
As somebody struggling to "make sense" with porting software to
OpenBSD "OpenBSD Ports Tutorial by Bernd Ahlers" I guess is my wish
come true. :-)

Hope Marc and Jason and Mike would be able to do something about this :-)

Thank you so much

Kind Regards

Siju

Re: Helping with Softraid testing

[Siju George]

On Nov 19, 2007 5:12 AM, Ray Percival <[EMAIL PROTECTED]> wrote:
> On Nov 18, 2007, at 3:34 PM, Siju George wrote:
> >
> 
> > I know I cannot escape recompiling the kernel because it is necessary
> > for updates. But as far as possible I would like to stay away from it
> > on production machines :-)
>
> That's what releases are for.
>

I haven't tried releases yet, thanks the next days I will do that :-)

Kind regards

Siju

Re: Helping with Softraid testing

[Marco Peereboom]

Nah, single disk is fine.

On Mon, Nov 19, 2007 at 01:12:29PM +, Edd Barrett wrote:
> On 19/11/2007, Marco Peereboom <[EMAIL PROTECTED]> wrote:
> > sparc
> >
> > Preferable I'd like to see the testing using real disks.
> 
> Do the slices need to be on different disks to make useful testing? I
> ask because my sparc(64) box has a single FCAL (Fibre Channel) disk,
> and these things are not easy to come by. I have been meaning to buy
> one, but OpenCON has cleaned my wallet out for now :P
> 
> 
> -- 
> Best Regards
> 
> Edd
> 
> ---
> http://students.dec.bournemouth.ac.uk/ebarrett

system not using second entry in $PKG_PATH

[Juan Miscaro]

On two OpenBSD 4.2 systems I have a (master) system that contains two
repositories - one of regular packages and one of packages derived from
ports.  On the client (slave) system I have a script with a PKG_PATH
containing both repositories:

PKG_PATH_LAN1=ftp://$MASTER/$VERSION/packages/
PKG_PATH_LAN2=ftp://$MASTER/$VERSION/packages/by_port/i386/all/
PKG_PATH=$PKG_PATH_LAN1:$PKG_PATH_LAN2

However the second one (PKG_PATH_LAN2) is never consulted.  If I remove
the first one then packages are found and installed with no problem.

Why is this happening?

// juan



  Be smarter than spam. See how smart SpamGuard is at giving junk email the 
boot with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New 
Mail today or register for free at http://mail.yahoo.ca 

Re: Helping with Softraid testing

[Edd Barrett]

On 19/11/2007, Marco Peereboom <[EMAIL PROTECTED]> wrote:
> sparc
>
> Preferable I'd like to see the testing using real disks.

Do the slices need to be on different disks to make useful testing? I
ask because my sparc(64) box has a single FCAL (Fibre Channel) disk,
and these things are not easy to come by. I have been meaning to buy
one, but OpenCON has cleaned my wallet out for now :P


-- 
Best Regards

Edd

---
http://students.dec.bournemouth.ac.uk/ebarrett

Re: ipsec.conf and AES 256

[Hans-Joerg Hoexer]

On Mon, Nov 19, 2007 at 12:26:16PM +0100, Mitja Mu?eni? wrote:
> As far as I can tell, currently in ipsec.conf there is no way to use AES
> with KEY_LENGHT=256. Is anybody working on adding this? Otherwise I might
> try it when the time permits. 
> 
> I'm thinking that isakmpd should first learn about a new default transform,
> let's say AES256 - then adding that into ipsecctl/ipsec.conf should be
> pretty much trivial. 

this sounds like a reasonable approach to me.

> 
> The other route is not to add this new default transform to isakmpd, but to
> have ipsecctl generate a config with a non-default transform - this does not
> touch isakmpd at all, but is less than trivial in ipsecctl.
> 
> Thoughts, anyone?
> 
> Mitja

Re: securing OpenBSD wireless network

[Lars Hansson]

On Nov 19, 2007 1:51 PM, Clint Pachl <[EMAIL PROTECTED]> wrote:
> Does it even matter?

If you want to connect to networks that are using WEP, yes.

---
Lars Hansson

Re: Helping with Softraid testing

[Marco Peereboom]

On Mon, Nov 19, 2007 at 12:54:04AM +, Stuart Henderson wrote:
> Marco, what arch are you missing reports for now?

That is the best question to ask :-)

The arches that I want more testing on are:
alpha
armish
hp300
hppa
landisk
luna88k
ma68k
mvme68k
mvme88k
sgi
sparc
vax
zaurus

Preferable I'd like to see the testing using real disks.  Yes USB is
important but it is also super slow and has different issues than actual
disk.  I have done a lot of testing using USB at this time and need more
love on actual disk.

Spare me the qemu/i386/amd64 ones I have tons and tons of those.

Thanks!

Re: Helping with Softraid testing

[Marco Peereboom]

On Mon, Nov 19, 2007 at 05:04:53AM +0530, Siju George wrote:
> On Nov 18, 2007 7:46 PM, Marco Peereboom <[EMAIL PROTECTED]> wrote:
> > On Sun, Nov 18, 2007 at 04:32:58AM +0530, Siju George wrote:
> > > Thank you so much
> > >
> >
> > Most of your questions are around rebuild or derivatives.  This does not
> > exist yet.  My current push is to get softraid working on all arches so
> > that it could get re-enabled.  The rebuild stuff comes after that.
> >
> 
> Thank you so much Marco for the detailed reply.
> 
> Just one more quick question please :-)
> 
> One all the features in your mind has been implemented to softraid
> will it make RAIDFRAME redundant?

RAIDFRAME for all its quirks and uglies still does way more than
softraid.  I'll be one happy man if we get to a stage that we can
replace it.  Besides this we'll have to make sure we are not screwing
users of RAIDFRAME out there.

> 
>  Though I love and use RAIDFRAME and have overcome the initial qualms
> of rebuilding the kernel from source after doing it a number of times
> now I think it will still be great if Software RAID can be implemented
> without having to re compile the kernel.
> I know I cannot escape recompiling the kernel because it is necessary
> for updates. But as far as possible I would like to stay away from it
> on production machines :-)

As far as I know I have one bug remaining that needs fixing.  Sometimes
at shutdown time one of the metadata updates does not make it onto a
disk and on the subsequent reboot the disk is not auto-assembled like it
should.

The other thing I really need is to make dead sure that there are no
booting issues on ANY platform.

Once I am passed these two issues I can move forward into the realm that
is rebuilds and derivatives.

> 
> Thanks a million for all the detailed answers once again :-)))
> 
> Kind Regards
> 
> Siju

Re: Subversion/Apache Mod dav

[David Gwynne]

Hi,

are you trying to use the subversion port, are you trying to roll  
your own?


dlg

On 13/11/2007, at 3:14 PM, Duncan Patton a Campbell wrote:


On Mon, 12 Nov 2007 20:49:08 -0600
Duncan Patton a Campbell <[EMAIL PROTECTED]> wrote:


Howdy?

I'm trying to install mod_dav_svn and mod_authz_svn with apache  
2.0.xx
and find that they have been moved into the ap2-subversion-1.4.4  
package that
requires apache 2.2.  When I go to the ports tree there is nothing  
equivalent

to this module.

Does anyone know what is going on?  Is subversion under apache 2.0  
no longer supported?


Any help would be greatly appreciated.

Thanks,

Dhu




Addenedum:

subversion 1.4.5 now appears to build on OBSD with mod_dav_svn, so  
this is less

problematic.. still(?)

Dhu

ipsec.conf and AES 256

[Mitja Muženič]

As far as I can tell, currently in ipsec.conf there is no way to use AES
with KEY_LENGHT=256. Is anybody working on adding this? Otherwise I might
try it when the time permits. 

I'm thinking that isakmpd should first learn about a new default transform,
let's say AES256 - then adding that into ipsecctl/ipsec.conf should be
pretty much trivial. 

The other route is not to add this new default transform to isakmpd, but to
have ipsecctl generate a config with a non-default transform - this does not
touch isakmpd at all, but is less than trivial in ipsecctl.

Thoughts, anyone?

Mitja

Re: securing OpenBSD wireless network

[Tor Houghton]

On Sun, Nov 18, 2007 at 10:51:49PM -0700, Clint Pachl wrote:
> >
> >OpenBSD supports WEP.
> >  
> 
> Does it even matter?
> 

Well, if you want to prevent someone from accidentally connecting to your
network, yes.

Tor

Re: Helping with Softraid testing

[Stuart Henderson]

On 2007/11/19 10:27, Edd Barrett wrote:
> On 19/11/2007, Stuart Henderson <[EMAIL PROTECTED]> wrote:
> > On 2007/11/19 05:04, Siju George wrote:
> > > One all the features in your mind has been implemented to softraid
> > > will it make RAIDFRAME redundant?
> >
> > This is all future stuff, I think I'm right in saying that what's
> > needed first and foremost is test reports for the less popular
> > machine architectures.
> 
> I can test on sparc64 if you like, but I am unsure what the driver is
> capable of at this stage.

RAID1, autoconfigured at boot (before root is mounted). Currently,
if a drive fails, you need to dd to clone the working drive, a bit
like ccd(4) mirrors in that respect.

Do give it a try if you haven't, if you don't have free disk space
you could always borrow a bit from /tmp or swap (or run under qemu if
need be). It's pretty slick.

Re: Helping with Softraid testing

[Edd Barrett]

On 19/11/2007, Stuart Henderson <[EMAIL PROTECTED]> wrote:
> On 2007/11/19 05:04, Siju George wrote:
> > One all the features in your mind has been implemented to softraid
> > will it make RAIDFRAME redundant?
>
> This is all future stuff, I think I'm right in saying that what's
> needed first and foremost is test reports for the less popular
> machine architectures.

I can test on sparc64 if you like, but I am unsure what the driver is
capable of at this stage.

-- 
Best Regards

Edd

---
http://students.dec.bournemouth.ac.uk/ebarrett

Re: Hoststated and randomly dropped connections

[Reyk Floeter]

hi!

are you sure that the apaches are not dropping the connections when
you reach a specific limit of max connections? i've seen problems like
this with apache2+linux webservers.

- make sure that you tuned some sysctls for hoststated. for example
kern.maxfiles, kern.somaxconn, kern.maxclusters,
net.inet.ip.ifq.maxlen. you have to be very careful when tuning the
sysctls, but you mostly always have to bump them up for L7 load
balancing.

- try out the "retry" option in the table configuration. this is a
work-around for buggy backends. i experienced that the _backend_
servers sometimes drop the inbound connection attempts, so i added
this option to immediatly retry it... which works very well.

table foo {
real port 80
check http '/ZendPlatform/client/getPing.php' code 200

host $www01 retry 2
host $www02 retry 2
host $www03 retry 2
...

demote carp
}

reyk

On Mon, Nov 19, 2007 at 12:14:18AM -0800, Preston Norvell wrote:
> We have been trying to migrate from an Apache proxy balancer to hoststated
> and have run into a couple issues, one of which I have asked about and the I
> write about now.
> 
> We are using 4.2-stable:
> OpenBSD mesh1 4.2 GENERIC.MP#1378 amd64
> 
> This particular issue is rather odd, such that I'm afraid my description may
> be somewhat confusing, but here goes...
> 
> We are doing layer 7 http load balancing for an application hosted on 8+
> machines behind the hoststated box for clients on the Internet.  In our
> testing, we seem to have an issue with hoststated somewhat randomly dropping
> inbound connections to a resource behind it.  It is not exactly
> deterministic, in that we cannot seem to generate a specific packet to make
> the connection fail, but it's just about statistically guaranteed to fail.
> The failure rate goes up as the traffic increases, though even a sequential
> run of 1000 single connections is likely to fail once or twice.
> 
> >From a tcpdump standpoint, I see the connection established through the load
> balancer.  The GET request is issued from the client machine, which is
> delivered by hoststated to the server, which dutifully considers the request
> and returns a valid response.  Oddly though, on the client-facing side of
> the load balancer,  immediately after the GET request is received, a FIN is
> sent from the load balancer itself.
> 
> As stated, the likelihood of this occurring goes up with more traffic, even
> with low-bandwidth request/response sequences.  The only message of any
> import in any log I've looked in is the following from /var/log/daemon:
> 
> Nov 18 17:17:02 mesh1 hoststated[1945]: relay appx, session 2948 (50
> active), a.b.c.d -> 10.100.0.208:8080, session failed
> 
> There are no blocks in pf, and no errors as far as the app server is
> concerned.  The connections work fine through a similarly configured OpenBSD
> firewall without hoststated in the loop.
> 
> I'm not sure where to start looking next to narrow down the issue farther,
> does anyone have any suggestions?
> 
> Thanks much,
> 
> ;P mn
> 
> --
> Preston M Norvell <[EMAIL PROTECTED]>
> Systems/Network Administrator
> Serials Solutions 
> Phone:  (866) SERIALS (737-4257) ext 1094

Re: FAM issue; how to fix

[Soner Tari]

On Sat, 2007-11-17 at 07:56 -0800, badeguruji wrote:
> Nov 16 22:43:23 myopenbsdpc famd[1183]: kqueue can't monitor more than 886 
> files

Setting 'kern.maxfiles=1' in sysctl.conf has solved that issue in my
case. (But I still have problems with files on mounted ext3 partitions.)

Hoststated and randomly dropped connections

[Preston Norvell]

We have been trying to migrate from an Apache proxy balancer to hoststated
and have run into a couple issues, one of which I have asked about and the I
write about now.

We are using 4.2-stable:
OpenBSD mesh1 4.2 GENERIC.MP#1378 amd64

This particular issue is rather odd, such that I'm afraid my description may
be somewhat confusing, but here goes...

We are doing layer 7 http load balancing for an application hosted on 8+
machines behind the hoststated box for clients on the Internet.  In our
testing, we seem to have an issue with hoststated somewhat randomly dropping
inbound connections to a resource behind it.  It is not exactly
deterministic, in that we cannot seem to generate a specific packet to make
the connection fail, but it's just about statistically guaranteed to fail.
The failure rate goes up as the traffic increases, though even a sequential
run of 1000 single connections is likely to fail once or twice.

>From a tcpdump standpoint, I see the connection established through the load
balancer.  The GET request is issued from the client machine, which is
delivered by hoststated to the server, which dutifully considers the request
and returns a valid response.  Oddly though, on the client-facing side of
the load balancer,  immediately after the GET request is received, a FIN is
sent from the load balancer itself.

As stated, the likelihood of this occurring goes up with more traffic, even
with low-bandwidth request/response sequences.  The only message of any
import in any log I've looked in is the following from /var/log/daemon:

Nov 18 17:17:02 mesh1 hoststated[1945]: relay appx, session 2948 (50
active), a.b.c.d -> 10.100.0.208:8080, session failed

There are no blocks in pf, and no errors as far as the app server is
concerned.  The connections work fine through a similarly configured OpenBSD
firewall without hoststated in the loop.

I'm not sure where to start looking next to narrow down the issue farther,
does anyone have any suggestions?

Thanks much,

;P mn

--
Preston M Norvell <[EMAIL PROTECTED]>
Systems/Network Administrator
Serials Solutions 
Phone:  (866) SERIALS (737-4257) ext 1094