Re: httpd(8) online manual page missing

[Raf Czlonka]

On Wed, Apr 02, 2014 at 07:37:30AM BST, Theo de Raadt wrote:
> > > The FAQ gets updated when the new release is out. Not before.
> > 
> > Following that chain of thought, shouldn't manual pages, or any official
> > documents referenced in the FAQ for that matter, default to '-release'
> > (or '-stable') rather than '-current'?
> 
> They should reference -release or -stable.  There really is little
> difference between them.  We do perhaps a handful of commits to -stable
> a release.
> 
> > > People running -current can cope. Really, noone's getting stabbed in
> > > the eye.
> > 
> > People running -current, sure. FAQ, however is aimed (or in part at
> > least) at people who don't necessarily (yet!) know what '-current' means
> > so the current - pun intended ;^) - behaviour is somewhat confusing.
> 
> Correct.
> 
> The FAQ should not document -current.
> 
> That's the common place for keeners, and we love to have lots of keeners.
> But everyone has to learn somewhere, and that's the stable footing of
> -release.

Thanks for clarifying that, Theo.

In that case, all references to manual pages in the FAQ should point to
5.4 (or whatever the '-release' might be) rather than '-current', i.e.:

http://www.openbsd.org/cgi-bin/man.cgi?query=dmesg&sektion=8&manpath=OpenBSD+5.4

rather than:

http://www.openbsd.org/cgi-bin/man.cgi?query=dmesg&sektion=8

Otherwise, we're running into an issue of manual pages having subtle
differences between '-release' and '-current' or appear to be missing
altogether and that's confusing to anyone reading the FAQ, not only, but
especially newcomers.

Cheers,

Raf

P.S. I think we can all live with 'i386' as the "default" arch ;^)

Re: httpd(8) online manual page missing

[Theo de Raadt]

> > The FAQ gets updated when the new release is out. Not before.
> 
> Following that chain of thought, shouldn't manual pages, or any official
> documents referenced in the FAQ for that matter, default to '-release'
> (or '-stable') rather than '-current'?

They should reference -release or -stable.  There really is little
difference between them.  We do perhaps a handful of commits to -stable
a release.

> > People running -current can cope. Really, noone's getting stabbed in
> > the eye.
> 
> People running -current, sure. FAQ, however is aimed (or in part at
> least) at people who don't necessarily (yet!) know what '-current' means
> so the current - pun intended ;^) - behaviour is somewhat confusing.

Correct.

The FAQ should not document -current.

That's the common place for keeners, and we love to have lots of keeners.
But everyone has to learn somewhere, and that's the stable footing of
-release.

Re: httpd(8) online manual page missing

[Raf Czlonka]

On Wed, Apr 02, 2014 at 07:14:11AM BST, Theo de Raadt wrote:

> The FAQ gets updated when the new release is out. Not before.

Following that chain of thought, shouldn't manual pages, or any official
documents referenced in the FAQ for that matter, default to '-release'
(or '-stable') rather than '-current'?

> People running -current can cope. Really, noone's getting stabbed in
> the eye.

People running -current, sure. FAQ, however is aimed (or in part at
least) at people who don't necessarily (yet!) know what '-current' means
so the current - pun intended ;^) - behaviour is somewhat confusing.

Regards,

Raf

Re: httpd(8) online manual page missing

[Alexander Hall]

On April 2, 2014 8:14:11 AM CEST, Theo de Raadt  wrote:
>> On April 2, 2014 6:41:01 AM CEST, Raf Czlonka
> wrote:
>> >Hi all,
>> >
>> >As I go through the FAQ I've noticed a httpd(8) online manual page
>> >missing[0]. The link in question comes from 4.8 section[1] of the
>FAQ:
>> >
>> >[...]
>> >/var/www: OpenBSD's web server lives here.
>> >[...]
>> >
>> >[0] http://www.openbsd.org/cgi-bin/man.cgi?query=httpd&sektion=8
>> 
>> Indeed, as the faq reflects the latest release, and httpd has been
>dropped since. You'll find it if you specify 5.4 in the search form.
>> 
>> Maybe the link should include that... Nick? :-)
>> 
>> /Alexander
>> 
>> >[1] http://www.openbsd.org/faq/faq4.html#Partitioning
>
>The FAQ gets updated when the new release is out.  Not before.
>
>People running -current can cope.  Really, noone's getting stabbed
>in the eye.

But in this case the faq refers to the -current manage, which is nonexistent. 
It's about people running -release, not -current.

Re: httpd(8) online manual page missing

[Theo de Raadt]

> On April 2, 2014 6:41:01 AM CEST, Raf Czlonka  wrote:
> >Hi all,
> >
> >As I go through the FAQ I've noticed a httpd(8) online manual page
> >missing[0]. The link in question comes from 4.8 section[1] of the FAQ:
> >
> >[...]
> >/var/www: OpenBSD's web server lives here.
> >[...]
> >
> >[0] http://www.openbsd.org/cgi-bin/man.cgi?query=httpd&sektion=8
> 
> Indeed, as the faq reflects the latest release, and httpd has been dropped 
> since. You'll find it if you specify 5.4 in the search form.
> 
> Maybe the link should include that... Nick? :-)
> 
> /Alexander
> 
> >[1] http://www.openbsd.org/faq/faq4.html#Partitioning

The FAQ gets updated when the new release is out.  Not before.

People running -current can cope.  Really, noone's getting stabbed
in the eye.

Re: httpd(8) online manual page missing

[Alexander Hall]

