headers
James Peltier | 1 Jun 2010 06:27
Picon
Favicon

Confirmation of trunk configuration

I'm trying to configure OpenBSD with trunking using LACP but I can't 
seem to get it to work correctly.  I have an HP Procurve 5304XL connected to a Dell 1750 with an  Intel
PRO/1000MT QP (82546EB).  I am unable to get trunking and LACP to work together for some reason.  Any help
would be greatly appreciated.

HP Ports B1 and B2 are connected to Dell 1750 em0 and em1
HP Ports B3 and B4 are connected to Dell 1750 em2 and em3

ProCurve Switch 5304XL# show lacp

                           LACP

no LACP ports found.

ProCurve Switch 5304XL# show trunk

 Load Balancing

  Port | Name                             Type      | Group Type
  ---- + -------------------------------- --------- + ----- -----

ProCurve Switch 5304XL(config)# trunk b3-b4 trk2 lacp
ProCurve Switch 5304XL(config)# show trunk

 Load Balancing

  Port | Name                             Type      | Group Type
  ---- + -------------------------------- --------- + ----- -----
  B3   |                                  100/1000T | Trk2  LACP
  B4   |                                  100/1000T | Trk2  LACP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uwe Dippel | 1 Jun 2010 10:07
Picon

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

On 06/01/2010 05:32 AM, Philip Guenther wrote:

> Was there a common thread to what did turn up?  My recall is that
> basically every time people get "Operation not supported by device"
> errors from pfctl, it's because their userland and kernel don't match.

> Review your upgrade procedure, because it's clearly broken.

Thanks for your help, seriously. And I don't want to start arguing, not 
at all, but this is one of my production boxes, without access, and I 
have been running the boot.bsd.rd updates since 3.8 twice a year.
Being production, I diligently watched, and saw with my own eyes the 
asterisks advancing. I can only say, I followed standard procedures; if 
just for my own sanity.
I *am* losing the latter, because it seems that all files in /sbin are 
identical to my box still on 4.6; though something has happened to them 
yesterday:

(this is my 4.6-box, upgraded only on April 19th:)
$ ls -l /sbin/p* 

-r-xr-xr-x  1 root  bin  492664 Apr 19 13:44 /sbin/pfctl
-r-xr-xr-x  1 root  bin  390264 Apr 19 13:44 /sbin/pflogd
-r-sr-xr-x  1 root  bin  210040 Apr 19 13:44 /sbin/ping
-r-sr-xr-x  1 root  bin  234616 Apr 19 13:44 /sbin/ping6

(This is my box upgraded yesterday, May 31st, to 4.7:)
# ls -l /sbin/p* 

-r-xr-xr-x  1 root  bin  492664 May 31 20:28 /sbin/pfctl
(Continue reading)

Permalink | Reply | 6 comments |
headers
Pete Vickers | 1 Jun 2010 10:17
Picon
Favicon

Re: OpenBSD 4.7 as VPN Gateway for Road Warriors, Preferred Configuration

Hi,

Transport mode IPSec has many legit uses. The first one which springs to mind
is gateway-gateway encryption, over which you can use your favourite tunneling
protocol e.g.  L2TP or GRE. Especially useful if you're transporting multicast
traffic over the VPN.

