Ismo Puustinen a écrit :
I started working on Ofono GPRS support.
Hello,
With GPRS support, Ofono become very interesting!
I failed to understand how the "isi_gprs" code in your patch communicate
with a PPP stack. For example, I currently use a project where the APN
is configured and a connec
Le mardi 1 septembre 2009 22:02:43 Jean-Christian de Rivaz, vous avez écrit :
> With GPRS support, Ofono become very interesting!
>
> I failed to understand how the "isi_gprs" code in your patch communicate
> with a PPP stack.
That would be because it does NOT use a PPP stack.
ISI modems have the
On Tue, Sep 01, 2009 at 14:02:43, Jean-Christian de Rivaz wrote:
> I failed to understand how the "isi_gprs" code in your patch
> communicate with a PPP stack. For example, I currently use a project
> where the APN is configured and a connection open with it. Then a pppd
> process is started to
Rémi Denis-Courmont a écrit :
Le mardi 1 septembre 2009 22:02:43 Jean-Christian de Rivaz, vous avez écrit :
With GPRS support, Ofono become very interesting!
I failed to understand how the "isi_gprs" code in your patch communicate
with a PPP stack.
That would be because it does NOT use a PPP
Le mardi 1 septembre 2009 23:17:36 Jean-Christian de Rivaz, vous avez écrit :
> Thanks for the explanation. I will start learning how phonet works. But
> I expect there exists a PPP stack somewhere in phonet because the modem
> I use don't have one.
ISI modems have a PPP "server-side" implementati
On Tue, Sep 01, 2009 at 15:17:36, Jean-Christian de Rivaz wrote:
> Thanks for the explanation. I will start learning how phonet works.
> But I expect there exists a PPP stack somewhere in phonet because the
> modem I use don't have one. And I don't think it's possible to have a
> IP link over GP
Everyone,
So as it happens I had also been brainstorming a GPRS API for the last several
days. And somewhat spontaneously a GPRS api discussion happened on IRC
between myself, Marcel and Ismo. The following GPRS API proposal is a result
of this discussion. I'd like all interested to comment.
Hi Denis,
> So as it happens I had also been brainstorming a GPRS API for the last
> several
> days. And somewhat spontaneously a GPRS api discussion happened on IRC
> between myself, Marcel and Ismo. The following GPRS API proposal is a result
> of this discussion. I'd like all interested
Hi Marcel,
> > Service org.ofono
> > Interface org.ofono.DataConnectionManager
>
> I think this should be GPRSManager or something to clearly separate
> between GRPS connections and actual data connection,
Two reasons for this:
- Purpose of DataConnectionManager is easier to
On Tue, 01 Sep 2009 15:42:40 -0700, Marcel Holtmann
wrote:
> Our current assumption is that the basic setup of IP address, netmask
> and broadcast are done by oFono. Only routing and DNS are up to other
> programs like ConnMan for example.
WHAAT? No way. There is just no way.
We need t
Hi Remi,
> > Our current assumption is that the basic setup of IP address, netmask
> > and broadcast are done by oFono. Only routing and DNS are up to other
> > programs like ConnMan for example.
>
> WHAAT? No way. There is just no way.
>
> We need to support letting the calling program
On Wed, 02 Sep 2009 02:16:40 -0700, Marcel Holtmann
wrote:
> Hi Remi,
>
>> > Our current assumption is that the basic setup of IP address, netmask
>> > and broadcast are done by oFono. Only routing and DNS are up to other
>> > programs like ConnMan for example.
>>
>> WHAAT? No way. The
2009/9/2 Rémi Denis-Courmont :
>> personally I don't care who finally sets the IP for the interface. It
>> really just makes no difference. What problem do you see if oFono would
>> set the IP address on that newly created interface that is up and
>> running now?
>
> Then the application cannot inf
Hi Aki,
> >> personally I don't care who finally sets the IP for the interface. It
> >> really just makes no difference. What problem do you see if oFono would
> >> set the IP address on that newly created interface that is up and
> >> running now?
> >
> > Then the application cannot influence the
On Wed, 02 Sep 2009 04:03:05 -0700, Marcel Holtmann
wrote:
>> And this generally applies to services that operators have decided to
>> run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC)
>> and others. For example, Elisa in Finland seems to be running their
>> MMSC behind an "m
On Wed, Sep 2, 2009 at 12:36 AM, Denis Kenzior wrote:
> of this discussion. I'd like all interested to comment. What needs
> improvement? What is missing? What should be removed?
Here are some comments. Some of the comments were already present in
the IRC discussion, but I'll repeat them here
Hi Ismo,
> > of this discussion. I'd like all interested to comment. What needs
> > improvement? What is missing? What should be removed?
>
> Here are some comments. Some of the comments were already present in
> the IRC discussion, but I'll repeat them here anyway. First of all,
> the both De
2009/9/2 Marcel Holtmann :
> Powered = on and RoamingAllowed = yes and Roaming = true will lead to
> auto-attach.
>
> Powered = on and RoamingAllowed = no and Roaming = true will lead to
> detach.
>
> Powered = on and Roaming = false will lead to auto-attach.
>
> Powered = off will lead to detach.
On Wed, 02 Sep 2009 05:02:46 -0700, Marcel Holtmann
wrote:
> I mentioned that already. We do wanna store something like Type that
> says internet, mms, wap etc. The only comment here was that for network
> initiated context we have no idea of its intent.
And we do not want to.
>> The attachment
Hi Aki,
> > Powered = on and RoamingAllowed = yes and Roaming = true will lead to
> > auto-attach.
> >
> > Powered = on and RoamingAllowed = no and Roaming = true will lead to
> > detach.
> >
> > Powered = on and Roaming = false will lead to auto-attach.
> >
> > Powered = off will lead to detach.
On Wed, 02 Sep 2009 05:46:31 -0700, Marcel Holtmann
wrote:
>> You will find that practically every Nokia phone behaves this way,
>> i.e., you make a call in 2G, and the UI will inform you that GPRS is
>> suspended while on call.
>
> So what is the difference signaling a disconnect and re-connect
Hi Remi,
> > I mentioned that already. We do wanna store something like Type that
> > says internet, mms, wap etc. The only comment here was that for network
> > initiated context we have no idea of its intent.
>
> And we do not want to.
>
> >> The attachment to the GPRS network in this proposal
Hi Ismo,
> This is a philosophical difference from the provisioning point of
> view. An operator will likely support multiple configured access
> points, and the provisioning program should know their purpose from
> the configuration file (internet/MMS/WAP/...). This metadata is not
> there in the
Hi Denis,
2009/9/2 Denis Kenzior :
> So the general rule is that if a feature isn't explicitly allowed in 27.007,
> we do not support it. There are exceptions to this of course. 27.007 only
> supports two states for context: activated and deactivated.
Ahem. Just like access selection mode is no
Hi Aki,
> > We are not going to expose Attach() or Detach() method. As explained
> > there are global anyway and so pointless to expose. This can be handled
> > in the background without bothering the higher level application with
> > these details.
>
> AFAIK, attach status of GPRS has both regula
Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit :
> Actually this one is missing from the API proposal. Marcel already wanted
> the context type (internet, mms, wap, etc) information. I've updated the
> proposed API in git.
This is not going to work.
Depending on the operat
2009/9/2 Denis Kenzior :
>> AFAIK, attach status of GPRS has both regulatory aspects to consider
>> (some operators require always attached vs. some prohibit it) as well
>> as power consumption issues (auto-attach might draw more power than
>> on-demand, although there's an inverse effect on latenc
Hi Aki,
> Hi Denis,
>
> 2009/9/2 Denis Kenzior :
> > So the general rule is that if a feature isn't explicitly allowed in
> > 27.007, we do not support it. There are exceptions to this of course.
> > 27.007 only supports two states for context: activated and deactivated.
>
> Ahem. Just like acce
Hi Remi,
> Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit :
> > Actually this one is missing from the API proposal. Marcel already
> > wanted the context type (internet, mms, wap, etc) information. I've
> > updated the proposed API in git.
>
> This is not going to work.
>
>
> > > This really belong in the kernel. Only the kernel can reliably know
> > > when a network interface has been brought down and notify the
> > > interested applications with the statistics.
> >
> > You're missing the point.
> >
> > Yes, any body can extract the statistics for a running context
> > > I am still not seeing the point in what suspended will do for us and
> > > the UI. And that Maemo 5 exposed such a state in the UI is not an
> > > argument to keep doing it. I asked this before, what are we suppose to
> > > be doing when we get signaled suspended?
> >
> > User, as well as i
Hi Waldo,
> > I know why you want this, but I'm still against the counter being an
> > oFono driver API. There needs to be a proper kernel interface that
> > signals the application when an interface has gone away with the rx/tx
> > details. This way we handle this generically for all modems wit
> > > I know why you want this, but I'm still against the counter being an
> > > oFono driver API. There needs to be a proper kernel interface that
> > > signals the application when an interface has gone away with the rx/tx
> > > details. This way we handle this generically for all modems withou
Hi Aki,
> >> AFAIK, attach status of GPRS has both regulatory aspects to consider
> >> (some operators require always attached vs. some prohibit it) as well
> >> as power consumption issues (auto-attach might draw more power than
> >> on-demand, although there's an inverse effect on latency). Thes
Hi Waldo,
> > > > I am still not seeing the point in what suspended will do for us and
> > > > the UI. And that Maemo 5 exposed such a state in the UI is not an
> > > > argument to keep doing it. I asked this before, what are we suppose to
> > > > be doing when we get signaled suspended?
> > >
>
Hi Marcel,
> > >> The reason is simple, Nokia modems suspend GPRS when scanning (or
> > >> registering), simply because the operation will take roughly three
> > >> times as long with GPRS attached. You will find this feature in
> > >> current phones, too.
> > >
> > > Then ideally you should have t
Hi Remi,
> > Actually this one is missing from the API proposal. Marcel already wanted
> > the context type (internet, mms, wap, etc) information. I've updated the
> > proposed API in git.
>
> This is not going to work.
>
> Depending on the operator, you may have more than one "type" for a sin
Hi Waldo,
> > > > I know why you want this, but I'm still against the counter being an
> > > > oFono driver API. There needs to be a proper kernel interface that
> > > > signals the application when an interface has gone away with the rx/tx
> > > > details. This way we handle this generically fo
Hi Denis,
> > > >> The reason is simple, Nokia modems suspend GPRS when scanning (or
> > > >> registering), simply because the operation will take roughly three
> > > >> times as long with GPRS attached. You will find this feature in
> > > >> current phones, too.
> > > >
> > > > Then ideally you s
Le jeudi 3 septembre 2009 00:01:03 Marcel Holtmann, vous avez écrit :
> > It's probably difficult if the PC client is allowed to redefine GPRS
> > contexts, but otherwise oFono should at least be able to report the total
> > tx/rx for the context's it has defined. The BT DUN / USB bridge could
> >
Hi Remi,
> > > It's probably difficult if the PC client is allowed to redefine GPRS
> > > contexts, but otherwise oFono should at least be able to report the total
> > > tx/rx for the context's it has defined. The BT DUN / USB bridge could
> > > call into oFono and trigger a poll of all the stats
Hi Ismo,
> I started working on Ofono GPRS support.
>
> The patch set contains:
>
> 1) Documentation describing how an Ofono GPRS D-Bus API would look like.
> 2) Common Ofono GPRS support.
> 3) Ofono GPRS ISI driver.
> 4) Test script for trying out the GPRS functionality.
>
> Note that the GPRS
Hi Marcel,
> since we have the upstream GPRS support for MBM and HSO devices, it
> would be great to have this for Phonet, too. I tried to work on the
> patch, but without proper documentation it is impossible. So please
> adapt it to the current upstream and resend it.
Yes, the GPRS ISI support
Hi Ismo,
> > since we have the upstream GPRS support for MBM and HSO devices, it
> > would be great to have this for Phonet, too. I tried to work on the
> > patch, but without proper documentation it is impossible. So please
> > adapt it to the current upstream and resend it.
>
> Yes, the GPRS IS
On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann
wrote:
> since we have the upstream GPRS support for MBM and HSO devices, it
> would be great to have this for Phonet, too. I tried to work on the
> patch, but without proper documentation it is impossible. So please
> adapt it to the current up
Hi Remi,
> On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann
>
> wrote:
> > since we have the upstream GPRS support for MBM and HSO devices, it
> > would be great to have this for Phonet, too. I tried to work on the
> > patch, but without proper documentation it is impossible. So please
> > ada
- Message d'origine -
> > But there are some more fundamental issues. First, the ISI General Packet
> > Data Service does not provide any location informations (roaming/not
> > roaming, area code, cell ID). And I must say I don't understand why this is
> > part of the GPRS atom. This has no
Hi Rem,
> > That is because 3GPP in their infinite wisdom structured the spec this
> > way.
>
> Just because AT commands group both pieces of unrelated data does not mean
> it is a good idea. I fail to see why the DBus and driver API should do the
> same mistake as 3GPP 27.007.
I already told yo
- Message d'origine -
> I already told you I'm open to fixing it. However 27.007 is the only standard
> we have right now.
That's easy to fix. Remove those from the GPRS status.
> Different network probably not, but different base station? Again I'm not the
> expert here either. The AP
Hi Remi,
> - Message d'origine -
>
> > I already told you I'm open to fixing it. However 27.007 is the only
> > standard we have right now.
>
> That's easy to fix. Remove those from the GPRS status.
The core only reports these attributes, it doesn't actually use them for
anything. When
> The core only reports these attributes, it doesn't actually use them for
> anything. When attached you can simply send a status=registered, LAC, CellId
> and Tech set to -1. We can see about removing these a bit later.
I would do that, but there is no apparent way to return the attached state
Hi Remi,
> > The core only reports these attributes, it doesn't actually use them for
> > anything. When attached you can simply send a status=registered, LAC,
> > CellId and Tech set to -1. We can see about removing these a bit later.
>
> I would do that, but there is no apparent way to return
- Message d'origine -
> Again, I don't see a point of exposing this to the user. Worst case we can
> always add intelligence / heuristics to oFono to attempt re-attaching
> periodically. We have to solve this for all modems, since there are no such
> 'auto-attach' semantics in 27.007.
If
Hi Remi,
> - Message d'origine -
>
> > Again, I don't see a point of exposing this to the user. Worst case we
> > can always add intelligence / heuristics to oFono to attempt re-attaching
> > periodically. We have to solve this for all modems, since there are no
> > such 'auto-attach' se
Hi Remi
> > I have two suggestions here:
> > 1. Lets make it work first, we can then make it work better.
> > 2. Can you describe these optimizations and suggest how the API/behavior can
> > be changed to take advantage of them?
>
> We just need to know if the core or the upper-layer application
On Wed, 09 Dec 2009 13:38:18 +0100, Rémi Denis-Courmont
wrote:
> I haven't had time to look at the context stuff yet.
It's just worse. oFono is enforcing an integer ID on any primary context.
This is again an idiosyncrasy of AT commands. With ISI modems, the context
ID space is managed by the mo
Hi Remi,
> > I haven't had time to look at the context stuff yet.
>
> It's just worse. oFono is enforcing an integer ID on any primary context.
> This is again an idiosyncrasy of AT commands. With ISI modems, the context
> ID space is managed by the modem, so oFono does not get to choose.
>
> In
On Thu, 10 Dec 2009 15:27:26 +0100, Marcel Holtmann
wrote:
> there has to be a mapping on some level. At least one driver has to do
> some sort of mapping. If you have a better idea to handle it in the core
> daemon, please propose something.
Of course we have context ID. But we cannot manage th
Hi Remi,
> > there has to be a mapping on some level. At least one driver has to do
> > some sort of mapping. If you have a better idea to handle it in the core
> > daemon, please propose something.
>
> Of course we have context ID. But we cannot manage them ourselves - the
> modem does it.
I di
Hi Remi,
> On Thu, 10 Dec 2009 15:27:26 +0100, Marcel Holtmann
>
> wrote:
> > there has to be a mapping on some level. At least one driver has to do
> > some sort of mapping. If you have a better idea to handle it in the core
> > daemon, please propose something.
>
> Of course we have context ID.
Hello,
On Thu, 10 Dec 2009 15:45:21 +0100, Marcel Holtmann
wrote:
>> > there has to be a mapping on some level. At least one driver has to do
>> > some sort of mapping. If you have a better idea to handle it in the
>> > core daemon, please propose something.
>>
>> Of course we have context ID
Hi Remi,
> >> > there has to be a mapping on some level. At least one driver has to do
> >> > some sort of mapping. If you have a better idea to handle it in the
> >> > core daemon, please propose something.
> >>
> >> Of course we have context ID. But we cannot manage them ourselves - the
> >> mod
62 matches
Mail list logo