On April 2, 2014 6:41:01 AM CEST, Raf Czlonka  wrote:
>Hi all,
>
>As I go through the FAQ I've noticed a httpd(8) online manual page
>missing[0]. The link in question comes from 4.8 section[1] of the FAQ:
>
>[...]
>/var/www: OpenBSD's web server lives here.
>[...]
>
>[0] http://www.openbsd.org/cgi-bin/man.cgi?query=httpd&sektion=8

Indeed, as the faq reflects the latest release, and httpd has been dropped 
since. You'll find it if you specify 5.4 in the search form.

Maybe the link should include that... Nick? :-)

/Alexander

>[1] http://www.openbsd.org/faq/faq4.html#Partitioning
>
>Regards,
>
>Raf

httpd(8) online manual page missing

[Raf Czlonka]

Hi all,

As I go through the FAQ I've noticed a httpd(8) online manual page
missing[0]. The link in question comes from 4.8 section[1] of the FAQ:

[...]
/var/www: OpenBSD's web server lives here.
[...]

[0] http://www.openbsd.org/cgi-bin/man.cgi?query=httpd&sektion=8
[1] http://www.openbsd.org/faq/faq4.html#Partitioning

Regards,

Raf

Re: Gnome and OpenBSD 5.4

[Johan Mellberg]

My emails do not often get to the list for some reason so that is why you get 
this reply to you own address as well. 

Anyway, why don't you try using ports, which should be better than trying to 
adapt information valid for a three-year old, unsupported version? There is an 
effort ongoing to try to get gnome working better:

http://undeadly.org/cgi?action=article&sid=20140219085851

/Johan

Sent from a smartphone of some sort. Damn you autocorrect.

> 2 apr 2014 kl. 05:53 skrev Nex6|Bill :
> 
> I am trying to get Gnome to work, and its giving me fits. I tryed to follow
> this link:
> Tutorial: Install Gnome Desktop and Gnome Display Manager on
> OpenBSD 4.8 - GabSoftware
> 
> 
> for the most part, but now instead of boot to gdm
> or xdm it boots to the console and when I startx. it 
> says file
> /root/.serverauth does not exist. 
> 
> any ideas? on what i missed?
> 
> -Nex6

Gnome and OpenBSD 5.4

[Nex6|Bill]

I am trying to get Gnome to work, and its giving me fits. I tryed to follow
this link:
Tutorial: Install Gnome Desktop and Gnome Display Manager on
OpenBSD 4.8 - GabSoftware


for the most part, but now instead of boot to gdm
or xdm it boots to the console and when I startx. it 
says file
/root/.serverauth does not exist. 

any ideas? on what i missed?

-Nex6

Re: system resets with openbsd flash drive

[Mikkel C. Simonsen]

Jim Rowan wrote:

Hi,

I'm trying to resurrect some neoware ca22 thinclient boxes, and seeing 
strange behavior I don't know how to interpret.


What can I do next?


I have used quite a few Neoware thin clients for OpenBSD (and FreeBSD) 
systems. I boot from an USB floppy or CD on those that support that, or 
connect a CD-drive to the IDE connector. In all cases I have installed 
on the internal flash module. Larger modules are available at low cost.


Best regards,

Mikkel C. Simonsen

Re: perl, ping and ... ? subsystem ?

[sven falempin]

On Tue, Apr 1, 2014 at 3:25 PM, sven falempin  wrote:
> Hello,
>
> A few days ago i was asking about pids and learn something.
>
> I am monitoring closely some interfaces and expect to move this into
> ifstated as a configuration.
> I am trying to keep it simple and i do a proto in perl.
>
> There is multiple default routes, and i want to test if the underlying
> network is ok or not.
>
> The following small function is checking the netwokr by icmping a peer
> (the peer depends of the underlying network i want to test). The ping
> refuse to bind $_[0]->{ 'fixed-address' } only in script perl when no
> -d !
>
> 35  sub lsystem {
> 36say (Dumper(@_));
> 37return system(@_);
> 38  }
>
>
>102  sub is_ifup {
>103my @cmd = ('/sbin/ping', '-q', '-c', '2', '-w', '1');
>104push @cmd, '-I', $_[0]->{ 'fixed-address' }, $_[0]->{ peer_test };
>105return not lsystem( @cmd );
>106  }
>
> perl exectution :
>
> $VAR1 = '/usr/bin/pkill';
> $VAR2 = '-HUP';
> $VAR3 = '-f';
> $VAR4 = '^dhclient: trunk0';
>
> $VAR1 = '/sbin/ping';
> $VAR2 = '-q';
> $VAR3 = '-c';
> $VAR4 = '2';
> $VAR5 = '-w';
> $VAR6 = '1';
> $VAR7 = '-I';
> $VAR8 = '10.0.0.126';
> $VAR9 = '10.0.0.171';
>
> ping: bind: Can't assign requested address
>
> #but just after same command is ok ...
>
> [0] ulis-v12-GW 34# /sbin/ping -q -c 2 -w 1 -I 10.0.0.126 10.0.0.171
> PING 10.0.0.171 (10.0.0.171): 56 data bytes
> --- 10.0.0.171 ping statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 29.048/30.200/31.352/1.152 ms
> [0] ulis-v12-GW 35#
>
> and if i relaunch perl it is nok.
>
> Something i found strange, once i launch the script with -d , it does
> the job (and add a route for this network)
> and then no more problem.
>
> I do not know where to look , perl doc or ping ?
>

pff my eyes are not in the right place, obviously dhclient is doing
something to the iface , i have to wait a bit before using ping. (OR
wait for ??? )

Sorry for the noise.