Also one of the most popular remote access VPN solutions (works 'out of the
box' on Windows, OS.X & Cisco routers) is "L2TP over IPSec". This provides
both static & dynamically addressed clients with an IPSec tunnel back to the
VPN server, over which L2TP is tunneled, providing DHCP for tunnel IP
addressing, and multi-protocol (IPX or IPv6 anyone ?) support.

It's also ideal for ubiquitous IP level any to any encryption if you spend the
effort on key management issues.

/Pete

On 31. mai 2010, at 18.56, Toni Mueller wrote:

>
> I'd say that transport mode is a design error in IPSEC and should be
> avoided at all costs. It also complicates network setup quite a bit,
> imho.
>
>
> Kind regards,
> --Toni++
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joachim Schipper | 1 Jun 2010 11:52
Picon

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:
> On 06/01/2010 05:32 AM, Philip Guenther wrote:
> 
> >Was there a common thread to what did turn up?  My recall is that
> >basically every time people get "Operation not supported by device"
> >errors from pfctl, it's because their userland and kernel don't match.
> 
> >Review your upgrade procedure, because it's clearly broken.
> 
> Thanks for your help, seriously. And I don't want to start arguing,
> not at all, but this is one of my production boxes, without access,
> and I have been running the boot.bsd.rd updates since 3.8 twice a
> year.
> Being production, I diligently watched, and saw with my own eyes the
> asterisks advancing. I can only say, I followed standard procedures;
> if just for my own sanity.
> I *am* losing the latter, because it seems that all files in /sbin
> are identical to my box still on 4.6; though something has happened
> to them yesterday:
> 
> (this is my 4.6-box, upgraded only on April 19th:)
> $ ls -l /sbin/p*
> 
> -r-xr-xr-x  1 root  bin  492664 Apr 19 13:44 /sbin/pfctl
> -r-xr-xr-x  1 root  bin  390264 Apr 19 13:44 /sbin/pflogd
> -r-sr-xr-x  1 root  bin  210040 Apr 19 13:44 /sbin/ping
> -r-sr-xr-x  1 root  bin  234616 Apr 19 13:44 /sbin/ping6
> 
> (This is my box upgraded yesterday, May 31st, to 4.7:)
> # ls -l /sbin/p*
(Continue reading)

Permalink | Reply | 5 comments |
headers
Uwe Dippel | 1 Jun 2010 13:09
Picon

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Joachim Schipper <joachim <at> joachimschipper.nl> writes:

 > Just untarring the release should work, but it's still odd. At least 
 > the md5sum of pfctl matches what I just downloaded, so that seems
 > fine; did you actually use *that* tarball, though? (Note that the
 > "right" pfctl binary is 500856 bytes long.)
 >
 > Are you sure that you upgraded the right disk?

Yep.

When I untar the files (I have them locally on a webserver:
ftp://metalab.uniten.edu.my/pub/OpenBSD/4.7/
all files come out perfectly well, as above. I did the upgrades using 
this URL; I am sure it were these files, because they only exist once 
locally (the speed with which the updates were done is proof that I used 
these local resources, downloaded by myself). In the Upgrade procedure I 
only added the (internal) IP for that server, accepting all else. And it 
can't be 4.6 that I used, kind of, because the installed (upgraded) 
kernel is 4.7.
I need to repeat, this is a remote production machine with serial 
access. I have no desire ever to do anything not along clear procedures, 
and I followed the Upgrade Guide 4.6->4.7 meticulously (system 
administration is part of my job description), even ticking off point 
after point on the printout of the upgrade guide.
So something was done to the files, at least they have the new time 
stamp, and some files have actually been installed correctly (kernels); 
as the hashsums show. So, finally, I *was* in the right directory and 
installed to the correct disk.
Here are the kernels, on the first machine, that has seemingly the
(Continue reading)

Permalink | Reply | 2 comments |
headers
TeXitoi | 1 Jun 2010 13:34
Picon
Favicon

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Joachim Schipper <joachim <at> joachimschipper.nl> writes:

> On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:
> > On 06/01/2010 05:32 AM, Philip Guenther wrote:
> > 
> > >Review your upgrade procedure, because it's clearly broken.
> > 
> > Thanks for your help, seriously. And I don't want to start arguing,
> > not at all, but this is one of my production boxes, without access,
> > and I have been running the boot.bsd.rd updates since 3.8 twice a
> > year.
> > Being production, I diligently watched, and saw with my own eyes the
> > asterisks advancing. I can only say, I followed standard procedures;
> > if just for my own sanity.
> > I *am* losing the latter, because it seems that all files in /sbin
> > are identical to my box still on 4.6; though something has happened
> > to them yesterday:
> 
> Just untarring the release should work, but it's still odd. At least the
> md5sum of pfctl matches what I just downloaded, so that seems fine; did
> you actually use *that* tarball, though? (Note that the "right" pfctl
> binary is 500856 bytes long.)
> 
> Are you sure that you upgraded the right disk?

I heard that some mirrors had corrupted tarball. Maybe it is related.

--

-- 
Guillaume Pinot               http://www.irccyn.ec-nantes.fr/~pinot/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gabriel Read | 1 Jun 2010 14:25
Picon

Re: slow network performance with realtek 8111D

Hi.  I tried what you said.  Both recvspace and sendspace were set to
16384.  I set both of them to 131070 and tried iperf again.  It wasn't
any faster.

Thanks,
Gabe

On Mon, May 31, 2010 at 10:44 PM, jean-philippe luiggi
<jpl <at> didconcept.com> wrote:
> Hello,
>
> Please check the result of :
>
> #sysctl -a | grep tcp.*space
>
> If the result is "65535" then increase the value to "131070" and run 'iperf'
again.
>
>
> Cheers,
>
> Jean-Philippe.
>
>
>
>
>
> * Gabriel Read <gabe2004 <at> gmail.com> [2010-05-25 02:19:57 -0400]:
>
>> Using iperf, I get around 300 mbits/s. between my openbsd machine and
(Continue reading)

Permalink | Reply | 0 comments |
headers
What you get is Not what you see | 1 Jun 2010 15:30
Picon

Mysql connection from within php

Freshly installed on openbsd 4.6 mysql,php and php5-mysql packages.
Done the configs. Now php and mysql works. But I couldnt make it
connect to mysql from within php with such a command
mysql_connect("localhost","user","pass")
It used to give "Cant connect to mysql through socket error" till I
change the command to
mysql_connect(127.0.0.1,"user","pass")
I want to learn why?
Permalink | Reply | 8 comments |
headers
L. V. Lammert | 1 Jun 2010 15:45

Re: Mysql connection from within php

On Tue, 1 Jun 2010, What you get is Not what you see wrote:

> Freshly installed on openbsd 4.6 mysql,php and php5-mysql packages.
> Done the configs. Now php and mysql works. But I couldnt make it
> connect to mysql from within php with such a command
> mysql_connect("localhost","user","pass")
> It used to give "Cant connect to mysql through socket error" till I
> change the command to
> mysql_connect(127.0.0.1,"user","pass")
> I want to learn why?
>
Because the socket is in /var, .. and default apache chroot's to /var/www.
I believe there are tricks to make it work, but it's simpler to
just connect  <at> 127.0.0.1.

	Lee
Permalink | Reply | 1 comment |
headers
Paul D. Ouderkirk | 1 Jun 2010 15:51
Picon

Re: Mysql connection from within php

On Tue, Jun 1, 2010 at 9:30 AM, What you get is Not what you see
<wyginwys <at> gmail.com> wrote:
> Freshly installed on openbsd 4.6 mysql,php and php5-mysql packages.
> Done the configs. Now php and mysql works. But I couldnt make it
> connect to mysql from within php with such a command
> mysql_connect("localhost","user","pass")
> It used to give "Cant connect to mysql through socket error" till I
> change the command to
> mysql_connect(127.0.0.1,"user","pass")
> I want to learn why?

From: http://dev.mysql.com/doc/refman/5.0/en/connecting.html

"On Unix, MySQL programs treat the host name localhost specially, in a
way that is likely different from what you expect compared to other
network-based programs. For connections to localhost, MySQL programs
attempt to connect to the local server by using a Unix socket file."

On OpenBSD, the MySQL socket file is outside the httpd chroot, so your
PHP script can't access it.  Accessing 127.0.0.1 over TCP is no
problem.

Paul.

--

-- 
------------------------------
Paul D. Ouderkirk
Senior UNIX System Administrator
paul <at> ouderkirk.ca
------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane