Re: Network-Manager Trunk and Fedora 12

[Dan Williams <dcbw redhat com>]

On Tue, 2010-03-30 at 15:45 -0400, Darren Albers wrote:
> On Tue, Mar 30, 2010 at 3:42 PM, Dan Williams <dcbw redhat com> wrote:
> > On Thu, 2010-03-25 at 20:13 -0400, Darren Albers wrote:
> >> On Thu, Mar 18, 2010 at 9:43 PM, Darren Albers <dalbers gmail com> wrote:
> >> > On Thu, Mar 18, 2010 at 8:28 PM, Dan Williams <dcbw redhat com> wrote:
> >> >> On Wed, 2010-03-17 at 21:47 -0400, Darren Albers wrote:
> >> >>> On Wed, Mar 17, 2010 at 9:18 PM, Dan Williams <dcbw redhat com> wrote:
> >> >>> > On Mon, 2010-03-15 at 22:59 -0400, Darren Albers wrote:
> >> >>> >> On Mon, Mar 15, 2010 at 7:22 PM, Dan Williams <dcbw redhat com> wrote:
> >> >>> >> > On Thu, 2010-03-11 at 20:10 -0500, Darren Albers wrote:
> >> >>> >> >> On Thu, Mar 11, 2010 at 6:56 PM, Dan Williams <dcbw redhat com> wrote:
> >> >>> >> >> > On Wed, 2010-03-10 at 15:45 -0500, Darren Albers wrote:
> >> >>> >> >> >> Are there any testing packages I can install to enable Bluetooth DUN
> >> >>> >> >> >> support on Fedora 12?
> >> >>> >> >> >
> >> >>> >> >> > The latest builds in koji should work; I've been doing some heavy
> >> >>> >> >> > ModemManager work the past week or two and thus there aren't any builds
> >> >>> >> >> > in a suitable state for F12 testing quite yet.
> >> >>> >> >> >
> >> >>> >> >> > http://koji.fedoraproject.org/koji/buildinfo?buildID=157530
> >> >>> >> >> >
> >> >>> >> >> > Dan
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >> >> Sorry one further question, is it safe to use these builds with an
> >> >>> >> >> older version of ModemManager?   Safe obviously being a relatively
> >> >>> >> >> term considering it isn't even in testing yet but enough for someone
> >> >>> >> >> to play with?
> >> >>> >> >
> >> >>> >> > Yes, they should be pretty safe for versions of NM from 2010 or very
> >> >>> >> > late 2009.
> >> >>> >> >
> >> >>> >> > Dan
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >> Thanks Dan!  I actually tested it on Fedora 13 but ModemManager
> >> >>> >> doesn't seem to like how the Blackberry responds.   I filed a bug
> >> >>> >> report on it but as usual for Blackberry's they seem to respond a
> >> >>> >> little differently that what you expect.  In this case it responds
> >> >>> >> with:
> >> >>> >> ** Message: (rfcomm0) opening serial device...
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): probe requested by plugin 'Generic'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): --> 'AT+GCAP<CR>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): <--
> >> >>> >> '+GCAP:<CR><LF><CR><LF>OK<CR><LF>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): --> 'AT+GCAP<CR>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): <--
> >> >>> >> '+GCAP:<CR><LF><CR><LF>OK<CR><LF>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): --> 'AT+GCAP<CR>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): <--
> >> >>> >> '+GCAP:<CR><LF><CR><LF>OK<CR><LF>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): --> 'ATI<CR>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): <-- 'Research In Motion BlackBerry
> >> >>> >> IP Modem<CR><LF><CR><LF>OK<CR><LF>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): --> 'AT+CPIN?<CR>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): <-- '+CPIN:
> >> >>> >> READY<CR><LF><CR><LF>OK<CR><LF>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): --> 'AT+CGMM<CR>'
> >> >>> >> ** (modem-manager:2729): DEBUG: (rfcomm0): <-- 'RIM BlackBerry Device
> >> >>> >> 4001507<CR><LF><CR><LF>OK<CR><LF>'
> >> >>> >> ** Message: (rfcomm0) closing serial device...
> >> >>> >>
> >> >>> >> I guess when it does this ModemManager doesn't recognize the response
> >> >>> >> from CGMM (Model Query?) so it doesn't go any further?  CPIN seems to
> >> >>> >> match what is expected in mm-generic-gsm.c but I can't seem to follow
> >> >>> >> what it expects from CGMM and where that is checked.
> >> >>> >
> >> >>> > It's not responding to GCAP so we don't actually know whether it's a
> >> >>> > CDMA or a GSM device.  What kind is yours?
> >> >>> >
> >> >>> > If yours is a GSM device, then that's great since it responds to AT+CPIN
> >> >>> > correctly and we'll know it's a GSM device with recent ModemManager
> >> >>> > versions.
> >> >>> >
> >> >>> > If yours is a CDMA device and it responds to AT+CPIN, then I hate the
> >> >>> > world and we'll have to figure something else out :)
> >> >>> >
> >> >>> > Dan
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>>
> >> >>> You can save your hate for more important things like bad wireless
> >> >>> cards then since it is a GSM device!   I can get a CDMA device to test
> >> >>> if you want to know how that kind of device responds.  So if a more
> >> >>> recent version of ModemManager is used it may recognize it as a Modem?
> >> >>
> >> >> Yeah, which I'll build today, hopefully.
> >> >>
> >> >> Dan
> >> >>
> >> >>
> >> >>
> >> >
> >> > Great news, thank you!
> >> >
> >>
> >> Dan,
> >>
> >> I tested the builds today and it detected the modem but when I
> >> attempted to connect using Network Manager it failed and I see this in
> >> /var/log/messages:
> >> Mar 25 19:51:58 localhost dbus-daemon: Rejected send message, 2
> >> matched rules; type="method_return", sender=":1.12" (uid=0 pid=1424
> >> comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error
> >> name="(unset)" requested_reply=0 destination=":1.10" (uid=0 pid=1414
> >> comm="NetworkManager))
> >
> > At what point does that failure come?  This could be caused by recent
> > (well, year-old) dbus policy changes for unrequested reply messages
> > which I'm not 100% sure how to get fixed...
> >
> > walters; what could be the cause of this sort of thing again?
> >
> > Dan
> >
> >
> >
> 
> It comes after the AT commands are sent I think and it looks like it
> is actually up when this kicks off.   Would you like the output of the
> modemmanager plugin in debug or just the general messages from the log
> around it?    What seems weird to me is shouldn't their be an
> interface name defined somewhere so a dbus policy can be created to
> allow it to send from that interface to another?

easy selinux test: "setenforce 0" and try again and see if you get the
error still.

Dan