-- 
-
() ascii ribbon campaign - against html e-mail
/\

perl, ping and ... ? subsystem ?

[sven falempin]

Hello,

A few days ago i was asking about pids and learn something.

I am monitoring closely some interfaces and expect to move this into
ifstated as a configuration.
I am trying to keep it simple and i do a proto in perl.

There is multiple default routes, and i want to test if the underlying
network is ok or not.

The following small function is checking the netwokr by icmping a peer
(the peer depends of the underlying network i want to test). The ping
refuse to bind $_[0]->{ 'fixed-address' } only in script perl when no
-d !

35  sub lsystem {
36say (Dumper(@_));
37return system(@_);
38  }


   102  sub is_ifup {
   103my @cmd = ('/sbin/ping', '-q', '-c', '2', '-w', '1');
   104push @cmd, '-I', $_[0]->{ 'fixed-address' }, $_[0]->{ peer_test };
   105return not lsystem( @cmd );
   106  }

perl exectution :

$VAR1 = '/usr/bin/pkill';
$VAR2 = '-HUP';
$VAR3 = '-f';
$VAR4 = '^dhclient: trunk0';

$VAR1 = '/sbin/ping';
$VAR2 = '-q';
$VAR3 = '-c';
$VAR4 = '2';
$VAR5 = '-w';
$VAR6 = '1';
$VAR7 = '-I';
$VAR8 = '10.0.0.126';
$VAR9 = '10.0.0.171';

ping: bind: Can't assign requested address

#but just after same command is ok ...

[0] ulis-v12-GW 34# /sbin/ping -q -c 2 -w 1 -I 10.0.0.126 10.0.0.171
PING 10.0.0.171 (10.0.0.171): 56 data bytes
--- 10.0.0.171 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 29.048/30.200/31.352/1.152 ms
[0] ulis-v12-GW 35#

and if i relaunch perl it is nok.

Something i found strange, once i launch the script with -d , it does
the job (and add a route for this network)
and then no more problem.

I do not know where to look , perl doc or ping ?


-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: Some SSH clients unable to connect to latest snapshot

[Emilio Perea]

On Tue, Apr 01, 2014 at 11:06:44AM -0700, Chris Cappuccio wrote:
> Emilio Perea [epe...@walkereng.com] wrote:
> > When using the latest snapshot, some ssh clients are unable to connect.
> > I don't know whether this is due to a problem with the client or the
> > server, but hope someone can point me in the right direction. If it is a
> > server problem, I will of course send a proper bug report.
> > 
> > I first noticed the problem when using an older version of putty on a
> > Windows terminal server. After updating it to the latest version it
> > worked fine, so I'm thinking it's a client problem. However, later I see
> > that both Xming and X-win32 get the same error, though both are using
> > the latest version of putty.
> > 
> 
> http://marc.info/?l=openbsd-cvs&m=139596131723206&w=2
> http://marc.info/?l=openbsd-cvs&m=139574041614940&w=2

Thanks, Chris!

pfsync: failed to receive bulk update

[Kapetanakis Giannis]

After updating my primary firewall to current, the pfsync initial sync 
does not end.


Primary firewall is
 OpenBSD 5.5-current (GENERIC.MP) #0: Tue Apr  1 19:26:27 EEST 2014
with latest 5.5 errata applied,

secondary firewall is a bit older but I'm afraid to update cause this 
might be the only working one.

OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb  7 11:45:09 MST 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

# grep pfsync /var/log/messages
Apr  1 19:29:24 primary /bsd: carp: pfsync0 demoted group carp by 32 to 
164 (pfsync init)
Apr  1 19:29:24 primary /bsd: carp: pfsync0 demoted group pfsync by 32 
to 32 (pfsync init)
Apr  1 19:29:24 primary /bsd: carp: pfsync0 demoted group carp by 1 to 
165 (pfsync bulk start)
Apr  1 19:29:24 primary /bsd: carp: pfsync0 demoted group pfsync by 1 to 
33 (pfsync bulk start)
Apr  1 20:56:59 primary /bsd: carp: pfsync0 demoted group carp by -1 to 
32 (pfsync bulk fail)
Apr  1 20:56:59 primary /bsd: carp: pfsync0 demoted group pfsync by -1 
to 32 (pfsync bulk fail)
Apr  1 20:56:59 primary /bsd: carp: pfsync0 demoted group carp by -32 to 
0 (pfsync init)
Apr  1 20:56:59 primary /bsd: carp: pfsync0 demoted group pfsync by -32 
to 0 (pfsync init)

Apr  1 20:56:59 primary /bsd: pfsync: failed to receive bulk update

# pfctl -si

State Table  Total Rate

  current entries   111638

  searches   55232462987851.9/s

  inserts  2808797  446.8/s

  removals 2697159  429.0/s


It does get states from backup firewall since it has almost the same number of 
entries (100K)


The logs on backup firewall say:
Apr  1 19:27:17 backup /bsd: carp: pfsync0 demoted group carp by 1 to 1 (pfsync 
link state down)
Apr  1 19:27:17 backup /bsd: carp: pfsync0 demoted group pfsync by 1 to 1 
(pfsync link state down)
Apr  1 19:27:27 backup /bsd: carp: pfsync0 demoted group carp by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:27:27 backup /bsd: carp: pfsync0 demoted group pfsync by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:27:45 backup /bsd: carp: pfsync0 demoted group carp by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:27:45 backup /bsd: carp: pfsync0 demoted group pfsync by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:28:55 backup /bsd: carp: pfsync0 demoted group carp by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:28:55 backup /bsd: carp: pfsync0 demoted group pfsync by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:29:24 backup /bsd: carp: pfsync0 demoted group carp by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:29:24 backup /bsd: carp: pfsync0 demoted group pfsync by -1 to 0 
(pfsync bulk cancelled)
Apr  1 19:38:36 backup /bsd: carp: pfsync0 demoted group carp by -1 to 0 
(pfsync link state up)
Apr  1 19:38:36 backup /bsd: carp: pfsync0 demoted group pfsync by -1 to 0 
(pfsync link state up)

