date:20160316

Re: proper way to terminate bgpd (removing routes from RIB upon termination of bgpd)

2016-03-16 Thread Peter Hessler

Are you sending any specific signals to bgpd?  Is it "just" `pkill bgpd`
or are you sending -6 or -9 (or others)?

Normally, I use `rcctl stop bgpd` or `/etc/rc.d/bgpd stop` depending on
how senile my finger memory is.  In such cases, all routes are removed
from the kernel fib as bgpd stops running.


On 2016 Mar 15 (Tue) at 17:36:56 +0100 (+0100), Laurent CARON wrote:
:Hi,
:
:I'm wondering what a good way of terminating bgpd would be.
:
:Context: OpenBSD box (5.8 GENERIC.MP#1236 amd64) running ospfd, bgpd, ...
:
:When terminating bgpd (pkill bgpd), routes installed by bgpd are not being
:removed from the routing table (this server is getting 4 full views and a lot
:of peering sessions (see bgpctl show rib mem below)).
:
:How to have the routes removed from the rib when the bgpd daemon is killed ?
:
:Thanks
:
::bgpctl show rib mem:
:RDE memory statistics
:583225 IPv4 unicast network entries using 22.2M of memory
: 95527 IPv6 unicast network entries using 5.1M of memory
:   1355164 rib entries using 82.7M of memory
:   6696529 prefix entries using 409M of memory
:   1150903 BGP path attribute entries using 132M of memory
:402714 BGP AS-PATH attribute entries using 21.8M of memory,
:   and holding 1150903 references
: 32147 BGP attributes entries using 1.2M of memory
:   and holding 3629437 references
: 32146 BGP attributes using 805K of memory
:RIB using 674M of memory
:

-- 
Experience is what causes a person to make new mistakes instead of old
ones.

OpenIKED: Interoperability problem w/ Juniper SRX

2016-03-16 Thread Bornkessel, Bernd

Hi,

I'm currently facing a problem establishing IKEv2 site-to-site VPN between 
OpenBSD and a Juniper SRX firewall.
The tunnel can be sucessfully established if it is initiated by the Juniper SRX 
firewall. If I configure OpenIKED to actively initiate the tunnel, the SRX 
firewall complains about a syntax error.

OpenBSD version:


root@openbsd:~# uname -a
OpenBSD openbsd.test.loc 5.8 GENERIC#1170 amd64
root@openbsd:~#


Juniper SRX version:


{primary:node0}[edit]
superman@juniper_srx-node0# run show version
node0:
--
Hostname: juniper_srx-node0
Model: srx240h2
JUNOS Software Release [12.3X48-D20.4]

node1:
--
Hostname: juniper_srx-node1
Model: srx240h2
JUNOS Software Release [12.3X48-D20.4]

{primary:node0}[edit]
superman@juniper_srx-node0#


OpenIKED acting as initiator:
*

OpenIKED configuration:
===

ikev2 vpn_corp active esp \
from 172.16.0.0/16 to 172.17.0.0/16 \
local 1.1.1.1 peer 2.2.2.2 \
ikesa auth hmac-sha2-256 enc aes-256 group modp2048 \
childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
srcid 1.1.1.1 dstid 2.2.2.2 \
ikelifetime 28800 lifetime 3600 \
psk 


OpenIKED log:
=

ca_privkey_serialize: type RSA_KEY length 1190
ca_pubkey_serialize: type RSA_KEY length 270
/etc/iked.conf: loaded 1 configuration rules
config_getpolicy: received policy
ikev2 "vpn_corp" active esp inet from 172.16.0.0/16 to 172.17.0.0/16 local 
1.1.1.1 peer 2.2.2.2 ikesa enc aes-256 prf hmac-sha2-256,hmac-sha1,hmac-md5 
auth hmac-sha2-256 group modp2048 childsa enc aes-256 auth hmac-sha2-256 group 
modp2048 srcid 1.1.1.1 dstid 2.2.2.2 ikelifetime 28800 lifetime 3600 bytes 
536870912 psk 0x
config_getpfkey: received pfkey fd 3
config_getcompile: compilation done
config_getsocket: received socket fd 4
config_getsocket: received socket fd 5
config_getsocket: received socket fd 7
config_getsocket: received socket fd 8
ca_reload: local cert type RSA_KEY
config_getocsp: ocsp_url none
ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0
ikev2_init_ike_sa: initiating "vpn_corp"
ikev2_policy2id: srcid IPV4/1.1.1.1 length 8
ikev2_add_proposals: length 60
ikev2_next_payload: length 64 nextpayload KE
ikev2_next_payload: length 264 nextpayload NONCE
ikev2_next_payload: length 36 nextpayload NOTIFY
ikev2_nat_detection: local source 0x08e787c5d31f442f 0x 
1.1.1.1:500
ikev2_next_payload: length 28 nextpayload NOTIFY
ikev2_nat_detection: local destination 0x08e787c5d31f442f 0x 
2.2.2.2:500
ikev2_next_payload: length 28 nextpayload NOTIFY
ikev2_next_payload: length 14 nextpayload NONE
ikev2_pld_parse: header ispi 0x08e787c5d31f442f rspi 0x 
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 462 
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 64
ikev2_pld_sa: more 0 reserved 0 length 60 proposal #1 protoid IKE spisize 0 
xforms 6 spi 0
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1
ikev2_pld_xform: more 0 reserved 0 length 8 type PRF id HMAC_MD5
ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 264
ikev2_pld_ke: dh group MODP_2048 reserved 0
ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 36
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP
ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 14
ikev2_pld_notify: protoid NONE spisize 0 type SIGNATURE_HASH_ALGORITHMS
ikev2_msg_send: IKE_SA_INIT request from 1.1.1.1:500 to 2.2.2.2:500 msgid 0, 
462 bytes
sa_state: INIT -> SA_INIT
ikev2_recv: IKE_SA_INIT response from responder 2.2.2.2:500 to 1.1.1.1:500 
policy 'vpn_corp' id 0, 474 bytes
ikev2_recv: ispi 0x08e787c5d31f442f rspi 0x9d7d95f32328d0ac
ikev2_recv: updated SA to peer 2.2.2.2:500 local 1.1.1.1:500
ikev2_pld_parse: header ispi 0x08e787c5d31f442f rspi 0x9d7d95f32328d0ac 
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x20 msgid 0 length 474 
response 1
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 48
ikev2_pld_sa: more 0 reserved 0 length 44 proposal #1 protoid IKE spisize 0 
xforms

Re: proper way to terminate bgpd (removing routes from RIB upon termination of bgpd)

2016-03-16 Thread Laurent CARON


I'm "just" using 'pkill bgpd'

On 16/03/2016 11:26, Peter Hessler wrote:

Are you sending any specific signals to bgpd?  Is it "just" `pkill bgpd`
or are you sending -6 or -9 (or others)?

Normally, I use `rcctl stop bgpd` or `/etc/rc.d/bgpd stop` depending on
how senile my finger memory is.  In such cases, all routes are removed
from the kernel fib as bgpd stops running.


On 2016 Mar 15 (Tue) at 17:36:56 +0100 (+0100), Laurent CARON wrote:
:Hi,
:
:I'm wondering what a good way of terminating bgpd would be.
:
:Context: OpenBSD box (5.8 GENERIC.MP#1236 amd64) running ospfd, bgpd, ...
:
:When terminating bgpd (pkill bgpd), routes installed by bgpd are not being
:removed from the routing table (this server is getting 4 full views and a lot
:of peering sessions (see bgpctl show rib mem below)).
:
:How to have the routes removed from the rib when the bgpd daemon is killed ?
:
:Thanks
:
::bgpctl show rib mem:
:RDE memory statistics
:583225 IPv4 unicast network entries using 22.2M of memory
: 95527 IPv6 unicast network entries using 5.1M of memory
:   1355164 rib entries using 82.7M of memory
:   6696529 prefix entries using 409M of memory
:   1150903 BGP path attribute entries using 132M of memory
:402714 BGP AS-PATH attribute entries using 21.8M of memory,
:   and holding 1150903 references
: 32147 BGP attributes entries using 1.2M of memory
:   and holding 3629437 references
: 32146 BGP attributes using 805K of memory
:RIB using 674M of memory
:

Re: ntop on openbsd

2016-03-16 Thread Stuart Henderson

On 2016-03-15, Indunil Jayasooriya  wrote:
> Hi,
>
> i installed ntop by going to /usr/ports/net/ntop/ (then, make , make
> install)
> 
> How to  run it on web mode?

This isn't the ntop you think it is, it's a super-old one which should
probably just be removed.

I have a WIP port of ntopng at https://junkpile.org/ntopng.tgz. It looks
quite nice but it crashes when it sees some JSON over HTTP packets, so it
doesn't stay running very long for me. I'll look at it again sometime but
upstream want me to try a devel version which needs a bunch of work first
(OpenBSD has a non-standard bpf_timeval struct which gets in the way of
porting many programs which do packet capture).

Re: wireshark illegal instruction on older systems

2016-03-16 Thread Peter Kay

Not wishing to be a dick about this, but what sort of notification is
in place to stop time being wasted trying to run programs on
incompatible CPUs? Obviously old processors need to be supported in
base for embedded systems, but it would be nice to have a note for
packages.

Is it viable to redirect/use ports with global compiler flags set to
'no SSE' or in some cases '486 compatible'

I ran it on a pentium ii laptop because it was lying around and seemed
like it would do the job, and a pentium ii system to verify, and
because it's being used for retro gaming. I do have more modern
systems.

On 15/03/2016, Christian Weisgerber  wrote:
> On 2016-03-15, Stuart Henderson  wrote:
>
>> Looks like Qt autodetects at build time, we probably want to configure
>> on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
>> (SSE2 is probably reasonable to expect for Qt5 apps, it's present on
>> Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
>> for heavy GUI apps).
>
> Well, Peter did attempt to run it on Pentium II, which doesn't have
> SSE2.
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de

Re: groupdel 'command' don't remove group id

2016-03-16 Thread Paul de Weerd

On Wed, Mar 16, 2016 at 08:21:35AM +0100, Max Power wrote:
| Find! Thank You Paul.
| 
| in /etc/passwd [about user]
| 
| testx:*:1001:1000::/home/testx:/usr/bin/false

That doesn't match what you said earlier.  This has user testx with
UID 1001 and GID 1000.  In your previous mail you said user testx has
UID 1001 and GID 1001:

| > | # id testx: uid=1001(testx) gid=1001 groups=1001, 1000(laboratory)

So something is weird here.

| So I have no choice but to replace '1001' with '1000' ?
| 
| testx:*:1000:1000::/home/testx:/usr/bin/false Ok?

You have lots of choices when it comes to the login group of the user,
about 65 thousand of them.  What makes sense depends on what you want
this user to do / have access to / etc.  Making the login group of the
testx user 1000 would put him in the laboratory group (again, as per
your data).  Does that make sense?  Probably, since the user is
already in that group according to /etc/group.

But we cannot tell you what group this user belongs in.  That's up to
you to decide.  It seems that you are missing some basic unix
knowledge in this area, you may want to read up on this or take a
basic unix course to expand your knowledge in this area.

Cheers,

Paul 'WEiRD' de Weerd

| > On Wed, Mar 16, 2016 at 07:10:09AM +0100, Max Power wrote:
| > | Hi Todd, guys.
| > |
| > | LogOut e reboot has been the first thing I have done,
| > | but nothing... gid is always there!
| > |
| > | The group not exist but gid: yes!
| > | # groups testx: group: can't find group 'testx'
| > | # id testx: uid=1001(testx) gid=1001 groups=1001, 1000(laboratory)
| >
| > The gid id reports here is the group that's configured in your passwd
| > file.  The line will look like this:
| >
| > testx:*:1001:1001:Test User:/home/testx:/bin/ksh
| > -
| >
| > That's the GID right there.  A user always has a login group that's
| > configed in /etc/passwd.  If you don't want this group to be used,
| > don't put users in it (either in /etc/group as additional groups or in
| > /etc/passwd as the login group).
| >
| > Cheers,
| >
| > Paul 'WEiRD' de Weerd
| >
| > | I just can not understand this!
| > | can someone please help me?
| > | Thanks.
| > |
| > | The same situation, with other deleted group, is on another server with
| > | OpenBSD 5.7 amd64.
| > |
| > | > A user's active groups are set at login time.  Removing a group
| > | > from the group file does not affect processes that are already
| > | > running.  If you logout and login again after removing the group
| > | > you should no longer be a member of the group.
| > | >
| > | >  - todd
| > |
| >
| > --
| >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
| > +++>-]<.>++[<>-]<+.--.[-]
| >  http://www.weirdnet.nl/
| 

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/

