Modem Dialler (not GSM/3G!) With DBus Interface

fishlike interliners · 02-12-2011, 02:30 PM

Hi.

I am a developer working on an application which needs to dial out via modem.

The modem activation/deactivation is done programmatically by the application, which may be running unattended. The online time is billed by the minute at a very high rate so it is imperative that the dialler does its best to terminate a connection whenever signalled to do so by the application.

The preferred means of communication with the dialler would be via DBus, due to design/architectural considerations.

The current solution relies on a DBus wrapper around pppd, but it has been found lacking in reliability (leaving connections open from time to time).

I have already reviewed some candidates such as wvdial, and network-manager but unfortunately those were unsuitable.

Any alternatives you could suggest would be much appreciated.

xeleema · 02-12-2011, 05:53 PM

Greetingz!

Okay, let me make sure we have the facts....
a) You're trying to build-in to your application support for controlling a Plain-Old-Telephone-System (POTS) modem.
b) This isn't a GSM/CDMA/3G/4G/ATM modem.
c) You want to use D-Bus to control a GUI-based dialer.
d) You already have a wrapper for pppd, but it's unreliable.

Now for the questions;
Have you made sure pppd was configured properly? I assume you have defined "active-filter"?

Code:

       active-filter filter-expression
              Specifies a packet filter to be applied to data packets to determine which packets are to be  regarded  as
              link  activity,  and therefore reset the idle timer, or cause the link to be brought up in demand-dialling
              mode.  This option is useful in conjunction with the idle option  if  there  are  packets  being  sent  or
              received  regularly over the link (for example, routing information packets) which would otherwise prevent
              the link from ever appearing to be idle.  The filter-expression syntax is  as  described  for  tcpdump(1),
              except  that  qualifiers which are inappropriate for a PPP link, such as ether and arp, are not permitted.
              Generally the filter expression should be enclosed in single-quotes to prevent whitespace in  the  expres-
              sion  from  being  interpreted  by  the  shell.  This  option is currently only available under Linux, and
              requires that the kernel was configured to include PPP filtering support (CONFIG_PPP_FILTER).   Note  that
              it  is possible to apply different constraints to incoming and outgoing packets using the inbound and out-
              bound qualifiers.

Have you double-checked the pppd daemon's "idle" settings?

Code:

       idle n Specifies that pppd should disconnect if the link is idle for n seconds.  The link is idle  when  no  data
              packets  (i.e.  IP packets) are being sent or received.  Note: it is not advisable to use this option with
              the persist option without the demand option.  If the active-filter option is given,  data  packets  which
              are rejected by the specified activity filter also count as the link being idle.

Exactly what's been the problem with pppd, wvdial, and network-manager (and why are the latter two undesireable?)
Have you tried dip?

fishlike interliners · 02-14-2011, 12:46 PM

Hi xeleema.

Thank you for your answer.

Quote:

Originally Posted by xeleema

Greetingz!

Okay, let me make sure we have the facts....
a) You're trying to build-in to your application support for controlling a Plain-Old-Telephone-System (POTS) modem.

Yup.

Quote:

b) This isn't a GSM/CDMA/3G/4G/ATM modem.

Nope.

Quote:

c) You want to use D-Bus to control

...the dialling, yes. But...

Quote:

a GUI-based dialer.

No, it is not a GUI-based dialler. It is a background process 'B' that at regular intervals needs to fetch updated information, and it does so by asking another background process 'C', to establish a PPP connection. Background process 'B' can be interrogated by a GUI process 'D', which can also ask it to do a refresh (therefore causing 'B' to tell 'C' to dial). In summary:

'B': Background process which holds/processes some data which requires regular or irregular updates over PPP.
'C': Background process which establishes or tears down a PPP connection and tells 'B' (or whoever is interested) that a connection is up / down.
'D': GUI process which interrogates 'B'. It does not talk directly do 'C', but can cause 'B' to tell 'C' to do some action.

Quote:

d) You already have a wrapper for pppd, but it's unreliable.

Correct. That's the process called 'C' above.

Now for the questions;

Quote:

Have you made sure pppd was configured properly?

Yup. Activating and deactivating pppd manually via the command line works exactly as required.

Quote:

I assume you have defined "active-filter"?

I do not have access to the code right now, so I can't give you a categorical answer on this specific point, but a priori pppd is configured to never terminate the connection unless requested.

That said, using active-filter with a very restrictive filter could very well be the answer to both the connect and disconnect use cases, obviating the need for process 'C' above, so I will research into that. Thanks a lot for bringing this to my attention!

Quote:

Have you double-checked the pppd daemon's "idle" settings?

Yup, see above.

Quote:

Exactly what's been the problem with pppd,

I believe pppd itself is behaving like a champ, the problem is with process 'C' not killing pppd when it's supposed to, and/or not bringing it up when needed. The root problem here is that 'C' has been put together from a bunch of reused bits of code which have themselves been recycled over and over, and it's all a horrible mess. So I've got two options: rewrite 'C' from scratch, or use an off-the-shelf solution if one is available. Requirements for such a solution are as per my first post, i.e.,:

* establish PPP connection (using predefined settings)
* tear down PPP connection
* expose a DBus method to command the two actions above.
* expose a DBus signal to let anyone interested know when the link is available / no longer available.

Quote:

wvdial, and network-manager (and why are the latter two undesireable?)

wvdial does not provide a DBus interface. NetworkManager does not seem to support POTS dial-up (the platform is Debian 6)

Quote:

Have you tried dip?

It's been looked at, I believe, but it fails the DBus requirement.

Once again, thanks for your help, especially the excellent lead on using demand dialling mode. I'll get back to let you know how that worked after it's been tested (it could take up to a couple of months due to other commitments, so please bear with me!).

xeleema · 02-14-2011, 04:41 PM

Cool! Glad I could help.

Post back to this thread if you need anything, if I don't respond after a day or two, hit my profile and leave me a message.