The are connected with cross-over cable and they have set skip on that 
interface.
It has been working like this the last few years.

regards,

Giannis

Re: pf / ping and reply-to

[Kapetanakis Giannis]

On 01/04/14 18:32, Kapetanakis Giannis wrote:

Hi,

I had the following rule in pf which served me well so far. After 
updating today to current (from 5.4 Jan)

icmp replied from firewall stopped working.

# pfctl -sr | head -2

pass in log quick on vlan101 inet from 192.168.1.1 to (vlan101) flags 
S/SA keep state (no-sync) reply-to 10.1.101.1@vlan101

pass out log quick inet from any to 192.168.1.1 flags S/SA

The actual rule is:
pass in quick log on $mgmt_if from $admin to ($mgmt_if) keep state 
(no-sync) reply-to ($mgmt_if $mgmt_gw)


On pf log I get

Apr 01 18:24:03.077339 rule 0/(match) pass in on vlan101: 
192.168.1.1.33831 > 10.1.101.2.22: S 2819604746:2819604746(0) win 
29200  (DF)
Apr 01 18:24:05.838976 rule 0/(match) pass in on vlan101: 192.168.1.1> 
10.1.101.2: icmp: echo request (DF)
Apr 01 18:24:05.838988 rule 1/(match) pass out on vlan102: 10.1.102.2 
> 192.168.1.1: icmp: echo reply (DF)\\


The ssh works fine.

The icmp reply does not get back from vlan101 (according to reply-to) 
but it goes from vlan102 (route entry for 192.168.1.1).


any ideas,

Thanks

G


The latest errata seems to fix the problem
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/001_icmp.patch.sig

G

Re: Some SSH clients unable to connect to latest snapshot

[Chris Cappuccio]

Emilio Perea [epe...@walkereng.com] wrote:
> When using the latest snapshot, some ssh clients are unable to connect.
> I don't know whether this is due to a problem with the client or the
> server, but hope someone can point me in the right direction. If it is a
> server problem, I will of course send a proper bug report.
> 
> I first noticed the problem when using an older version of putty on a
> Windows terminal server. After updating it to the latest version it
> worked fine, so I'm thinking it's a client problem. However, later I see
> that both Xming and X-win32 get the same error, though both are using
> the latest version of putty.
> 

http://marc.info/?l=openbsd-cvs&m=139596131723206&w=2
http://marc.info/?l=openbsd-cvs&m=139574041614940&w=2

Some SSH clients unable to connect to latest snapshot

[Emilio Perea]

When using the latest snapshot, some ssh clients are unable to connect.
I don't know whether this is due to a problem with the client or the
server, but hope someone can point me in the right direction. If it is a
server problem, I will of course send a proper bug report.

I first noticed the problem when using an older version of putty on a
Windows terminal server. After updating it to the latest version it
worked fine, so I'm thinking it's a client problem. However, later I see
that both Xming and X-win32 get the same error, though both are using
the latest version of putty.

This is the snapshot:

OpenBSD 5.5-current (GENERIC.MP) #44: Mon Mar 31 11:14:26 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

This is the error on X-Win32:

Looking up host "herakles.walkertx.com"
Connecting to 192.168.60.74 port 22
Using SSPI from SECUR32.DLL
Server version: SSH-2.0-OpenSSH_6.6
Using SSH protocol version 2
We claim version: SSH-2.0-PuTTY_Local:_Aug_17_2012_15:07:42
GSSAPI key-exchange initialisation failed
No credentials are available in the security package.
Doing Diffie-Hellman group exchange
Server unexpectedly closed network connection
FATAL ERROR: Server unexpectedly closed network connection

This is from /var/log/authlog:

Apr  1 11:20:03 herakles sshd[9594]: Server listening on 0.0.0.0 port 22.
Apr  1 11:20:03 herakles sshd[9594]: Server listening on :: port 22.
Apr  1 11:35:53 herakles sshd[27087]: fatal: no matching mac found: client 
hmac-sha1,hmac-sha1-96,hmac-md5 server 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512
 [preauth]
Apr  1 11:40:47 herakles sshd[28093]: Accepted publickey for eperea from 
192.168.61.11 port 57192 ssh2: ECDSA 
81:3b:89:f2:25:23:09:a1:16:8b:de:08:57:83:b4:20
Apr  1 11:45:22 herakles sshd[20497]: Accepted publickey for eperea from 
192.168.61.11 port 57151 ssh2: RSA 
ea:de:cc:6a:87:83:d1:39:fd:44:8b:28:a5:46:1e:87

The failure was from X-Win32, the following three two were from an
OpenBSD 5.5 VM and the latest putty.

pf / ping and reply-to

[Kapetanakis Giannis]

Hi,

I had the following rule in pf which served me well so far. After 
updating today to current (from 5.4 Jan)

icmp replied from firewall stopped working.

# pfctl -sr | head -2

pass in log quick on vlan101 inet from 192.168.1.1 to (vlan101) flags 
S/SA keep state (no-sync) reply-to 10.1.101.1@vlan101

