Entries : Category [ Hacks ]
Computer and electronics tricks and fooling around
[Miscellaneous]  [Computers and Technology]  [Travel]  [Education]  [Hacks]  [Robotics]  [Science]  [Programming and Software]  [iPhone]  [Digital TV and Video]  [Intellectual Property & Copyright]  [Personal] 

15 December
2012

My router needs to use an MTU of 1460 with my Sympatico DSL modem

After a power failure, most pages from my server stopped being served to users from the outside word, even though the pages are accessible from within the local network. This took a lot of time to debug since outside monitoring didn't even notice the problem: small pages continued to be served up properly. Noticing that small pages worked and big pages didn't took me quite some time, but once I had that clue I could rules out things like most common firewall issues, broken routing tables, and brutish misconfiguration.

As it happened, the issue was a mismatch between the MTU size (Maximum Transmission Unit ) used for my router (a Cisco E4200), and the MTU size used by the Sympatico DSL modem I use (a 2701HG-G Gateway). The MTU determines the size of data packets transmitted by Ethernet -- that is, the lower protocols levels used to carry Internet traffic. While Internet traffic at the TCP/IP level can be served up in arbitrary packet sizes, at the lower ethernet level hardware devices that are directly connected to one another presupposed that data data is divided into packets of a maximum size and, as it happens, may silently reject packets that are too big. In my case this was hellish to find since I had assumed it was a power-induced hardware problem and inly after lots of debugging did I start to notice that some pages were getting though: small pages:OK, larger pages: nothing shows up. Oddly, all the logs seemed to say everything was working normally. The fact this could only be tested from outside the local network made it harder still to debug.

For ethernet networks, the default MTU is 1500; this is what Tomato uses by default. For PPPOE networks, the default MTU is 1492; that is what the Sympatico requires.

That can be tested by using the command "ping" to try different packet sizes, and see what works well:


ping -s 1432 www.yahoo.com

(Note that some sites do not respond to ping probes at all, and some like google do not respond with arbitrary-sized packets as this test wants.)
On WIndows, you need to go to "Start/ Programs/ Accessories/Command Prompt " to enter this command, and you probably should use the variation

"ping -f -l 1432 www.yahoo.com"

The ping packets include a 28 bytes ICMP header, so the MTU will be 28 bytes more than the biggest ping packet size that works.
To make things work well on my router, I had a maximum ping packet of 1432 which means my MTU should be set to 1432+28 suggesting an MTU of 1460 and no larger. Any bigger and requests for most pages from my server stall forever without ever getting a response.



MTU 1460 for sympatico
MTU 1460 for sympatico
(Click to expand)





I hope this page has enough keywords to help the next poor soul with this problem. Additional information can be found at this very nice FAQ at DSLReports.com

Some other pople have commented on the requirement of this unusual 1460 MTU required by Sympatico, mainly in a fairly bitter and cynical manner, and I can see why:

Dell + Vista + DSL = WTF (read down the comments).

By Gregory Dudek at | Read (1) or Leave a comment |    
06 April
2013

Here is a version of Flite for Asterisk version 11. It also supports an exception file so that it can better pronounce certain words that Flite normally stumbles on (like my surname).

Flite is a text-to-speech program that converts English text strings to audio flies, and it's based on the larger and slower Festival project.

Greg's Flite for Asterisk 11


By Gregory Dudek at | Read (1) or Leave a comment |    
26 June
2014

chmod solution included

When I tried to play audio on the Raspberrypi using mpg123, I could only do so as the superuser. Unless I was root, I got the following errors:

mpg123 -l 6 -g 200 18000.mp3
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.3.2-1 (2012/03/25). Written and copyrights by Joe Drew,
...
ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM default
Can't find a suitable libao driver. (Is device in use?)


Well, I used strace to find the problem. I was a lack on the correct access priveliges on the audio device (of course). I had suspected this, but it was hard to find. The solution is to gain root access then then type:

chmod o+rw /dev/snd/controlC0

one might also try the more drastic