Re: groupdel 'command' don't remove group id

2016-03-16 Thread Christopher Zimmermann

On Wed, 16 Mar 2016 08:21:35 +0100 "Max Power"
 wrote:

> Find! Thank You Paul.
>
> in /etc/passwd [about user]
>
> testx:*:1001:1000::/home/testx:/usr/bin/false
>
> So I have no choice but to replace '1001' with '1000' ?

I like using the users (10) group as primary group for all human users.

> testx:*:1000:1000::/home/testx:/usr/bin/false Ok?
>
>
>
>
> > On Wed, Mar 16, 2016 at 07:10:09AM +0100, Max Power wrote:
> > | Hi Todd, guys.
> > |
> > | LogOut e reboot has been the first thing I have done,
> > | but nothing... gid is always there!
> > |
> > | The group not exist but gid: yes!
> > | # groups testx: group: can't find group 'testx'
> > | # id testx: uid=1001(testx) gid=1001 groups=1001,
> > | 1000(laboratory)
> >
> > The gid id reports here is the group that's configured in your
> > passwd file.  The line will look like this:
> >
> > testx:*:1001:1001:Test User:/home/testx:/bin/ksh
> > -
> >
> > That's the GID right there.  A user always has a login group that's
> > configed in /etc/passwd.  If you don't want this group to be used,
> > don't put users in it (either in /etc/group as additional groups or
> > in /etc/passwd as the login group).
> >
> > Cheers,
> >
> > Paul 'WEiRD' de Weerd
> >
> > | I just can not understand this!
> > | can someone please help me?
> > | Thanks.
> > |
> > | The same situation, with other deleted group, is on another
> > | server with OpenBSD 5.7 amd64.
> > |
> > | > A user's active groups are set at login time.  Removing a group
> > | > from the group file does not affect processes that are already
> > | > running.  If you logout and login again after removing the group
> > | > you should no longer be a member of the group.
> > | >
> > | >  - todd
> > |
> >
> > --
> >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> > +++>-]<.>++[<>-]<+.--.[-]
> >  http://www.weirdnet.nl/
>