pass out log quick inet from any to 192.168.1.1 flags S/SA

The actual rule is:
pass in quick log on $mgmt_if from $admin to ($mgmt_if) keep state 
(no-sync) reply-to ($mgmt_if $mgmt_gw)


On pf log I get

Apr 01 18:24:03.077339 rule 0/(match) pass in on vlan101: 
192.168.1.1.33831 > 10.1.101.2.22: S 2819604746:2819604746(0) win 29200 
 (DF)
Apr 01 18:24:05.838976 rule 0/(match) pass in on vlan101: 192.168.1.1> 
10.1.101.2: icmp: echo request (DF)
Apr 01 18:24:05.838988 rule 1/(match) pass out on vlan102: 10.1.102.2 > 
192.168.1.1: icmp: echo reply (DF)\\


The ssh works fine.

The icmp reply does not get back from vlan101 (according to reply-to) 
but it goes from vlan102 (route entry for 192.168.1.1).


any ideas,

Thanks

G

Re: system resets with openbsd flash drive

[Martin Brandenburg]

Jim Rowan  wrote:

> Hi,
> 
> I'm trying to resurrect some neoware ca22 thinclient boxes, and seeing  
> strange behavior I don't know how to interpret.
> 
> I have a bootable 5.4 usb stick.   If I put that in the box, right  
> after the initial bios boot screen (after it says "via c7 1.0Ghz"),  
> the system resets.  This is before it tests the memory or probes for  
> devices.   If I go into bios setup, and *then* plug the usb stick in,  
> it resets immediately.  If I let it start booting windows xp (which is  
> on it's flash DOM), and then plug it in, it continues to boot.
> 
> Suspicious that it was the usb drive itself, I tried three separate  
> brands.  Same thing.
> I put grml on one of them, it boots fine.  I put nanobsd on the same  
> one; again boots fine.   With openbsd on the usb drive, and I wipe out  
> the beginning of the drive with dd, it then does not reset.
> 
> I haven't yet managed to get a dmesg captured, but it's a rather  
> unremarkable via c7 motherboard.  I've tried changing all the bios  
> settings to the most conservative, disabled everything I can, ... same  
> thing.  Oh, and I've tried a different box (I have several of them)  
> and a different power supply; neither had any effect.
> 
> One of the confusing things is the reset that happens when the usb  
> drive is plugged in while in the bios setup...
> 
> What can I do next?

What brand of BIOS is this? I had the exact same problem on a Gigabyte
motherboard with Award's BIOS before. I assumed it was a BIOS bug and
gave up because it wasn't a particularly good motherboard to begin with.

- Martin

Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

[Andy]

Hi Stuart,

I have tried with a carp netmask equal to the physical interface (/24 
for example in my lab) and a /32 (like when you have many CARP IP 
addresses).


From investigation the problem seems to occur because when a box is the 
carp master, their will be a /32 route in the routing table for that 
specific IP address (regardless of netmask in hostname.carpX) attached 
to the interface 'carpX'.


For example, run 'netstat -rn' on your carp master and you will see 
lines like the following;

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio 
Iface
170.16.3/24170.16.3.1 UG 00 -48 
em1
170.16.3.2 08:00:27:a4:02:3d  UHLc   04 - 4 
lo0
170.16.3.3 08:00:27:9f:83:ca  UHLc   1  1019447 - L   4 
em1
170.16.3.4 170.16.3.4 UH 00 - 4 
carp1


.2 is this firewall (master), .3 is the other firewall (backup), and .4 
is the shared CARP IP.
Because the interface for the .4 IP address is carp1 and not em1 (where 
the BGP neighbor is connected), setting the nexthop to .4 fails.



If you run the same on the backup;
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio 
Iface
170.16.3/24link#2 UC 20 - 4 
em1
170.16.3.1 c2:00:01:e4:00:00  UHLc   5   143456 - L   4 
em1
170.16.3.2 08:00:27:a4:02:3d  UHLc   4   158601 - L   4 
em1


Notice their is no /32 route for the CARP IP address as it is not the 
carp master.


As a result the BGP announcements from the backup firewall do 
successfully set the nexthop!


So only the backup firewall can set the nexthop of BGP announcements to 
a CARP IP address. The master has those /32 routes which breaks the 
nexthop validation check because it thinks the IP you are trying to set 
is not in the network directly connected to the neighbor even though it 
actually is.


Cheers, Andy.


On Tue 01 Apr 2014 15:03:29 BST, Stuart Henderson wrote:

On 2014-04-01, Andy  wrote:

Specifically to accommodate CARP interfaces, to allow setting the
nexthop on an announced route to a CARP IP address?

This currently doesn't work as OpenBGPD considers the CARP interface as
being a different network to the physical interface, even though they
are on the same segment and valid according to the BGP rules of being
directly connected.


What netmasks are you using?

I think perhaps there needs to be some reach-around where a carp has a
/32 or /128, to determine the netmask of the carpdev and use that instead
in some cases...

Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

[Stuart Henderson]

On 2014-04-01, Andy  wrote:
> Specifically to accommodate CARP interfaces, to allow setting the 
> nexthop on an announced route to a CARP IP address?
>
> This currently doesn't work as OpenBGPD considers the CARP interface as 
> being a different network to the physical interface, even though they 
> are on the same segment and valid according to the BGP rules of being 
> directly connected.

What netmasks are you using?

I think perhaps there needs to be some reach-around where a carp has a
/32 or /128, to determine the netmask of the carpdev and use that instead
in some cases...

Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

[Andy]

On Tue 01 Apr 2014 10:27:03 BST, Andy wrote:

On Tue 01 Apr 2014 10:10:02 BST, Andy wrote:

Hi Claudio and Stuart, thanks for your replies.

On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote:

On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote:

On 2014/03/31 09:31, Andy wrote:

Hi Stuart,

Does Henning, Claudio or any of the other developers have any plan to
implement BGP equal cost multi-path support (maximum-paths) to
OpenBGPd?


No idea about anyone else's plans...



For me it is fairly low on the todo list. I think that BGP equal cost
multi-path will not trigger most of the time since the routes need
to be
equal till fairly far down the decision tree. There are more important
things to solve first (some of them bugs, some of them "features" and
some
of them real features).


PS forgive me for bringing up an old discussion, but do any of these
features include enhancing the nexthop validation code?

Specifically to accommodate CARP interfaces, to allow setting the
nexthop on an announced route to a CARP IP address?

This currently doesn't work as OpenBGPD considers the CARP interface
as being a different network to the physical interface, even though
they are on the same segment and valid according to the BGP rules of
being directly connected.

Cheers :)
Andy



