[network-admin] and modem-applet don't work for setting up dial-up

I should definitely mention that this is all using cdc_acm module for ISDN USB
modem which provides /dev/ttyACM0. When I added a link /dev/modem ->
/dev/ttyACM0 (and then let it "auto-detect" modem, even though I have manually
put the right device before), I've got it moving (it tried to start pppd
according to /var/log/messages).

Perhaps I'll investigate more a bit later.

I'm working with gnome-system-tools upstream on this issue. I'm very interessted
if the latest gnome-applets (2.9.5ubuntu3) upload helped you?

I'll update my system tonight (when I go to sleep), so I'll report back tommorow.

Nothing changed for me with dist-upgrade. I've also found out that above "got
it moving" was actually the process of auto-detection: /var/log/messages showed
pppd starting while checking /dev/modem.

gnome-system-tools 1.1.90-0ubuntu3
gnome-applets 2.9.5-0ubuntu3
gnome-applets-data 2.9.5-0ubuntu3

Ok, I've identified a few problems.

First of all, pppd command is passed a "connect" using *backticks* instead of
the regular quotes for calling chat program. This is basically the following
line in network.pl:

  $command .= " connect `$command_chat -f $chat_file`";

The other problem I'm having is that the connect script is insisting on matching
on "ogin:" and "password:" prompts, whereas I use PAP authentication (and most
ISPs use PAP or CHAP these days). If I get some time, I'll write a patch for
g-s-t, but I first need to clean up my hard-drive so I can put my Gnome CVS
check-out on it.

It would also be nice to have ports other than /dev/modem, /dev/ttyS[0-3]
auto-detected (perhaps doing a "dmesg |egrep tty[A-Za-z]+[0-9]+" would work out
for GNU/Linux systems?).

I've noticed that the Network Connection Applet does not show any connection status...wireless, wired,
etc. (only lo) I am not using a modem. Is this only for a modem connection? I'm just a newbie to
Linux, but noticed that this applet does not appear to function properly.

It works for me for any active connections. But please report this as a separate
bug, because it's totally unrelated to this problem.

Hi Danilo!

Fixing the quotes and PAP/CHAP stuff will fix this for you? I'd love to get this
fixed for 1.2, I don't have any modem connection myself, but all I could need is
people testing this for me

   Thanks

Carlos, actually, there're a few more things I need to set for it to work for
me. I can manually change it in network.pl or profiles.xml, but that's obviously
not the best solution.

I don't see any GUI option to choose whether remote peer needs to authenticate
(when connecting to ISP, it most usually doesn't, since I'm the one who is
authenticating, so I should use "noauth" instead of "auth"). I also add "user
ssegan" to pppd command line, and remove "ogin:"/"assword:" detection from the
chatscript (as above). Of course, you'd need to append '"username" *
"password"' line to /etc/ppp/pap-secrets and /etc/ppp/chap-secrets, for it to
work (I have it already in there, put by pppconfig).

The final problem is handling of volume settings: my ISDN modem doesn't accept
AT&FH0M0 command, and what follows it in the chatscript is "OK-AT-OK-ATDT...",
which fails for me, because ATM0 fails (it gives out "ERROR" instead of "OK",
and ABORT ERROR is set).

All these changes finally made it possible for me to connect via network-admin
"Activate" button on "Modem connection". "Deactivate" doesn't work yet (you
ought to shut down "pppd" which was started, instead of only "ifconfig down
ppp0"), and neither does the modem applet from gnome-applets (I get "ppp0" not
found from chat program in the syslog).

On Debian and Ubuntu, I'd prefer if configuration was done a bit differently.
I.e. there would be one chatscript per connection, and for connecting you'd call
"pppd call ppp0", "pppd call ppp1", etc.

Though, I should definitely open up a bug on bugzilla.gnome.org for all of this
(I first thought it was only Ubuntu integration problem).

(In reply to comment #9)

<snip>

> I don't see any GUI option to choose whether remote peer needs to authenticate
> (when connecting to ISP, it most usually doesn't, since I'm the one who is
> authenticating, so I should use "noauth" instead of "auth"). I also add "user
> ssegan" to pppd command line, and remove "ogin:"/"assword:" detection from the
> chatscript (as above). Of course, you'd need to append '"username" *
> "password"' line to /etc/ppp/pap-secrets and /etc/ppp/chap-secrets, for it to
> work (I have it already in there, put by pppconfig).

right, I tried to avoid writing to the config files when doing an operation that
was supposed to do this cleanly, but it's clearly the best solution to do this
securely

>
> The final problem is handling of volume settings: my ISDN modem doesn't accept
> AT&FH0M0 command, and what follows it in the chatscript is "OK-AT-OK-ATDT...",
> which fails for me, because ATM0 fails (it gives out "ERROR" instead of "OK",
> and ABORT ERROR is set).

that's weird, M0, L1, L2 and L3 are standard hayes commands for setting the
modem volume, can't this be set in yours?

>
> All these changes finally made it possible for me to connect via network-admin
> "Activate" button on "Modem connection". "Deactivate" doesn't work yet (you
> ought to shut down "pppd" which was started, instead of only "ifconfig down
> ppp0"), and neither does the modem applet from gnome-applets (I get "ppp0" not
> found from chat program in the syslog).
>
> On Debian and Ubuntu, I'd prefer if configuration was done a bit differently.
> I.e. there would be one chatscript per connection, and for connecting you'd call
> "pppd call ppp0", "pppd call ppp1", etc.

