[arch-releng] Support mobile broadband with wvdial
I refer to this: http://mailman.archlinux.org/pipermail/arch-general/2010-June/014388.html Other (desktop) distributions can skip wvdial on their installers because they have (1) a desktop environment by default and as such (2) some sort of GUI network management front-end that can handle most types of connections, including mobile broadband [1]. However, we are leaving out those users. I had posted another link to configuring such connections with ppp some months ago [2], but the fact of the matter is that it's all pretty cumbersome. On the other hand, wvdial is a well-known method for this and is easy to configure, aside from gathering ISP details like APN and putting that in a file (etc/wvdial.conf). Right now only the following people can install Arch Linux without having to go through a number of hoops: * with cable broadband * with DSL broadband * with wireless broadband I believe we'd be pretty much 'complete' if we added: * with mobile broadband At least, in the 'broadband' category. This effectively implies 2 packages from [extra]: wvdial wvstreams (dependency) Since a package needn't be in [core] to be included in the image, I say we should do this :) [1] http://en.wikipedia.org/wiki/Mobile_broadband [2] http://mailman.archlinux.org/pipermail/arch-general/2010-October/016727.html
On Tue, Dec 7, 2010 at 11:53 PM, Ray Rashif <schiv@archlinux.org> wrote:
I refer to this: http://mailman.archlinux.org/pipermail/arch-general/2010-June/014388.html
Other (desktop) distributions can skip wvdial on their installers because they have (1) a desktop environment by default and as such (2) some sort of GUI network management front-end that can handle most types of connections, including mobile broadband [1]. However, we are leaving out those users.
is there a way to offer "support packs" so to speak? for instance, we could have the base image, then a series of optional images that would provide more options for those that need it. rather than always adding to [core], the packs would be in a repo called, say, [install]. note: this question not because of or in spite of your need in particular; just trying to see if there is a generic way we can handle the more exotic requirements of installation (a one time thing*), vs. the requirements once the system is running. installation is expected to handle everything from everybody, yet only some fraction is needed for any single install. something like: # dd if=base.img of=/dev/usb # dd if=dial.img of=/dev/usb seek=<XYZ> is that possible (probably not that simple tho im guessing :-)? i would also expect that many people are able to using cheap 1-8GB flash drive nowadays anyway, maybe we should consider some options for those that don't burn discs (when will we ever drop CDs? i never liked them from day 1)... seriously, i just got a 8GB for $12 the other day... maybe we should do a survey or something. C Anthony
Am 08.12.2010 06:53, schrieb Ray Rashif:
I refer to this: http://mailman.archlinux.org/pipermail/arch-general/2010-June/014388.html
Other (desktop) distributions can skip wvdial on their installers because they have (1) a desktop environment by default and as such (2) some sort of GUI network management front-end that can handle most types of connections, including mobile broadband [1]. However, we are leaving out those users.
I had posted another link to configuring such connections with ppp some months ago [2], but the fact of the matter is that it's all pretty cumbersome. On the other hand, wvdial is a well-known method for this and is easy to configure, aside from gathering ISP details like APN and putting that in a file (etc/wvdial.conf).
Right now only the following people can install Arch Linux without having to go through a number of hoops:
* with cable broadband * with DSL broadband
Only with a router that gives your DHCP. If you need to connect yourself using PPPoE (most of Europe) or PPTP (IIRC common in Austria), you still need to do work.
* with wireless broadband
By creating a netcfg profile manually - there is no dialog-GUI in AIF to do that.
I believe we'd be pretty much 'complete' if we added:
* with mobile broadband
At least, in the 'broadband' category.
This effectively implies 2 packages from [extra]:
wvdial wvstreams (dependency)
I want to say this: 1) We do not need wvdial. This works easily with pppd and chat alone - wvdial is just another abstraction layer that doesn't simplify anything (you still have to configure everything that you need to configure in pppd and chat), so I don't see the need for wvdial at all. 2) Implement pppd/chat-based mobile broadband as a netcfg connection. 3) Implement pppoe and pptp as netcfg connections. 4) Implement support for creating netcfg profiles in AIF. IMO, this is the way to go. It isn't difficult, it just needs some time and someone to do it (it's on my imaginary TODO list which is growing and growing - meaning I won't do it any time soon).
On Wed 08 Dec 2010 11:46 +0100, Thomas Bächler wrote:
1) We do not need wvdial. This works easily with pppd and chat alone - wvdial is just another abstraction layer that doesn't simplify anything (you still have to configure everything that you need to configure in pppd and chat), so I don't see the need for wvdial at all.
2) Implement pppd/chat-based mobile broadband as a netcfg connection.
3) Implement pppoe and pptp as netcfg connections.
4) Implement support for creating netcfg profiles in AIF.
IMO, this is the way to go. It isn't difficult, it just needs some time and someone to do it (it's on my imaginary TODO list which is growing and growing - meaning I won't do it any time soon).
I agree, but couldn't wvdial be used until someone implements it properly with netcfg?
Am 08.12.2010 13:08, schrieb Loui Chang:
I agree, but couldn't wvdial be used until someone implements it properly with netcfg?
As I said, wvdial does not simplify the process in any way, compared to pppd and chat. In both cases you need to create equally obscure configuration files with non-intuitive options. I found wvdial to be even more confusing than pppd.
On 8 December 2010 18:46, Thomas Bächler <thomas@archlinux.org> wrote:
I want to say this:
1) We do not need wvdial. This works easily with pppd and chat alone - wvdial is just another abstraction layer that doesn't simplify anything (you still have to configure everything that you need to configure in pppd and chat), so I don't see the need for wvdial at all.
2) Implement pppd/chat-based mobile broadband as a netcfg connection.
3) Implement pppoe and pptp as netcfg connections.
4) Implement support for creating netcfg profiles in AIF.
IMO, this is the way to go. It isn't difficult, it just needs some time and someone to do it (it's on my imaginary TODO list which is growing and growing - meaning I won't do it any time soon).
That's fine too, I was just concerned that we need something that actually works in a straightforward manner. This (netcfg method) would be even better, actually. It's just that I've never tried to dial up with anything other than wvdial, and I haven't come across much documentation that uses ppp for gsm. For eg. I have 2 configuration files that I copied off the net; 1 for 3G modems which I didn't have to edit and the other for cellphones, which needed only the APN changed. I just issue a 'wvdial' to get connected with my Huawei E220 or ROKR E8. I wouldn't know how one would do the equivalent with pppd alone. I've tried adapting /etc/ppp/options by looking at each line in /etc/wvdial.conf, to no avail. Thomas, could you provide an example? I'd like to include that in the wiki and improve existing articles like [1], effectively solving this without the need to have any new software/packages introduced. [1] https://wiki.archlinux.org/index.php/Dialup_without_a_dialer_HOWTO
Am 08.12.2010 16:57, schrieb Ray Rashif:
IMO, this is the way to go. It isn't difficult, it just needs some time and someone to do it (it's on my imaginary TODO list which is growing and growing - meaning I won't do it any time soon).
That's fine too, I was just concerned that we need something that actually works in a straightforward manner. This (netcfg method) would be even better, actually. It's just that I've never tried to dial up with anything other than wvdial, and I haven't come across much documentation that uses ppp for gsm.
For eg. I have 2 configuration files that I copied off the net; 1 for 3G modems which I didn't have to edit and the other for cellphones, which needed only the APN changed. I just issue a 'wvdial' to get connected with my Huawei E220 or ROKR E8.
I wouldn't know how one would do the equivalent with pppd alone. I've tried adapting /etc/ppp/options by looking at each line in /etc/wvdial.conf, to no avail. Thomas, could you provide an example?
This is a chat file (would be generated on-the-fly by netcfg): ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED ABORT ERROR '' ATX OK 'ATZ' TIMEOUT 5 OK 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0' OK AT+CGDCONT=1,"IP","internet" OK ATH OK ATE1 OK 'ATM0L0DT *99***1#' CONNECT This is more complicated than it needs to be actually, some stuff might be omitted. "internet" is the APN here, and *99***1# is the "phone number", which is different in some cases (I think *99#). The rest never has to be changed. Now, this can be launched using: /usr/sbin/pppd /dev/ttyUSB2 persist nodetach nobsdcomp nodeflate connect "/usr/sbin/chat -s -S -v -f /path/to/chat/file/foo.chat" 460800 modem crtscts defaultroute user " " password " " noaccomp nopcomp novj novjccomp noccp noauth ipcp-accept-remote ipcp-accept-local noipdefault usepeerdns Now, most of these options are to override insane default from /etc/ppp/options (which sadly are always applied, and 'auth' is default, so you need to have 'noauth'). The only thing one would have to change here is the tty, the username and password (usually ignored on 3G) and maybe replace persist with demand. What I meant earlier: When I first tried to use wvdial, I thought I wouldn't have to write the chat file - however, the wvdial.conf just contained the same shit as my chat file, just in a less readable format. The pppd-line is actually very long, but most of the stuff is never changed. This information alone is enough to write a netcfg 3g connection, but I do not have a 3G stick anymore. I could test this with my mobile phone, which works exactly the same way (I just need to use /dev/rfcomm0 as a tty instead).
On 9 December 2010 01:48, Thomas Bächler <thomas@archlinux.org> wrote:
This is a chat file (would be generated on-the-fly by netcfg):
ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED ABORT ERROR '' ATX OK 'ATZ' TIMEOUT 5 OK 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0' OK AT+CGDCONT=1,"IP","internet" OK ATH OK ATE1 OK 'ATM0L0DT *99***1#' CONNECT
This is more complicated than it needs to be actually, some stuff might be omitted. "internet" is the APN here, and *99***1# is the "phone number", which is different in some cases (I think *99#). The rest never has to be changed.
Now, this can be launched using:
/usr/sbin/pppd /dev/ttyUSB2 persist nodetach nobsdcomp nodeflate connect "/usr/sbin/chat -s -S -v -f /path/to/chat/file/foo.chat" 460800 modem crtscts defaultroute user " " password " " noaccomp nopcomp novj novjccomp noccp noauth ipcp-accept-remote ipcp-accept-local noipdefault usepeerdns
Thanks so much, I think I get it now. I'll be trying this out, and hopefully can organise a little bit of documentation for the beginners' guide.
On Wed 08 Dec 2010 13:24 +0100, Thomas Bächler wrote:
Am 08.12.2010 13:08, schrieb Loui Chang:
I agree, but couldn't wvdial be used until someone implements it properly with netcfg?
As I said, wvdial does not simplify the process in any way, compared to pppd and chat. In both cases you need to create equally obscure configuration files with non-intuitive options. I found wvdial to be even more confusing than pppd.
When I used dialup years ago I honestly tried to connect the pure ppp route, but I couldn't figure it out. wvdial actually worked simply without an complicated configuration. As wvdial is implemented by a Canadian group and I was connecting to a Canadian ISP, that might explain why it worked without a hitch for me. If it does only work well for a select few, then I agree that it shouldn't be included in the install.
participants (4)
-
C Anthony Risinger
-
Loui Chang
-
Ray Rashif
-
Thomas Bächler