chmod o+rw /dev/snd/*


By Gregory Dudek at | Read (2) or Leave a comment |    
08 April
2016

SIP firmware upgrade path that works with version 9 software

I recently purchased a used Cisco 7970 phone and wanted to
convert it to use the SIP protocol. I did a factory reset and soon
discovered that one cannot upgrade from the factory state
to a recent firmware build without first loading an intermediate firmware.
The problem is that the firmware in the phone validates any new firmware upload before installing it, and it does it using built-in authentication keys. Somewhere along the line Cisco changed the authentication keys used to validate the firmware, and old firmware will refuse to validate new firmware. In between, however, there were a few firmware versions that included the keys for both old and new. SIP firmware versions of those dual-key firmwares, however, are not readily available.

The problem is that while both old and new SIP firmwares can be downloaded for free, the intermediate "bridge" builds and not available from Cisco for free and require a paid Cisco account and I didn't want to get one just for this experiment.

I found a workaround by going through a pair of free SCCP firmwares (i.e. non-SIP software). The following sequence of re-flashes can probably be optimized, but it was faster for me to just go ahead this way.

Upgrading my phone directly to firmware version 8.5 (cmterm 8-5-2SR1) or any newer version led to an "AUTH FAIL" error. Here's what does work:

http://www.dudek.org/blog/blogpics/cisco_auth_fail.jpg
http://www.dudek.org/blog/blogpics/cisco_auth_fail.jpg
(Click to expand)



  • Upgrade to SIP70.8-2-1S
  • This is an old firmware that works on a factory-clean phone. This might not be needed and almost any old firmware is sufficient, but is where I started.

  • SCCP 8.5.2
  • Then upgrade to an old SCCP (AKA skinney) protocol firmware version 8.5.2, available for free from Cisco: SCCP70.8-5-2S (filename cmterm-7970_7971-sccp.8-5-2.zip)

  • SCCP 8.5.3
  • Then upgrade to a SCCP (skinny) protocol firmware 8.5.3
    This is also available free from Cisco. The actual zip package is cmterm-7970_7971-sccp.8-5-3.zip The important point is that this firmware includes the authentication keys for new builds! The corresponding SIP firmware cannot be download for free, incidentally.

  • SIP 9.4
  • Finally, you can upgrade to the free SIP firmware 9-4-2SR1

    Look for it at https://software.cisco.com/download/release.html?mdfid=278436620&softwareid=282074288&release=9.4(2)SR1

    Note that if you need to do all this via a TFTP server. For each
    phase unzip the corresponding firmware package, modify the XMLDefault.cnf.xml
    to indicate the loads file to use, and then reboot the phone.


    By Gregory Dudek at | Read (3) or Leave a comment |    
    30 April
    2016

    R cannot be resolved to a variable

    On OS X Snow Leopard (10.6.8) revision 23 and later of the Android development environment will not work properly. In particular, the most obvious symptom is that the resource file R will not get built leading to the infamous and non-specific error: R cannot be resolved to a variable

    The problem is that the programs in sdk/build-tools/23.0.3/
    such as aapt will throw a segmentation fault, but this is often hidden and hard to fix. You need the old versions!

    The simple solution is not to not upgrade beyond revision 22, but this has various disadvantages such as missing new API changes. It may also be hard to downgrade after the upgrade has already taken place.

    An alternative is to copy the build tools from SDK revision 22 to the directory for revision 23 (or later), for example:

    cp
    adt-bundle-mac-x86_64-20140702/sdk/build-tools/22.0.1/*
    adt-bundle-mac-x86_64-20140702/sdk/build-tools/23.0.3/


    By Gregory Dudek at | Leave a comment |    
    20 July
    2017

    I recently had to build a Linux image for an Intel Galileo for a project I was working on. This is based on Yocto and the board support package (BSP) from Intel which includes code for the Galileo board and the quark microprocessor. I had a few problems especially since I wanted to include my own modifications to the Linux kernel.

    I was using an Ubuntu 16,04 distribution that included gcc v5. Version 5 of gcc was too new for several modules in the BSP 1.24.0 image that is currently available. I had do install gcc version 4.8.5. There were also problems with locale support which required a patch. Here are the key fixes.


    1)
    Patch the locale/gen_wctype.c routine using patch code from Oregon State University
    The code is also at the bottom this post in case that page goes away.


    2)
    Install an old gcc (apt-get install gcc-4.8) and then use

    sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 100 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8

    to install it. Later, select the one you wait using
    update-alternatives --config gcc

    3) Add support for new modules by adding a layer, and editing conf/bblayers.conf to include the new payer in the build.

    4) Configure the kernel:
    You might think you could do
    bitbake linux-yocto-quark -c menuconfig
    but that does not work with the Intel IOT dev kit. Instead, you need to cd to the kernel directory, and do a make menuconfig. This can be done on the hist since all we are doing is creating a config file, not actually generating any code for the Galileo target. Then you need to make sure the config gets use by bitmake, which I managed to do use one or another brutal hack. I recommend:

    make oldconfig
    cp .config defaultconfig

    Then go do your bitbake.

    The bitbake cheat sheet and bitbake command list might also be useful.


    Patch:


    --- a/extra/locale/gen_wctype.c
    +++ b/extra/locale/gen_wctype.c
    @@ -227,11 +227,12 @@
    ++verbose;
    continue;
    }
    - if (!setlocale(LC_CTYPE, *argv)) {
    + /* setlocale might be just a stub */
    + /* if (!setlocale(LC_CTYPE, *argv)) {
    verbose_msg("setlocale(LC_CTYPE,%s) failed! Skipping this locale...\n", *argv);
    continue;
    }
    -
    + */
    if (!(totitle = wctrans("totitle"))) {
    verbose_msg("no totitle transformation.\n");
    }
    @@ -306,43 +307,43 @@
    #endif
    #if 0
    if (c --- a/extra/locale/gen_wctype.c
    +++ b/extra/locale/gen_wctype.c
    @@ -227,11 +227,12 @@
    ++verbose;
    continue;
    }
    - if (!setlocale(LC_CTYPE, *argv)) {
    + /* setlocale might be just a stub */
    + /* if (!setlocale(LC_CTYPE, *argv)) {
    verbose_msg("setlocale(LC_CTYPE,%s) failed! Skipping this locale...\n", *argv);
    continue;
    }
    -
    + */
    if (!(totitle = wctrans("totitle"))) {
    verbose_msg("no totitle transformation.\n");
    }
    @@ -306,43 +307,43 @@
    #endif
    #if 0
    if (c

    By Gregory Dudek at | Leave a comment |    
    Prev  1   2   3   4   5   6   [7]