ups, sorry, but in fact I tried to move a bit away from this, before 1.1.x, one
could create any interface, even if it didn't exist, and amongst other many
problems, it left the doubt of knowing which PPP interface was activated (it
doesn't matter that you call the chatscript ppp1, the interface will be called
ppp0), and it also gave problems with some distros which only supported one PPP
config at a time

So I'd encourage to use network profiles/locations for getting this :)

>
> Though, I should definitely open up a bug on bugzilla.gnome.org for all of this
> (I first thought it was only Ubuntu integration problem).

yeah, sounds like a good idea :)

A little question, you said that you have an ISDN modem, aren't you using the
capi plugin for connecting?

BTW, I'm attaching a patch that implements all the suggestions but the ATM0 one

    Thanks!

Created an attachment (id=1350)
first try

My modem is an ISDN modem, but connected via USB, so it uses cdc_acm kernel
module to get /dev/ttyACM0, which I use to connect. Most USB modems (including
those that are not ISDN) can use the same driver (cdc_acm), so this should
probably be supported.

As for volume control, I know those are standard AT commands, but they're still
not supported. ISDN connects in 1 second, so there's no sense in talking about
volume (it's a digital line, not analog, so there might not even be
MOdulation/DEModulation, but I don't know exactly :). Yeah, it's still a shame
it doesn't just ignore it, instead of outputting "ERROR". But, I can't change
the hardware, so this is a requirement for me.

I'll continue the discussion in UPSTREAM bug
http://bugzilla.gnome.org/show_bug.cgi?id=167342, so I'm closing this as
UPSTREAM (I hope that's a correct thing to do, Ubuntu folks?).

(In reply to comment #9)
> Carlos, actually, there're a few more things I need to set for it to work for
> me. I can manually change it in network.pl or profiles.xml, but that's obviously
> not the best solution.

 Something more: Hayes may be a standard but especially some old modems are very
slow and have weird dependings on commands. EG on my old Best 9600EC the command
AT&FH0E1 is processed like following: &F resets factory settings and aborts
further processing. So H0 and E1 are dropped. Reseting takes around two seconds,
all communications in this timeframe is discarted so sending ATD1234 does no
good at all. My personal two cents:

ALWAYS insert a short chatscript-delay before an AT-Commands with \d. Or at
least offer one fast and one secure chatscript.

Split Commands to several lines. Especially with atz and at&f and at&w and some
other lowlevel-stuff.

Also old modems have rather low speeds on their V.24/RS232-interfaces. My Best
again chokes beyond 38400bps. I haven't found any solution to change the speed
in network-admin.

In an ideal world network-admin would offer one additional config-page for
fiddling around the chatscript/modem-commands/RS232-speed yourself, it took me a
odyssey to find out who actually does the chatting and now I'll try my luck with
a hand-made network.pl.

FWIW, I was getting an ERROR response from my cell phone (used as a USB modem)
following the "AT&FH0M0" commands. Playing around with a bit, it seems the
problem command is AT&F. And the problem seem to be timing related. As in: if I
type "AT&F", the "modem" always responds "OK". But if I paste in "AT&F", then
the modem sometimes responds with error. So I think adding a '\d' or '\p'
between & and F in the chat script might fix the problem.

So, with all of the discussion around this bug... can we call it confirmed?

marking as confirmed according to the number of comments about the issue

This bug hasn't seen any activity in 3 years.
Given that now in Karmic we have Network Manager instead of network-admin, can you confirm that this bug doesn't apply anymore and close it?
If it's still present, does it still apply to the same package?

As far as I know, network manager support never made it far enough to be usable as a generic dial-up tool. However, it's been a while since I had modem internet connections (and especially ISDN connections), that I think we can make this bug 'Invalid' (meaning "obsolete") or 'Incomplete' — I will not be able to provide further debugging information. I'd say it wouldn't be right to call this 'fix released', but that's just me.

OK, thanks for your tolerance. ;-) Indeed, things must have changed so much since Hoary that the debugging should be started from scratch, or given up. Closing, anyway nobody will work on it as-is. But feel free to open new reports about problems in the gnome-system-tools or network-manager (which should work better with modems in every new release).