Re: spamming router with router solicitations

2019-05-29 Thread Brian J. Murrell 
On Wed, 2019-05-29 at 09:28 +0200, Thomas Haller via networkmanager-
list wrote:
> 
> If this is happening, when you kill NetworkManager with SIGKILL, it
> would not give NetworkManager to cleanup...
> 
>   sudo killall -SIGKILL NetworkManager
> 
> (and veryify that NetworkManager is indeed not running. Maybe first
> `systemctl mask NetworkManager`, so that systemd won't restart it).

Are you suggesting that I kill NM with SIGKILL as a debugging step to
see if the RSes still stop when stopping NM?

If so, that was an interesting experiment:

# killall -SIGKILL NetworkManager
# ps -ef | grep Network
root 15001 1  0 12:02 ?00:00:00 /usr/sbin/NetworkManager 
--no-daemon

So clearly systemd restarted it, but it's not flooding RSes after the
restart.  I even waited 17 minutes and still no flooding.  I want to
leave it like this in case there is anything you want me to investigate
with it.

Otherwise I will continue on with the second part of the experiment
where I mask the service in systemd and kill it with a KILL and see
what happens.

>   grep -R ^ /proc/sys/net/ipv6/conf/

Currently that's:

/proc/sys/net/ipv6/conf/all/accept_dad:0
/proc/sys/net/ipv6/conf/all/accept_ra:1
/proc/sys/net/ipv6/conf/all/accept_ra_defrtr:1
/proc/sys/net/ipv6/conf/all/accept_ra_pinfo:1
/proc/sys/net/ipv6/conf/all/accept_ra_rt_info_max_plen:0
/proc/sys/net/ipv6/conf/all/accept_ra_rtr_pref:1
/proc/sys/net/ipv6/conf/all/accept_redirects:1
/proc/sys/net/ipv6/conf/all/accept_source_route:0
/proc/sys/net/ipv6/conf/all/autoconf:1
/proc/sys/net/ipv6/conf/all/dad_transmits:1
/proc/sys/net/ipv6/conf/all/disable_ipv6:0
/proc/sys/net/ipv6/conf/all/enhanced_dad:1
/proc/sys/net/ipv6/conf/all/force_mld_version:0
/proc/sys/net/ipv6/conf/all/force_tllao:0
/proc/sys/net/ipv6/conf/all/forwarding:0
/proc/sys/net/ipv6/conf/all/hop_limit:64
/proc/sys/net/ipv6/conf/all/keep_addr_on_down:0
/proc/sys/net/ipv6/conf/all/max_addresses:16
/proc/sys/net/ipv6/conf/all/max_desync_factor:600
/proc/sys/net/ipv6/conf/all/mc_forwarding:0
/proc/sys/net/ipv6/conf/all/mldv1_unsolicited_report_interval:1
/proc/sys/net/ipv6/conf/all/mldv2_unsolicited_report_interval:1000
/proc/sys/net/ipv6/conf/all/mtu:1280
/proc/sys/net/ipv6/conf/all/ndisc_notify:0
/proc/sys/net/ipv6/conf/all/optimistic_dad:0
/proc/sys/net/ipv6/conf/all/proxy_ndp:0
/proc/sys/net/ipv6/conf/all/regen_max_retry:3
/proc/sys/net/ipv6/conf/all/router_probe_interval:60
/proc/sys/net/ipv6/conf/all/router_solicitation_delay:1
/proc/sys/net/ipv6/conf/all/router_solicitation_interval:4
/proc/sys/net/ipv6/conf/all/router_solicitations:3
grep: /proc/sys/net/ipv6/conf/all/stable_secret: Input/output error
/proc/sys/net/ipv6/conf/all/temp_prefered_lft:86400
/proc/sys/net/ipv6/conf/all/temp_valid_lft:604800
/proc/sys/net/ipv6/conf/all/use_optimistic:0
/proc/sys/net/ipv6/conf/all/use_tempaddr:0
/proc/sys/net/ipv6/conf/default/accept_dad:1
/proc/sys/net/ipv6/conf/default/accept_ra:1
/proc/sys/net/ipv6/conf/default/accept_ra_defrtr:1
/proc/sys/net/ipv6/conf/default/accept_ra_pinfo:1
/proc/sys/net/ipv6/conf/default/accept_ra_rt_info_max_plen:0
/proc/sys/net/ipv6/conf/default/accept_ra_rtr_pref:1
/proc/sys/net/ipv6/conf/default/accept_redirects:1
/proc/sys/net/ipv6/conf/default/accept_source_route:0
/proc/sys/net/ipv6/conf/default/autoconf:1
/proc/sys/net/ipv6/conf/default/dad_transmits:1
/proc/sys/net/ipv6/conf/default/disable_ipv6:0
/proc/sys/net/ipv6/conf/default/enhanced_dad:1
/proc/sys/net/ipv6/conf/default/force_mld_version:0
/proc/sys/net/ipv6/conf/default/force_tllao:0
/proc/sys/net/ipv6/conf/default/forwarding:0
/proc/sys/net/ipv6/conf/default/hop_limit:64
/proc/sys/net/ipv6/conf/default/keep_addr_on_down:0
/proc/sys/net/ipv6/conf/default/max_addresses:16
/proc/sys/net/ipv6/conf/default/max_desync_factor:600
/proc/sys/net/ipv6/conf/default/mc_forwarding:0
/proc/sys/net/ipv6/conf/default/mldv1_unsolicited_report_interval:1
/proc/sys/net/ipv6/conf/default/mldv2_unsolicited_report_interval:1000
/proc/sys/net/ipv6/conf/default/mtu:1280
/proc/sys/net/ipv6/conf/default/ndisc_notify:0
/proc/sys/net/ipv6/conf/default/optimistic_dad:0
/proc/sys/net/ipv6/conf/default/proxy_ndp:0
/proc/sys/net/ipv6/conf/default/regen_max_retry:3
/proc/sys/net/ipv6/conf/default/router_probe_interval:60
/proc/sys/net/ipv6/conf/default/router_solicitation_delay:1
/proc/sys/net/ipv6/conf/default/router_solicitation_interval:4
/proc/sys/net/ipv6/conf/default/router_solicitations:3
grep: /proc/sys/net/ipv6/conf/default/stable_secret: Input/output error
/proc/sys/net/ipv6/conf/default/temp_prefered_lft:86400
/proc/sys/net/ipv6/conf/default/temp_valid_lft:604800
/proc/sys/net/ipv6/conf/default/use_optimistic:0
/proc/sys/net/ipv6/conf/default/use_tempaddr:0
/proc/sys/net/ipv6/conf/enp2s0/accept_dad:1
/proc/sys/net/ipv6/conf/enp2s0/accept_ra:1
/proc/sys/net/ipv6/conf/enp2s0/accept_ra_defrtr:0
/proc/sys/net/ipv6/conf/enp2s0/accept_ra_pinfo:0
/proc/sys/net/ipv6/conf/enp2s0/accept_ra_rt_info_max_plen:0
/proc/sys/net/ipv6/conf/enp2s

Re: Adding basic OpenVPN PKCS#11 support

2019-05-29 Thread Martin Forssen via networkmanager-list 
I did a first patch which used a naive approach and just added support for
specifying the pkcs11-providers and pkcs11-id in the GUI. This works but is
not elegant or user friendly and requires that openvpn plays nicely with
the desired pkcs#11 provider. In practice this is often a big problem.

After some more reading and investigating I think it is better to do all
the pkcs#11 operations outside openvpn. This is what the openvpn developers
seem to desire and it neatly sidesteps all the issues we have with bad
support for various pkcs#11 libraries in openvpn. Openvpn already supports
offloading these operations via the management interface.

We can use the builtin pkcs#11 support in the cert_chooser so the UI is
fairly simple to implement. The nm-openvpn-service is already responsible
for talking to the management interface of openvpn so that has to support
the new requests. But the question is where to put the code which does the
actual pkcs#11 requests. My initial idea is to use the Gnome pkcs11 support
and put teh code in the auth-dialog program. Does that sound like a good
idea?

On Tue, Apr 2, 2019 at 7:39 PM Thomas Haller  wrote:

> On Tue, 2019-03-26 at 08:41 +0100, Martin Forssen via networkmanager-
> list wrote:
> > Hello,
> >
> > I have the need to run OpenVPN with PKCS#11 hardware certificates on
> > Linux. This does currently not seem to be possible with
> > NetworkManager.
> >
> > I have looked around a bit and realize this is a can of worms. The
> > nice clean solution would require changes to OpenVPN, which so far
> > seems to be hard to get merged.
> >
> > So my plan right now is to take the simplest possible approach and
> > just add text fields where one can enter pkcs11-providers and pkcs11-
> > id (and of course support for importing these values).
> >
> > My question now is if I were to submit patches which does this, is
> > there any chance of them getting merged (assuming they follow coding
> > standard etc)?
> >
>
> Hi,
>
>
> work on this would be great.
>
> Lubomir was working on that, quite a while ago.
>
> Some work in progess is still at [1]. Note this also requires support
> from NetworkManager ([2]).
>
>
> [1]
> https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/commits/lr/p11-forward
> [2]
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/p11-forward
>
>
> best,
> Thomas
>


-- 

Martin Forssén

Director of Information Security

Recorded Future 

+46 760 252357

m...@recordedfuture.com
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: spamming router with router solicitations

2019-05-29 Thread Thomas Haller via networkmanager-list 
On Mon, 2019-05-27 at 06:59 -0400, Brian J. Murrell wrote:
> On Mon, 2019-05-27 at 10:16 +0200, Beniamino Galvani via
> networkmanager-list wrote:
> > Are you sure you don't have other daemons like systemd-networkd
> 
> # repoquery -q systemd-networkd
> systemd-networkd-0:219-62.el7_6.6.x86_64
> 
> # rpm -q systemd-networkd
> package systemd-networkd is not installed
> 
> 
> So, not even installed.
> 
> > or
> > something else active which are racing with NM?
> 
> Fairly sure there is nothing else.


If this is happening, when you kill NetworkManager with SIGKILL, it
would not give NetworkManager to cleanup...

  sudo killall -SIGKILL NetworkManager

(and veryify that NetworkManager is indeed not running. Maybe first
`systemctl mask NetworkManager`, so that systemd won't restart it).

If then the RS flood stops, we know it was sent by NetworkManager.
Otherwise, it wasn't.


For now, I would guess that kernel is sending these solicitations... if
that's the case, the sysctl settings would be interesting:

  grep -R ^ /proc/sys/net/ipv6/conf/



best,
Thomas


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list