PS; Forgot to mention that we have sponsored a PhD/RA chap who is 
slowly looking at this specific 'setting nexthop to CARP' enhancement 
in his spare time. He's currently familiarizing himself with the 
OpenBGPD code.






Yea that will definitely be the case for multi-homed redundant
Transits. And I have no doubt there are other very important things on
the list too.

If its OK I would like to highlight however that nearly every network
I know (the vast majority of the networks who we peer with at LONAP
and LINX in London and Amsterdam at least) have multiple routers
attached to the IXP exchanges, and in all those cases nearly every
route learned from those peers do match all the way down.

Our peerings now cover over 13% of the full Internet routing table
(currently 65549 routes out of 487459) and this is increasing.

And so around 12% of the Internet is being forced out only one IXP
connection via one ASBR leaving the other one mostly idle except for
some inbound packets which I am trying to steer with MEDs etc.

Anyway, this is becoming more common as IXPs now reach more and more
data centers and providers connect to the same exchanges at multiple
data centers.


I guess it should be quite quick to add as OpenOSPFd already
supports this
and the kernel FIB is ready.


I don't think it's safe to assume "quick" here - at the very least,
bgp
has a bunch more code handling nexthop validity than ospfd does.


The bgpd RIB and FIB is a fair bit different from the ospfd one. While
some basic ideas may be reused I doubt there is a lot of code that
could
be shared.


Additionally I suspect this will result in bgpd needing to revalidate
routes more often, which is a known problem area for out-of-memory
crashes
in bgpd's RDE.


Yeah, this is something we need to fix first (see above).



Interesting, does that mean OpenBGPD currently only revalidates the
FIB routes and not the RIB routes.


Adding these two features has obvious and significant benefits.
BIRD already
supports ECMP and BFD but I would rather stick with OpenBGPd as it is
developed against OpenBSD :)


Note that I mostly added the BIRD port to test interop with
bgpd/ospfd -
I've only run it minimally to test basic operation, and haven't had
much
feedback about the port, so consider it not particularly well
tested on
OpenBSD at this point.

If running BIRD I'd suggest probably doing it on a Linux-ish system..
While it does get some use on BSDs (I know of someone using it for a
big
wireless network on FreeBSD) it's originally written for Linux and
some
things aren't supported on BSDs. Case in point:

$ cat `find . -type f` | grep -c RTF_MPATH
0



:) As mentioned we would rather stick with OpenBGPD than try and make
BIRD work. I really don't want to have to go down that road..



There is also a GSoC project to get BFD into OpenBSD. So if a
student is
interested in working on that that would be an oportunity.



Great news, crossing fingers we have some budding student with awesome
C skills is up for the challenge.


As always, thanks for your great work!
Cheers Andy.

Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

[Andy]

On Tue 01 Apr 2014 10:10:02 BST, Andy wrote:

Hi Claudio and Stuart, thanks for your replies.

On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote:

On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote:

On 2014/03/31 09:31, Andy wrote:

Hi Stuart,

Does Henning, Claudio or any of the other developers have any plan to
implement BGP equal cost multi-path support (maximum-paths) to
OpenBGPd?


No idea about anyone else's plans...



For me it is fairly low on the todo list. I think that BGP equal cost
multi-path will not trigger most of the time since the routes need to be
equal till fairly far down the decision tree. There are more important
things to solve first (some of them bugs, some of them "features" and
some
of them real features).


PS forgive me for bringing up an old discussion, but do any of these 
features include enhancing the nexthop validation code?


Specifically to accommodate CARP interfaces, to allow setting the 
nexthop on an announced route to a CARP IP address?


This currently doesn't work as OpenBGPD considers the CARP interface as 
being a different network to the physical interface, even though they 
are on the same segment and valid according to the BGP rules of being 
directly connected.


Cheers :)
Andy





Yea that will definitely be the case for multi-homed redundant
Transits. And I have no doubt there are other very important things on
the list too.

If its OK I would like to highlight however that nearly every network
I know (the vast majority of the networks who we peer with at LONAP
and LINX in London and Amsterdam at least) have multiple routers
attached to the IXP exchanges, and in all those cases nearly every
route learned from those peers do match all the way down.

Our peerings now cover over 13% of the full Internet routing table
(currently 65549 routes out of 487459) and this is increasing.

And so around 12% of the Internet is being forced out only one IXP
connection via one ASBR leaving the other one mostly idle except for
some inbound packets which I am trying to steer with MEDs etc.

