Are you installing from source?
If so you should run apt-get build-dep networkmanager to get most of the
required dependencies to build
For gudev its likely complaining that it doesnt have the dev package.
-Kevin
On Jun 4, 2013 12:56 AM, "Paul Connor" wrote:
> Facing a major bug with 0.9.4.0 i
Facing a major bug with 0.9.4.0 in ubuntu 12.04 LTS
Thought I would install the latest package of network manager to begin the
debug process but seeing this problem after running ./configure
configure: error: Package requirements (gudev-1.0 >= 165) were not met:
No package 'gudev-1.0' found
Con
Dan Williams writes:
> Is it likely the device requires 0/1/2/3/4/5, or does any MAC address
> work as long as it's explicitly set?
Good question. I thought any address would work, and that the modem
would pick it up from the DHCP and/or ARP requests from the host. But I
may be wrong. Testing
On Tue, 2013-06-04 at 00:33 +0200, Bjørn Mork wrote:
> Dan Williams writes:
> > On Mon, 2013-06-03 at 21:31 +, Graham Inggs wrote:
> >> My Huawei E1820 works fine with ModemManager in PPP mode.
> >> I tried to get it to work with NDISDUP. I added the following lines to
> >> plugins/huawei/77
Dan Williams writes:
> On Mon, 2013-06-03 at 21:31 +, Graham Inggs wrote:
>> My Huawei E1820 works fine with ModemManager in PPP mode.
>> I tried to get it to work with NDISDUP. I added the following lines to
>> plugins/huawei/77-mm-huawei-net-port-types.rules:
>>
>> # Huawei E1820 firmware
On Tue, 2013-06-04 at 00:09 +0200, Bjørn Mork wrote:
> Graham Inggs writes:
>
> > My Huawei E1820 works fine with ModemManager in PPP mode.
> > I tried to get it to work with NDISDUP. I added the following lines to
> > plugins/huawei/77-mm-huawei-net-port-types.rules:
> >
> > # Huawei E1820 fir
Graham Inggs writes:
> My Huawei E1820 works fine with ModemManager in PPP mode.
> I tried to get it to work with NDISDUP. I added the following lines to
> plugins/huawei/77-mm-huawei-net-port-types.rules:
>
> # Huawei E1820 firmware 11.831.03.00.00
> SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}==
On Mon, 2013-06-03 at 16:45 -0500, Dan Williams wrote:
> On Mon, 2013-06-03 at 21:31 +, Graham Inggs wrote:
> > My Huawei E1820 works fine with ModemManager in PPP mode.
> > I tried to get it to work with NDISDUP. I added the following lines to
> > plugins/huawei/77-mm-huawei-net-port-types.r
On Mon, 2013-06-03 at 21:31 +, Graham Inggs wrote:
> My Huawei E1820 works fine with ModemManager in PPP mode.
> I tried to get it to work with NDISDUP. I added the following lines to
> plugins/huawei/77-mm-huawei-net-port-types.rules:
>
> # Huawei E1820 firmware 11.831.03.00.00
> SUBSYSTEMS
My Huawei E1820 works fine with ModemManager in PPP mode.
I tried to get it to work with NDISDUP. I added the following lines to
plugins/huawei/77-mm-huawei-net-port-types.rules:
# Huawei E1820 firmware 11.831.03.00.00
SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="02",
ATTRS{bInterfaceSubClass}==
Do you now have a PDP context #20 as reported by the AT+CGDCONT?
command?
Dan
Yup!
+CGDCONT: 0,"IP","","",0,0,0,0
+CGDCONT: 1,"IP","","",0,0,0,0
+CGDCONT: 2,"IP","internet","",0,0,0,0
+CGDCONT: 20,"IP","internet","",0,0,0,0
UNIVERSITY OF CAPE TOWN
This e-mail
On Mon, 2013-06-03 at 18:17 +, Graham Inggs wrote:
> So it's interesting that the NDISDUP=? reported a range of (1-20) while
> the CGDCONT=? reports a range of (0-31). Can you try using
> NDISDUP=21,1,"internet" for me?
>
> In any case, I think we should probably pass the CID to NDISDUP, ther
So it's interesting that the NDISDUP=? reported a range of (1-20) while
the CGDCONT=? reports a range of (0-31). Can you try using
NDISDUP=21,1,"internet" for me?
In any case, I think we should probably pass the CID to NDISDUP, there
are other references to that, but we couldn't get a straight an
On Mon, 2013-06-03 at 17:28 +, Graham Inggs wrote:
> Graham, can you do some other tests for us? Can you try other CIDs?
>
> AT^NDISDUP=,1,""
>
> You noted the response for AT^NDISDUP=? included (1-20); what's the
> result of:
>
> AT+CGDCONT=?
>
> Thanks!
> Dan
>
>
> Transcript follows,
Graham, can you do some other tests for us? Can you try other CIDs?
AT^NDISDUP=,1,""
You noted the response for AT^NDISDUP=? included (1-20); what's the
result of:
AT+CGDCONT=?
Thanks!
Dan
Transcript follows, showing how the NDISDUP command connects, disconnects and
updates PDP context #2.
On Mon, 2013-06-03 at 10:06 +0200, Aleksander Morgado wrote:
> On 02/06/13 16:32, Graham Inggs wrote:
> > The attached patch allows ModemManager to detect the Huawei E3276.
> > It also defaults to IPv4 if the bearer ip_type is not specified, does not
> > send encoded_auth if it is zero, and sends
On 03/06/2013 10:06, Aleksander Morgado wrote:
On 02/06/13 16:32, Graham Inggs wrote:
The attached patch allows ModemManager to detect the Huawei E3276.
It also defaults to IPv4 if the bearer ip_type is not specified, does not send
encoded_auth if it is zero, and sends the short form AT^NDISDUP
"Martin Anderseck" writes:
> Hi all,
>
> As promised I'm now coming back to you with the results of my
> research. Seems like the firmware bug was our problem. I compiled the
> latest stable kernel and now it works fine. Time for the next tests
> :-)
Great!
(I realize I should have added some c
Hi all,
As promised I'm now coming back to you with the results of my research. Seems
like the firmware bug was our problem. I compiled the latest stable kernel and
now it works fine. Time for the next tests :-)
Can anyone estimate how long it'll take until this patch arrives in standard
Ubunt
>>
>> NetworkManager currently allows to pass allowed/preferred modes (e.g. 2G
>> & 3G but 3G preferred) when requesting a connection to ModemManager. I'd
>> like to suggest to have these settings removed from the connection
>> profile (and therefore not passed to Simple.Connect()), and let system
On 02/06/13 16:32, Graham Inggs wrote:
> The attached patch allows ModemManager to detect the Huawei E3276.
> It also defaults to IPv4 if the bearer ip_type is not specified, does not
> send encoded_auth if it is zero, and sends the short form AT^NDISDUP=1,1 if
> the username and password are bot
On 02/06/13 17:31, W. Martin Borgert wrote:
>> As a workaround, set up a udev rule to:
>> > - set the group and mode on the device
>> > - create a non-changing symlink name to the changing device name
>> > - tell ModemManager not to touch the device
>> >
>> > Create a file, say /etc/udev/rules.d
On 02/06/13 01:06, Dan Williams wrote:
>>> Yeah, full debug output would be good then, since if MM sees that the
>>> > > device is not actually a modem, after probing it completely, it should
>>> > > never touch the device again unless the device goes away and re-appears.
>> >
>> > Here comes the
23 matches
Mail list logo