--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
2779 7F73 44FD 0736 B67A  C410 69EC 7922 34B4 2566

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

Re: groupdel 'command' don't remove group id

2016-03-16 Thread Max Power

Find! Thank You Paul.

in /etc/passwd [about user]

testx:*:1001:1000::/home/testx:/usr/bin/false

So I have no choice but to replace '1001' with '1000' ?

testx:*:1000:1000::/home/testx:/usr/bin/false Ok?




> On Wed, Mar 16, 2016 at 07:10:09AM +0100, Max Power wrote:
> | Hi Todd, guys.
> |
> | LogOut e reboot has been the first thing I have done,
> | but nothing... gid is always there!
> |
> | The group not exist but gid: yes!
> | # groups testx: group: can't find group 'testx'
> | # id testx: uid=1001(testx) gid=1001 groups=1001, 1000(laboratory)
>
> The gid id reports here is the group that's configured in your passwd
> file.  The line will look like this:
>
> testx:*:1001:1001:Test User:/home/testx:/bin/ksh
> -
>
> That's the GID right there.  A user always has a login group that's
> configed in /etc/passwd.  If you don't want this group to be used,
> don't put users in it (either in /etc/group as additional groups or in
> /etc/passwd as the login group).
>
> Cheers,
>
> Paul 'WEiRD' de Weerd
>
> | I just can not understand this!
> | can someone please help me?
> | Thanks.
> |
> | The same situation, with other deleted group, is on another server with
> | OpenBSD 5.7 amd64.
> |
> | > A user's active groups are set at login time.  Removing a group
> | > from the group file does not affect processes that are already
> | > running.  If you logout and login again after removing the group
> | > you should no longer be a member of the group.
> | >
> | >  - todd
> |
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/