Anyway, this is becoming more common as IXPs now reach more and more
data centers and providers connect to the same exchanges at multiple
data centers.


I guess it should be quite quick to add as OpenOSPFd already
supports this
and the kernel FIB is ready.


I don't think it's safe to assume "quick" here - at the very least, bgp
has a bunch more code handling nexthop validity than ospfd does.


The bgpd RIB and FIB is a fair bit different from the ospfd one. While
some basic ideas may be reused I doubt there is a lot of code that could
be shared.


Additionally I suspect this will result in bgpd needing to revalidate
routes more often, which is a known problem area for out-of-memory
crashes
in bgpd's RDE.


Yeah, this is something we need to fix first (see above).



Interesting, does that mean OpenBGPD currently only revalidates the
FIB routes and not the RIB routes.


Adding these two features has obvious and significant benefits.
BIRD already
supports ECMP and BFD but I would rather stick with OpenBGPd as it is
developed against OpenBSD :)


Note that I mostly added the BIRD port to test interop with
bgpd/ospfd -
I've only run it minimally to test basic operation, and haven't had
much
feedback about the port, so consider it not particularly well tested on
OpenBSD at this point.

If running BIRD I'd suggest probably doing it on a Linux-ish system..
While it does get some use on BSDs (I know of someone using it for a
big
wireless network on FreeBSD) it's originally written for Linux and some
things aren't supported on BSDs. Case in point:

$ cat `find . -type f` | grep -c RTF_MPATH
0



:) As mentioned we would rather stick with OpenBGPD than try and make
BIRD work. I really don't want to have to go down that road..



There is also a GSoC project to get BFD into OpenBSD. So if a student is
interested in working on that that would be an oportunity.



Great news, crossing fingers we have some budding student with awesome
C skills is up for the challenge.


As always, thanks for your great work!
Cheers Andy.

Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

[Andy]

Definitely agree Theo. Our topology is less than ideal just to ensure 
we have OSPF's fast convergence changing the nexthops of our intra-AS 
routers for what are otherwise BGP routes.


Whilst people say bird 1.4 supports BFD, BIRD is generally used on 
Linux route servers (not forwarding traffic), and OpenBGPD is mostly 
used on OpenBSD routers which are forwarding traffic (imho).


Cheers, Andy.

On Tue 01 Apr 2014 01:09:12 BST, Theo de Raadt wrote:

There is also a GSoC project to get BFD into OpenBSD. So if a student is
interested in working on that that would be an oportunity.


Honestly, I think many people are building hacks because they lack a
carefully-integrated BFD.  If we had it, it would not solve fair-share
problems, but it would solve many other cases.

I am baffled noone has stepped up with something yet, GSoC or otherwise.

Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

[Andy]

Hi Claudio and Stuart, thanks for your replies.

On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote:

On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote:

On 2014/03/31 09:31, Andy wrote:

Hi Stuart,

Does Henning, Claudio or any of the other developers have any plan to
implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd?


No idea about anyone else's plans...



For me it is fairly low on the todo list. I think that BGP equal cost
multi-path will not trigger most of the time since the routes need to be
equal till fairly far down the decision tree. There are more important
things to solve first (some of them bugs, some of them "features" and some
of them real features).



Yea that will definitely be the case for multi-homed redundant 
Transits. And I have no doubt there are other very important things on 
the list too.


If its OK I would like to highlight however that nearly every network I 
know (the vast majority of the networks who we peer with at LONAP and 
LINX in London and Amsterdam at least) have multiple routers attached 
to the IXP exchanges, and in all those cases nearly every route learned 
from those peers do match all the way down.


Our peerings now cover over 13% of the full Internet routing table 
(currently 65549 routes out of 487459) and this is increasing.


And so around 12% of the Internet is being forced out only one IXP 
connection via one ASBR leaving the other one mostly idle except for 
some inbound packets which I am trying to steer with MEDs etc.


Anyway, this is becoming more common as IXPs now reach more and more 
data centers and providers connect to the same exchanges at multiple 
data centers.



I guess it should be quite quick to add as OpenOSPFd already supports this
and the kernel FIB is ready.


I don't think it's safe to assume "quick" here - at the very least, bgp
has a bunch more code handling nexthop validity than ospfd does.


The bgpd RIB and FIB is a fair bit different from the ospfd one. While
some basic ideas may be reused I doubt there is a lot of code that could
be shared.


Additionally I suspect this will result in bgpd needing to revalidate
routes more often, which is a known problem area for out-of-memory crashes
in bgpd's RDE.


Yeah, this is something we need to fix first (see above).



Interesting, does that mean OpenBGPD currently only revalidates the FIB 
routes and not the RIB routes.



Adding these two features has obvious and significant benefits. BIRD already
supports ECMP and BFD but I would rather stick with OpenBGPd as it is
developed against OpenBSD :)


Note that I mostly added the BIRD port to test interop with bgpd/ospfd -
I've only run it minimally to test basic operation, and haven't had much
feedback about the port, so consider it not particularly well tested on
OpenBSD at this point.

If running BIRD I'd suggest probably doing it on a Linux-ish system..
While it does get some use on BSDs (I know of someone using it for a big
wireless network on FreeBSD) it's originally written for Linux and some
things aren't supported on BSDs. Case in point:

$ cat `find . -type f` | grep -c RTF_MPATH
0



:) As mentioned we would rather stick with OpenBGPD than try and make 
BIRD work. I really don't want to have to go down that road..




There is also a GSoC project to get BFD into OpenBSD. So if a student is
interested in working on that that would be an oportunity.



Great news, crossing fingers we have some budding student with awesome 
C skills is up for the challenge.



