Hey All,
I solved my problem. I have a d-bus client application that identifies
the correct carrier, and thus the correct connection to activate. There
was a race condition where my client was trying to activate the
connection while NetworkManager was already setting up the bearer, and
the fi
All callers of request_wireless_scan() cleared the periodic scan
source immediately before calling the function, so just move that
into request_wireless_scan(). The only one that doesn't clear
it is request_wireless_scan_periodic() but that sets the source
id to 0 already, so the clear has no effe
On Fri, 2016-10-07 at 19:46 +0200, Thomas Haller wrote:
> On Fri, 2016-10-07 at 12:28 -0500, Dan Williams wrote:
> >
> > Some TTY drivers or devices appear to ignore port speed and always
> > report zero. Technically this means the port is hung up and
> > control
> > lines should be disconnected,
On Fri, 2016-10-07 at 12:28 -0500, Dan Williams wrote:
> Some TTY drivers or devices appear to ignore port speed and always
> report zero. Technically this means the port is hung up and control
> lines should be disconnected, but with USB devices many of the serial
> port attributes are meaningles
Some TTY drivers or devices appear to ignore port speed and always
report zero. Technically this means the port is hung up and control
lines should be disconnected, but with USB devices many of the serial
port attributes are meaningless and ignored by some devices.
pppd requires the port's speed
Hi,
While testing NM recently with multiple connections active, I realized that NM
merges all the resolver information into single resolv.conf file and then
submits that as a single interface to resolvconf (e.g. can be seen as
/run/resolvconf/interfaces/NetworkManager)
This bascially inhibits
