Samat Says (Posts about Ubuntu)https://blog.samat.org/tag/ubuntu.atom2018-06-29T09:25:27ZSamat K JainNikolaEnabling HTTP/2 on Apache 2.4 on Debian or Ubuntuhttps://blog.samat.org/2015/11/26/Enabling-HTTP2-on-Apache-2.4-on-Debian-Ubuntu/2015-11-26T00:00:00Z2015-11-26T00:00:00ZSamat K Jain<div><p><a class="reference external" href="https://httpd.apache.org/docs/2.4/mod/mod_http2.html">Apache 2.4.17 ships with mod_http2</a>.
Available in Debian 9 (stretch) and <span class="strike">Ubuntu 16.04 (Xenial Xerus)</span> (see comments) Ubuntu 16.10 (Yakkety Yak),
it brings HTTP/2 support to one of the Internet's popular Web servers.
Assuming you've already configured a SSL/TLS Website, this quick tutorial will show you how to quickly enable HTTP/2.</p>
<p>Based on <a class="reference external" href="https://icing.github.io/mod_h2/">mod_h2</a>, the module is still very experimental.
It should be enabled manually, on a site-by-site basis, via the <a class="reference external" href="https://httpd.apache.org/docs/2.4/mod/core.html#protocols">Protocols directive</a>.
The module's defaults otherwise don't need to be changed.</p>
<p>First, enable the module:</p>
<pre class="code sh"><a name="rest_code_40dd213b29044b90a0274126674c0091-1"></a>sudo a2enmod http2
</pre><p>In the <VirtualHost> stanzas for your Website served over TLS in your Apache configuration, add the Protocols directive:</p>
<pre class="code apache"><a name="rest_code_144f128ccf994f22abc932a08616bfab-1"></a><span class="nt"><VirtualHost</span> <span class="s">*:443</span><span class="nt">></span>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-2"></a> <span class="nb">ServerName</span> example.com
<a name="rest_code_144f128ccf994f22abc932a08616bfab-3"></a>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-4"></a> <span class="nb">Protocols</span> h2 http/1.1
<a name="rest_code_144f128ccf994f22abc932a08616bfab-5"></a>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-6"></a> <span class="c"># Other configuration stuff here…</span>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-7"></a><span class="nt"></VirtualHost></span>
</pre><p>Restart Apache:</p>
<pre class="code sh"><a name="rest_code_c1307c7b66dc472d9ff614cfac9f5def-1"></a>sudo service apache2 restart
</pre><p>If you've curl 7.34.0 or later, you can test whether HTTP/2 is working by running:</p>
<pre class="code sh"><a name="rest_code_eceda1c831cd4a80b484e124d3e8850b-1"></a>curl -k -v --http2 https://example.com/
</pre><p>and look for mentions of "http2".</p>
<p>While you're fiddling with your Web server configuration, consider updating your SSL settings with <a class="reference external" href="https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.17">Mozilla's great SSL configuration generator</a>.</p></div>Following Firefox's New Development Channels with Ubuntuhttps://blog.samat.org/2011/05/31/Following-Firefoxs-New-Development-Channels-with-Ubuntu/2011-05-31T00:00:00Z2011-05-31T00:00:00ZSamat K Jain<div><figure class="right">[inline:Firefox-Beta-About-Screen.jpeg]</figure>
<p>Shortly after Firefox 4's release, Mozilla announced the <a href="https://developer.mozilla.org/devnews/index.php/2011/04/07/new-development-channels-and-repositories-for-rapid-releases/">move to a channel development model</a>, à la Chrome. On Windows and Mac, builds from these channels update themselves; what about on Linux, where both self-updating software and software outside management of the package manager (i.e. manually installed) is taboo?</p>
<p>If you use Debian, Mike Hommey and the Debian Mozilla Team's <a href="http://mozilla.debian.net/">mozilla.debian.net</a> provides packages for the Firefox Stable, Beta, Aurora, and Nightly channels. Be aware that these packages are still labeled <a href="http://en.wikipedia.org/wiki/Iceweasel">Iceweasel</a>, i.e. they lack the official Firefox branding. These packages work on Ubuntu should you want to use them.</p>
<p>What if you want something more Ubuntu-specific? <abbr title="Personal Package Archive">PPA</abbr>s following each of the channels exist, but they're not obvious to find.</p>
<p>Nightly builds of Firefox trunk, formerly known as "Minefield" builds, are available in the <a href="https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa">Ubuntu Mozilla Daily PPA</a>. Remember, Nightly builds receive little testing (e.g. can they build without errors?) and thus may crash frequently. Start using these builds by pasting the following into your terminal:</p>
<pre><samp>sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa
sudo apt-get update && sudo apt-get install firefox-trunk
</samp></pre>
<p>Firefox's new build channel, Aurora, has builds that have had more testing than those from Nightly. Builds from the Aurora channel are available from the <a href="https://launchpad.net/~ubuntu-mozilla-daily/+archive/firefox-aurora">firefox-aurora PPA</a>, which you can use with:</p>
<pre><samp>sudo add-apt-repository ppa:ubuntu-mozilla-daily/firefox-aurora
sudo apt-get update && sudo apt-get install firefox
</samp></pre>
<p>The Beta channel, containing builds that received more testing than Aurora and are (mostly) ready to be released, is available in the <a href="https://launchpad.net/~mozillateam/+archive/firefox-next">firefox-next PPA</a>:</p>
<pre><samp>sudo add-apt-repository ppa:mozillateam/firefox-next
sudo apt-get update && sudo apt-get install firefox
</samp></pre>
<p>Lastly, if you want to follow the Stable channel, consider sticking with what's available in Ubuntu's normal repositories. Ubuntu has a (new) <a href="https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel">policy</a> to bring stable Firefox updates to Ubuntu releases more quickly. If you really want to be testing the next Firefox release, try the Beta channel above. If you still want the "bleeding edge" of stable, there's the <a href="https://launchpad.net/~mozillateam/+archive/firefox-stable">firefox-stable PPA</a>, which will go away soon, and <a href="https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa">Ubuntu's Mozilla Security Team PPA</a>, within which packages only remain until they are moved into the main archive.</p>
<p>Notice that the Aurora, Beta, and Stable channels contain packages of the same name: "firefox"; this means:</p>
<ol>
<li>You can only install Firefox from one channel at a time.</li>
<li>They all will use the same profile and profile registry. You'll need to manually switch profiles or alter shortcuts to launch the desired profile if you desire different.</li>
</ol>
<p>Packages in the Nightly channel, however, are named firefox-trunk and can be co-installed alongside builds from another channel.</p>
<p>To switch to another channel, disable the source with <a href="https://help.ubuntu.com/community/Repositories/Ubuntu">Ubuntu's Software Properties</a> or delete the appropriate file in /etc/apt/sources.list.d/:</p>
<pre><samp>sudo rm /etc/apt/sources.list.d/ubuntu-mozilla-team-firefox-aurora\*list
sudo rm /etc/apt/sources.list.d/mozillateam\*list
</samp></pre>
<p>Then re-add the appropriate repository to switch to a desired channel.</p>
<p>Hopefully, with easy-to-use PPAs available for each of Firefox's build channels, more people, including you, will test these builds. Go forth and test!</p></div>Increase file descriptors for Transmission on Linuxhttps://blog.samat.org/2011/04/05/Increase-file-descriptors-for-Transmission-on-Linux/2011-04-05T00:00:00Z2011-04-05T00:00:00ZSamat K Jain<div><p>Have you run out of file descriptors for <a href="http://www.transmissionbt.com/">Transmission</a>? The torrent will be stopped (for no apparent reason), and when you examine it, you'll see an error similar to:</p>
<pre><samp><span class="prompt">$</span> <kbd>transmission-remote -t 1 -i | grep -i 'open files'</kbd>
Unable to save resume file. Too many open files.
</samp></pre>
<p>Time to increase the number of file descriptors available. This article is tailored towards Debian and Ubuntu.</p>
<p>It's unlikely you'll need to raise your system's global limit. Check with:</p>
<pre><samp><span class="prompt">$</span> <kbd>cat /proc/sys/fs/file-max</kbd>
397460
</samp></pre>
<p>The OS needs a couple thousand file descriptors for itself. Make sure to make space for them with whatever numbers to choose below. In my case, I've more than enough.</p>
<p>If you still need to raise your system's limit, you can easily; to set it to a million (which will be remembered across reboots):</p>
<pre><samp><kbd>sudo sh -c "echo fs.file-max=$(dc -e '2 20 ^ p') > /etc/sysctl.d/file-descriptors-max.conf</kbd>
<kbd>sudo service procps restart</kbd>
</samp></pre>
<p>While you may not need to change your system's global limit, you probably will need to change the limit for your users. Check that limit with:</p>
<pre><samp><span class="prompt">$</span> <kbd>ulimit -Sn</kbd>
1024
<span class="prompt">$</span> <kbd>ulimit -Hn</kbd>
1024
</samp></pre>
<p>If you're working with hundreds of torrents (each with dozens to hundreds of files) with Transmission, this isn't enough. To let a user have a few thousand (in the below example, 16,384, with 128 more for the hard limit), create a new file /etc/security/limits.d/debian-transmission.conf:</p>
<pre><samp><kbd>sudo sh -c "echo debian-transmission soft nofile $(dc -e '2 14 ^ p')" > /etc/security/limits.d/debian-transmission.conf</kbd>
<kbd>sudo sh -c "echo debian-transmission hard nofile $(dc -e '2 14 ^ 2 7 ^ + p')" >> /etc/security/limits.d/debian-transmission.conf</kbd>
</samp></pre>
<p>Replace "debian-transmission" with the user that is running Transmission.</p>
<p>For the changes to go into effect, you need to logout completely (e.g. close multiplexed SSH connections, etc), and log back in again. Or to be sure, just reboot to make sure changes kick in. You'll see you have many more file descriptors available:</p>
<pre><samp><span class="prompt">$</span> <kbd>ulimit -Sn</kbd>
16384
<span class="prompt">$</span> <kbd>ulimit -Hn</kbd>
16512
</samp></pre>
<p>Now, we need to configure Transmission to use this many. In /etc/transmission-daemon/settings.json, find the open-file-limit option and set to a larger number (e.g. 16000 or so). When done, restart transmission-daemon:</p>
<pre><samp><kbd>sudo service transmission-daemon restart</kbd>
</samp></pre>
<p>If you're not running Transmission as a system user, edit the right settings.json and restart the daemon appropriately.</p>
<p>That's it. Have fun!</p></div>High-resolution text console with uvesafb and Debianhttps://blog.samat.org/2010/11/09/High-resolution-text-console-with-uvesafb-and-Debian/2010-11-09T00:00:00Z2010-11-09T00:00:00ZSamat K Jain<div><p>While you may rarely use the console on your server, it's nice to have a high-resolution display just to see that many more columns and rows. Linux's vesa module (via the vga= parameter) has been around for a while and made this possible, provided you kept up with what VGA mode number to use and don't mind the spotty hardware compatibility.</p>
<p>While <abbr title="Kernel Mode Setting">KMS</abbr> is the way to do this in the future, it doesn't help us with the drivers and hardware we have now. A new kernel module, <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/uvesafb.txt;h=eefdd91d298a9c9ea45e1ab9d84cdbf8ea1f1908;hb=HEAD">uvesafb</a>, mainlined in 2.6.24, is another, new option. In addition to specifying modes in a more user-friendly way (e.g. 1280x1024-32 for 32-bit color, with a 1280x1024 resolution), hardware compatibility is better—in particular, you can now get a high-resolution text console with NVIDIA display adapters.</p>
<p>In the following, I describe how to use uvesafb on Debian and derivative distributions (e.g. Ubuntu). The instructions assume kernel 2.6.27 or higher (Debian 6.0 (squeeze) and Ubuntu 8.10 (Intrepid Ibex), or later).</p>
<p><a href="https://blog.samat.org/2010/11/09/High-resolution-text-console-with-uvesafb-and-Debian/">Read more…</a> (2 min remaining to read)</p></div>Speeding up SpamAssassin rule processing on Debian and Ubuntuhttps://blog.samat.org/2008/10/02/speeding-up-spamassassin-rule-processing-on-debian-and-ubuntu/2008-10-02T00:00:00Z2008-10-02T00:00:00ZSamat K Jain<div><p><a href="http://spamassassin.apache.org/">SpamAssassin</a> is one of the most-used spam filtering systems in use today. Unfortunately, because there are so many different ways SpamAssassin can be used, SpamAssassin remains subject to many performance problems. Fortunately, there are several speed-ups and optimizations that can be applied to most SpamAssassin installations to speed up its rule processing, especially on Debian and Ubuntu GNU/Linux-based systems. These instructions can be adopted to other operating systems as well.</p>
<p>This article does not discuss configuring your mail filtering system (i.e. procmail, maildrop). This depends completely on your setup, and more than likely there are plenty of other articles that describe the best way to setup what you want.
<!--break--></p>
<h3>The spamc/spamd client/server combination</h3>
<p>A normal SpamAssassin setup invokes the <code>spamassassin</code> command for each incoming e-mail that needs to be scanned. This process is expensive when you consider what this does: for each incoming e-mail, a perl interpreter starts and loads all of SpamAssassin's perl code, including its thousands of rules. Starting SpamAssassin like this, with a decent amount of incoming e-mail, will increase I/O load and slows things down, fast.</p>
<p>SpamAssassin 2.x introduced the <a href="http://spamassassin.apache.org/full/3.0.x/dist/doc/spamc.html">spamc</a>/<a href="http://spamassassin.apache.org/full/3.0.x/dist/doc/spamd.html">spamd</a> combination to alleviate this issue. <code>spamd</code> is a version of SpamAssassin intended to be run as long-running process that accepts connections from <code>spamc</code>. <code>spamc</code> is a lightweight C program made to replace the <code>spamassassin</code> command, taking a message and passing it to <code>spamd</code> for processing. This alleviates all of the I/O caused by loading perl and all of SpamAssassin's rules repeatedly. Instead, both perl and SpamAssassin's rule sets are only loaded once.</p>
<p>Setting this up and relatively quick and easy. Install:</p>
<pre><kbd>sudo aptitude install spamc
</kbd></pre>
<p>Then, edit /etc/default/spamassassin to enable startup of the spamd process. In this file, change:</p>
<pre><samp>ENABLED=1
</samp></pre>
<p>Start the spamd process:</p>
<pre><kbd>sudo /etc/init.d/spamassassin start
</kbd></pre>
<p>Next, in your mail filtering scripts wherever you invoke the <code>spamassassin</code> command, invoke the <code>spamc</code> command instead. After verifying spam filtering still works after all these changes, you are done.</p>
<p>One important thing to note: the spamd/spamc combination sets up another service running on your system, possibly opening up a security hole waiting to be exploited. Make sure to follow due process (securing user accounts, setting up firewall, etc) before enabling new network services.</p>
<h3>Precompiled Rules</h3>
<p>Erich Schubert went into <a href="http://blog.drinsama.de/erich/en/linux/2007122403-spamassassin-precompiled-rules.html">SpamAssassin 3.2's ability to precompile rules</a> a few months ago. While Perl's regular expressions are fast, C regular expressions can be faster (and consume less memory). SpamAssassin can compile its rules into a C shared library that is used instead of interpreted perl code. Eric mentions a negative to precompilation: it requires your mail server to have a C compiler.</p>
<p>If you're comfortable with that, setting up your system for precompiling SpamAssassin's rules is easy. Install the required depencencies:</p>
<pre><kbd>sudo aptitude install re2c build-essential
</kbd></pre>
<p>and run the <a href="http://spamassassin.apache.org/full/3.2.x/doc/sa-compile.html">sa-compile</a> command:</p>
<pre><kbd>sudo sa-compile
</kbd></pre>
<p>You then need to configure SpamAssassin to use the precompiled rules. This is done by editing /etc/spamassassin/v320.pre, and uncommenting out the line:</p>
<pre><samp>loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody
</samp></pre></div>Yes, GNOME is limiting!https://blog.samat.org/2007/02/18/yes-gnome-is-limiting/2007-02-18T00:00:00Z2007-02-18T00:00:00ZSamat K Jain<div><p>There's been a lot of fallout from <a href="http://applications.linux.com/article.pl?sid=07/02/16/1937237">Linus' latest criticism of the GNOME desktop</a>, with which I complete agree. I feel as if I need to comment on some of the responses.</p>
<p><a href="http://ubuntu.wordpress.com/">Carthik Sharma</a> writes in <a href="http://ubuntu.wordpress.com/2007/02/17/of-apples-and-oranges-gnome-and-kde/">Of Apples and Oranges, GNOME and KDE</a>:</p>
<blockquote>
<p>I dread having to find something, since it most definitely will be placed in some non-intuitive sub-menu.</p>
</blockquote>
<p>KDE has no control over where applications decide to place themselves.</p>
<blockquote>
<p>I like the way GNOME display fonts on the screen. I don’t want to have to change every little variable to get the perfect system.</p>
</blockquote>
<p>GNOME pioneered use of fontconfig; in fact, lately, GNOME has been pioneering the use of many next-gen APIs and technologies (e.g. AIGLX, Beryl, etc). But Qt/KDE have also been using fontconfig for several years now—what's different?</p>
<p>Interesting enough, there has been criticism about <a href="http://primates.ximian.com/~federico/news-2007-01.html#font-sizes">how GNOME handles fonts</a>. Taking points from that article, GNOME's font configuration is a mess:</p>
<ul>
<li>What's a “Terminal” font (it should be called “Monospace,” as it is in KDE, because this is how it's also used throughout GNOME)?</li>
<li>What does “size” mean (apparently, it's not what you think)?</li>
<li>Why do I care about the subpixel ordering of my fonts' antialiasing?</li>
<li>Why would I need to set fonts at all (see my weblog entry <a href="https://blog.samat.org/weblog/20070218-the-gnome-font-dialog-why.html">The GNOME font dialog, why?</a>)?</li>
</ul>
<p>KDE is no different than GNOME in trying to provide “sensible” defaults, defaults that its developers have decided are intrinsic to a “perfect desktop.” But, what the developers have decided is the perfect desktop may not be your perfect desktop—and here lies the essence of Linus' argument, and the difference with KDE and GNOME. With KDE, you may have an option to make a setup “perfect”; with GNOME, quite often the option won't exist and you are limited to what the powers that be decided was perfect for them, not you. This is Linus' argument: <b>GNOME is limiting</b>.</p></div>High-speed cellular wireless modems (e.g. EVDO, HSPDA) in Ubuntu GNU/Linux 6.10https://blog.samat.org/2007/01/27/high-speed-cellular-wireless-modems-in-ubuntu-linux-6-10/2007-01-27T00:00:00Z2007-01-27T00:00:00ZSamat K Jain<div><div style="float: right;">[inline:novatel-s720.gif]</div>
<p><em><strong>Note:</strong> If you are running Ubuntu 7.04 or greater, this article is no longer relevant. Your EVDO modem should be detected and run at a higher speed automatically.</em></p>
<p>I've been raving about cellular wireless modems/data cards for a while now. While they've been available for a long while, they've finally become practical with networks such as <abbr title="Evolution-Data Optimized">EVDO</abbr> and <abbr title="High-Speed Downlink Packet Access">HSPDA</abbr> that offer broadband-like speeds. I personally own a <a href="http://www.novatelwireless.com/products/merlin/merlin-pc720.html">Novatel Merlin S720</a> that I use with <a href="http://powervision.sprint.com/mobilebroadband/">Sprint's Mobile Broadband service</a>.</p>
<p>Most of these datacards are easy to get running in Linux--I actually setup mine in Linux faster than I did in Microsoft Windows. However, due to some shortcomings in the kernel used by Ubuntu GNU/Linux 6.10, you cannot take advantage of the speeds that these modern wireless networks offer.</p>
<p>This article talks about some of the problems of the often-used usbserial driver, and how to use the better-performing airprime driver instead.
<!--break--></p>
<h3>Using the usbserial vs airprime drivers</h3>
<p>Many instructions on the Internet that detail how to use these modems in Linux talk about using the usbserial driver, often having to pass custom vendor and device IDs to the driver so that it recognizes the device. While this does work, the usbserial driver was not made to handle high-speed devices like EVDO and HSPDA modems. It has some small I/O buffers, and with these small buffers you will not be able to get transfer speeds greater than 60 KB/sec. There are patches available to increase usbserial's buffer size, but with the airprime driver, this is not needed.</p>
<p>The Linux airprime driver can operate these modems at full-speed, after support for larger buffers was added in 2.6.18. Unfortunately, the driver has to be patched to recognize any kind of new device.</p>
<p>This doesn't help me using since I am Linux 2.6.17 on Ubuntu 6.10, and I've also no desire to deviate far from the distribution-provided kernel. 2.6.17's airprime driver does not have the support for large buffers, nor does it contain the driver IDs so that the driver takes control of the device.</p>
<p>I took <a href="http://lkml.org/lkml/2006/6/30/7">Andy Gay's airprime improvement patches</a> and backported them ("backport" is a misnomer since it was so easy), also adding the device IDs from 2.6.20 and a few other popular wireless modem devices (Note: I've not personally tested anything but the Novatel Merlin S720).</p>
<p>You can get the <a href="https://blog.samat.org/sites/blog.samat.org/files/airprime-sjain-012807.patch.txt">patch against Ubuntu's 2.6.17 kernel</a>, or simply download the <a href="https://blog.samat.org/sites/blog.samat.org/files/airprime-sjain-012807.c.txt">entire patched airprime.c file</a>. The patch contains device IDs for:</p>
<ul>
<li>AirPrime 5220</li>
<li>Sierra Wireless Aircard 580</li>
<li>Sierra Wireless EM5625</li>
<li>Sierra Wireless MC5720</li>
<li><a href="http://www.novatelwireless.com/products/merlin/merlin-v620.html">Novatel Wireless S620</a></li>
<li><a href="http://www.novatelwireless.com/products/merlin/merlin-pc720.html">Novatel Wireless S720</a></li>
<li><a href="http://www.novatelwireless.com/products/ovation/mcd3000.html">Novatel Wireless U720</a></li>
<li><a href="http://www.novatelwireless.com/products/expresscard/merlin-xu870.html">Novatel Merlin XU870</a></li>
<li>ExpressCard34 Qualcomm 3G CDMA</li>
<li>Dell Wireless 5500</li>
<li>Kyocera Wireless KPC650/Passport</li>
<li>Audiovox PC5740</li>
<li>Pantech PX-500</li>
</ul>
<h3>Kernel and driver setup</h3>
<p>Install the minimum build environment, Linux sources, and Linux headers for your currently-running kernel:
<code>
apt-get install build-essential linux-headers linux-source
</code></p>
<p>Go into /usr/src/ and uncompress the kernel source code:
<code>
cd /usr/src
tar xjvf linux-source-2.6.17.tar.bz2
</code></p>
<p>Enter the directory containing the airprime driver:</p>
<p><code>
cd linux-source-2.6.17/drivers/usb/serial
</code></p>
<p>Now, either apply the patch, or replace airprime.c with the pre-patched version (see above for download links).</p>
<p>If patching:</p>
<p><code>
patch -p0 < airprime-sjain-012807.patch
</code></p>
<p>If replacing (not recommended, patching is safer):</p>
<p><code>
mv airprime.c airprime.c.bak
mv airprime-sjain-012807.c airprime.c
</code>
Normally, to patch a driver, you have to recompile the entire kernel tree and replace all the kernel modules as well as the core kernel image itself. But since we are using Ubuntu's sources, we can only compile the driver's that we need and overwrite the old ones.</p>
<p>To compile only the airprime dirver (this actually compiles all drivers in the directory):
<code>
make -C /lib/modules/<code>uname -r</code>/build M=<code>pwd</code>
</code></p>
<p>Then, install it (you need root privileges to overwrite the existing driver) and update module dependencies:
<code>
sudo cp airprime.ko /lib/modules/<code>uname -r</code>/kernel/drivers/usb/serial/airprime.ko
sudo depmod -a
</code></p>
<p>You can either remove and reinsert the driver, or take the easy way out and reboot. Your device should now be recognized by the airprime driver, and a new device node /dev/ttyUSB0 created.</p>
<h3>Some ending notes...</h3>
<p>The above installs files outside the knowledge of Ubuntu's package manager. If your kernel ever gets upgraded, dpkg will happily overwrite your custom driver, and you will have to go through the above procedure again. To prevent this happening at an inopportune time, set your kernel's package status to "hold" to prevent automatic upgrades.</p>
<p>If you're using Sprint's Mobile Broadband service as I am, you may want to look the sister article I've written, <a href="https://blog.samat.org/2007/01/28/sprints-evdo-mobile-broadband-on-ubuntu-linux">Sprint's Mobile Broadband on Ubuntu GNU/Linux 6.10</a>.</p></div>Sprint's EVDO Mobile Broadband on Ubuntu GNU/Linuxhttps://blog.samat.org/2007/01/27/sprints-evdo-mobile-broadband-on-ubuntu-linux/2007-01-27T00:00:00Z2007-01-27T00:00:00ZSamat K Jain<div><div style="float: right; padding-left: 1ex;">[inline:sprint-mobile-broadband-card.jpg]</div>
<p>So, you've gotten your shiny new EVDO datacard working under Linux (if not, see <a href="https://blog.samat.org/2007/01/27/high-speed-cellular-wireless-modems-in-ubuntu-linux-6-10">High-speed cellular wireless modems (e.g. EVDO, HSPDA) in Ubuntu GNU/Linux 6.10</a>) and you want to now setup the actual Internet connection?</p>
<p>In this article I document how I setup <a href="http://powervision.sprint.com/mobilebroadband/">Sprint's Mobile Broadband service</a> with ppp in Ubuntu GNU/Linux 6.10.
<!--break--></p>
<h3>Setting up ppp</h3>
<p>There are some great GUI tools for setting up <abbr title="Point to Point Protocol">PPP </abbr> on Linux, but I don't care to use them. I <em>like</em> editing text files and working on the <abbr title="Command Line Interface">CLI</abbr>.</p>
<p>To get things working, we only need to create several different files (as superuser). The first, <b>/etc/ppp/peers/sprint</b>:</p>
<pre>/dev/ttyUSB0 # modem
921600 # faster than this has no effect, and actually can be detrimental
defaultroute # use cellular network for default route
usepeerdns # use the DNS servers from the remote network
\#nodetach # keep pppd in the foreground
\#debug
crtscts # hardware flow control
lock # lock the serial port
noauth # don't expect the modem to authenticate itself
local # don't use Carrier Detect or Data Terminal Ready
persist # Redial if connection lost
user
ppp
holdoff 5 # Reconnect after 5s on connection loss
lcp-echo-failure 4 # prevent timeouts
lcp-echo-interval 65535 # prevent timeouts
connect "/usr/sbin/chat -v -f /etc/chatscripts/sprint-connect"
disconnect "/usr/sbin/chat -v -f /etc/chatscripts/sprint-disconnect"
</pre>
<p>Notice that you do not need your Sprint PCS username or password. The modem authenticates itself to Sprint in hardware via its <acronym title="electronic serial number">ESN</acronym>. Next is <b>/etc/chatscripts/sprint-connect</b>:</p>
<pre>TIMEOUT 10
ABORT 'BUSY'
ABORT 'NO ANSWER'
ABORT 'ERROR'
SAY 'Starting Sprint...\n'
\# Get the modem's attention and reset it.
"" 'ATZ'
\# E0=No echo, V1=English result codes
OK 'ATE0V1'
\# List signal quality
'OK' 'AT+CSQ'
'OK' 'ATDT#777'
CONNECT
</pre>
<p>and your connection will work</p>
<p>And then the optional <b>/etc/chatscripts/sprint-disconnect</b>:</p>
<pre>"" "\K"
"" "+++ATH0"
SAY "Disconnected from Sprint."
</pre>
<p>You can also setup this connecton in <b>/etc/network/interfaces</b>, adding the stanza (assuming you want to use ppp0):</p>
<pre>iface ppp0 inet ppp
provider sprint
</pre>
<p>And that's basically it! If you setup your interfaces file, you can simply run:</p>
<pre><kbd>sudo ifup ppp0</kbd></pre>
<p>to bring up the connection. Remember to ifdown the interface to disconnect. If not using interfaces, you can use the pon/poff pair of commands:</p>
<pre><kbd>sudo pon sprint # Start connection
sudo poff sprint # Stop connection</kbd>
</pre>
<h3>Problem: default route does not get set</h3>
<p>For some reason, my default route is not set properly. If not set properly, you look as if you've been connected to Sprint, but you will not actually be able to connect to any site on the Internet. To check if this is happening to you, look at the last line of "route -n" and see if it reads the nonsense:
</p><pre>0.0.0.0 0.0.0.0 0.0.0.0 UG 0 0 0 ppp0
</pre>
<p>To fix this, I created script into /etc/ppp/ip-up.d/zzz-fix-route:</p>
<pre><code>\#!/bin/sh
/sbin/route del default gw 0.0.0.0 # Remove nonsense route
/sbin/route add default gw $PPP_REMOTE # Add correct route
</code></pre>
<p>Remember to make the file executable. The "zzz-" prefix insures that it is the last script run, just to prevent a script after it from misconfiguring the route again,</p></div>