Re: Network-Manager Trunk and Fedora 12



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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]