Re: groupdel 'command' don't remove group id

2016-03-16 Thread Paul de Weerd

On Wed, Mar 16, 2016 at 07:10:09AM +0100, Max Power wrote:
| Hi Todd, guys.
| 
| LogOut e reboot has been the first thing I have done,
| but nothing... gid is always there!
| 
| The group not exist but gid: yes!
| # groups testx: group: can't find group 'testx'
| # id testx: uid=1001(testx) gid=1001 groups=1001, 1000(laboratory)

The gid id reports here is the group that's configured in your passwd
file.  The line will look like this:

testx:*:1001:1001:Test User:/home/testx:/bin/ksh
-

That's the GID right there.  A user always has a login group that's
configed in /etc/passwd.  If you don't want this group to be used,
don't put users in it (either in /etc/group as additional groups or in
/etc/passwd as the login group).

Cheers,

Paul 'WEiRD' de Weerd

| I just can not understand this!
| can someone please help me?
| Thanks.
| 
| The same situation, with other deleted group, is on another server with
| OpenBSD 5.7 amd64.
| 
| > A user's active groups are set at login time.  Removing a group
| > from the group file does not affect processes that are already
| > running.  If you logout and login again after removing the group
| > you should no longer be a member of the group.
| >
| >  - todd
| 

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/

Re: groupdel 'command' don't remove group id

2016-03-16 Thread Max Power

Hi Todd, guys.

LogOut e reboot has been the first thing I have done,
but nothing... gid is always there!

The group not exist but gid: yes!
# groups testx: group: can't find group 'testx'
# id testx: uid=1001(testx) gid=1001 groups=1001, 1000(laboratory)

I just can not understand this!
can someone please help me?
Thanks.

The same situation, with other deleted group, is on another server with
OpenBSD 5.7 amd64.

> A user's active groups are set at login time.  Removing a group
> from the group file does not affect processes that are already
> running.  If you logout and login again after removing the group
> you should no longer be a member of the group.
>
>  - todd

Re: proper way to terminate bgpd (removing routes from RIB upon termination of bgpd)

OpenIKED: Interoperability problem w/ Juniper SRX

Re: proper way to terminate bgpd (removing routes from RIB upon termination of bgpd)

Re: ntop on openbsd

Re: wireshark illegal instruction on older systems

Re: groupdel 'command' don't remove group id

Re: groupdel 'command' don't remove group id

Re: groupdel 'command' don't remove group id

Re: groupdel 'command' don't remove group id

Re: groupdel 'command' don't remove group id

10 matches

Site Navigation

Mail list logo

Footer information