More debug info required here, can you run stuff like this?

1) stop NetworkManager
2) killall -TERM modem-manager
3) modem-manager --debug
4) NetworkManager --no-daemon
5) try to connect

then attach the NM and modem-manager logs?  Looks like the AC850 is getting connected OK, but we need to figure out what's going wrong with the PPP negotiation.

Created attachment 653686 [details]
nm.log

Created attachment 653687 [details]
mm.log

It appears that for some reason NetworkManager thinks the modem is disconnected, possibly as a result of this code:

static void
modem_connected_cb (NMModem *modem, GParamSpec *pspec, gpointer user_data)
{
	NMDeviceModem *self = NM_DEVICE_MODEM (user_data);
	NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (self);

	if (   nm_device_get_state (NM_DEVICE (self)) == NM_DEVICE_STATE_ACTIVATED
	    && !nm_modem_get_mm_connected (priv->modem)) {
		/* Fail the device if the modem disconnects unexpectedly */
		nm_device_state_changed (NM_DEVICE (self), NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER);
	}
}

could be a race condition between being activated and the "State" signal from ModemManager or something, but we'll have to patch NM to debug.

Mads,

Please try these F18 scratch builds, which have additional logging that will hopefully let us figure out what's going on:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4739305

and again grab both the NetworkManager and ModemManager logs.  Thanks!

Created attachment 654661 [details]
nm.log

Created attachment 654662 [details]
mm.log

My fault, my debug patch used the wrong log level.  Here's a corrected build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4744674

thanks again.

Created attachment 655223 [details]
nm.log

Created attachment 655224 [details]
mm.log

I cannot spot any relevant difference in the output.

Like before the culprit seems to me to be "could not get port's parent device".

But this latest build had the same version as the previous one - are you sure the change is included?

I will probably give up and lose access to this system very soon, so if you have other tests then please let me know asap.

Worked fine, we've got the NetworkManager logs we want:

NetworkManager[2417]: <info> Activation (ttyS0) successful, device activated.
NetworkManager[2417]: <info> (ttyS0): properties changed:
NetworkManager[2417]: <info>      State -> 70
NetworkManager[2417]: <info> (ttyS0): modem state changed 90 -> 70
NetworkManager[2417]: <info> (ttyS0): device state 100 modem state 70
NetworkManager[2417]: <info> (ttyS0): unexpected disconnect, failing device
NetworkManager[2417]: <info> (ttyS0): device state change: activated -> failed (reason 'modem-no-carrier') [100 120 25]

So that log indicates that everything appears to be working as expected; but your issue is that while you're connected with the 850, you cannot access any sites, correct?

Can you grab:

route -n
ifconfig ppp0

while connected?  What happens if you try to "ping 4.2.2.1"?

# ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data.
^C
--- 4.2.2.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

# ifconfig ppp0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 212.27.18.25  netmask 255.255.255.255  destination 10.64.64.64
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 7  bytes 94 (94.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 759 (759.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data.
^C
--- 4.2.2.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 4999ms

# ifconfig ppp0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 212.27.18.25  netmask 255.255.255.255  destination 10.64.64.64
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 7  bytes 94 (94.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 22  bytes 1263 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# iptables-save 
# Generated by iptables-save v1.4.16.2 on Fri Nov 30 22:16:22 2012
*filter
:INPUT ACCEPT [5543:24270137]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2417:128884]
COMMIT
# Completed on Fri Nov 30 22:16:22 2012

Pings are sent, nothing received ... except for the initial ppp chat and DNS info.

I reproduced the issue with two different devices, the AC860 and a Sony Ericsson GC87.  Both are PCMCIA cards that use the serial_cs kernel driver.  But a Sierra-based device worked fine.  At this point I'm starting to think the 3.6 kernel is the problem, but I'll need to do some more tests on the serial_cs driver to figure that out I guess.  There shouldn't be any significant difference between the serial/tty behavior of any of the serial drivers, and I know the 860 worked a few kernel versions ago, so I'm thinking kernel bug.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Checked again with the Sierra 860 and kernel 3.9.10 and no joy.  Not sure wahts' going on here without a bunch of kernel debugging.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.