As always, thanks for your great work!
Cheers Andy.

Re: OpenBGPd - Exporting Communities to route server peers

[Thorleif Wiik [BCIX]]

Hi,


On Mon, Mar 31, 2014 at 11:38 PM, Claudio Jeker wrote:

> On Sun, Mar 30, 2014 at 01:08:12PM +0200, Thorleif Wiik [BCIX] wrote:
> > Hi,
> >
> >
> > were running OpenBGPd since a long a time as route servers.
>
> I guess those are configured as route-reflectors. Correct?
>

As a route server deployed at an IXP.


> > We now want to export certain BGP Communities to all route server peers.
> >
> > We already set the communities, but according to the documentation,
> > I'm unsure how to export them to the peers.
> >
> > We currently use the following config line to set a community e.g.
> > 16374:15 to all peers in the groups "n15-v4" and  "n15-v6"
>
> The above paragraph does not match with the example. On is to all peers in
> group the other is from all peers in group.
>

What we want to do is to export the location communities on the regarding
prefixes
to all peers.

community for location a: 16374:15
community for location b: 16374:36

and so on.

We already built groups for the peers based on the locations, e.g.
"group n15-v4", "group a36-v4"  and so on.

We now want to set the  the location communities on alle prefixes like this:

193.107.120.0/22
Communities: 16374:15


194.107.120.0/22 
Communities: 16374:36

But the important thing is that we also want to export these communities to
all peers.

I'm currently looking for the best solutions for this.

The following example works, but do not export the communities.


>
> > # remarks: 16374:15   learned at  Location Nonnendammallee 15
> > match from { group n15-v4,  group n15-v6 }  set community $ASNUM:15
> >
> >
> > When I look into the prefixes on the production box,
> > I'll see the correct communitiy, for example:
> >
> > >bgpctl sh rib as 48173  detail
> >
> > ..
> > BGP routing table entry for 193.107.120.0/22
> > 48173
> > Nexthop 193.178.185.33 (via 193.178.185.33) from n15-v4-unbelievable
> > (94.198.63.8)
> > Origin IGP, metric 1, localpref 100, external, valid, best
> > Last update: 05w2d01h ago
> > Communities: 16374:15
> > ..
> >
> >
> > When the connected peers look into their prefixes received from the route
> > server,
> > they don't see these  communities.
> >
> > My question: What's the most efficient way
> > to export these communities to all my peers, now ?
> >
>
> Normally I would set the communities on the originating routes and not on
> the route server. At least that way the route is tagged properly from the
> start.
>

We want to give our peers the possibility to do some traffic engineering
regarding where they deployed their routers. As our peers do not set set
the mentioned
communities, we as an IXP want to set them and export these to give some of
the
peers with multiple ports in multiple locations the chance to balance the
traffic.




Thanks, Thorleif



>
> --
> :wq Claudio
>
>


-- 
Thorleif Wiik, CTO
thorleif.w...@bcix.de

 Tel: +49 160 90378641

BCIX Management GmbH / BCIX e.V.
Stromstrasse 5
10555 Berlin - Germany

http://www.bcix.de/
http://twitter.com/bcix
https://www.facebook.com/BCIX.Internet.Exchange

rss2email feed header field missing

[Peter Kane]

Hello

Since around the snapshot of 28 March rss2email has been delivering
its feeds with no "from" header field containing the feed name, so
everything appears as if from the default sender
(b...@dev.null.invalid). I don't think there have been any changes
related to rss2email, so does this imply the change is related to
smtpd? I was already using smtpd before it was migrated to default
mailer status, but it seems to have undergone a few changes recently.
I don't think the email client (Mutt) would alter the headers. Here is
part of a typical feed header:

>From b...@dev.null.invalid Thu Mar 27 14:52:43 2014
Return-Path: b...@dev.null.invalid
Delivered-To: user@host
Received: from localhost (1000@localhost [local]);
by localhost (OpenSMTPD) with ESMTPA id 4fea0f2a;
for ;
Thu, 27 Mar 2014 14:52:43
Message-Id: <10516280821498716486.enqueue@host>
Content-Disposition: inline
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: user@host
Subject:
X-RSS-ID:
User-Agent: rss2email
X-RSS-URL:
Date:
X-RSS-TAGS:
X-RSS-Feed:
From: "feed name"  <-- whole field now missing
Status:  <-- also removed
Content-Length:
Lines:

Changing the rss2email config.py doesn't seem to help.

Thanks, Peter

Re: how to query running process for its ulimit values

[Imre Oolberg]

On Mon, 2014-03-31 at 13:16 -0700, Philip Guenther wrote:
> On Mon, Mar 31, 2014 at 11:10 AM, Imre Oolberg  wrote:
> ...
> > But i wonder how i could ask the system how much are the so to say
> > ulimits of the running unbound process, e.g. number of open files?
> 
> There's currently no way to do that from a non-privileged process and
> no canned way to do it from a privileged process.
> 
> A privileged process could do it by using kvm_getprocs() to get the
> kinfo_proc for the target process, then kvm_read() the struct plimit
> for the process from the address found in kinfo->p_limit.

Thank you for quick and clear reply. (After reading my own mail i must
say i said confusing things in the line of 'how to query running
process' and 'how i could ask system', what i meant actually was just to
get to know what are the limits in effect.)

Generally i would feel more comfortable if i could check if limits that
are set actually took effect. So may i ask if there are any plans to
introduce this? And i am sorry being just OpenBSD user i most probably
dont realize what work it takes to implement this.


Best regards,

Imre