Friday, January 2, 2015

Frustrating Experience with BSNL 3G Data SIM - and a workaround

I took a BSNL SIM while travelling expecting that their services were more likely to be available in most states. Unfortunately, I did not test it well in Chandigarh before leaving.

I was using a Huawei 3G E8231 dongle and it just did not connect. I tried on cell phone as well but the data connection did not happen whether 2G or 3G.

I needed BSNL connection in Rajasthan where Tata Docomo did not have their own data service. Once I reached Pune, I did not need the BSNL connection but it worked using the APN bsnllive!

However, my relief was not long. It did not connect in Goa either, except for some reason for 1 day, when it worked very well for the whole day and using the APN bsnlnet as expected.

Since then again no connection. It is frustrating to contact BSNL support on their call centre, especially while roaming.

I sent emails to the addresses mentioned on BSNL site. The messages did not bounce; however, I got no feedback at all. Curiously, the email addresses were on gmail.com :)

I got a call yesterday (may be because I had visited the BSNL office in Mapusa who said that they will contact Chandigarh for help). I was told that I should try now as the problem is resolved.

However, no change in status and I cannot call back the person who had called :(

Finally, I got a person on 1503 of the Maharashtra circle who gave me the help number for Punjab. The person from the Punjab circle wasn't helpful at all and probably disconnected in the middle. I tried once again and it got disconnected again. No point in making any more effort.

I am bewildered by why did it work on two days and not on other days. Since it worked twice, it does not seem like a compatibility problem with my devices. Oh, well, fortunately, there are many more options now, which work AND who really do try to help!

I will dump the sim. A lesson learnt for a thousand rupees - a mere US$ 15 :)

Update 7th Feb 2015:

There had to be a reason why the BSNL connection worked twice. I kept thinking about the sequence of operations which might have been the reason.

I think I now know.

The default APN for bsnl is 'bsnlnet'. It did not work.
I changed the profile to 'bsnllive'.
Waited for a while.
State is now connected. Some data is sent but nothing is received.
I changed the profile back to 'bsnlnet'.
State remains connected and the 3G data connection works :)

The above steps have worked on two days now.
Why? That remains a mystery!





Monday, November 10, 2014

OpenStack Nova Compute Cannot Launch Instance after Upgrade to Fedora 21

I updated my system to Fedora 21 beta and then found that I could not use OpenStack. Every effort to launch an instance failed:
libvirtError: operation failed: filter 'nova-no-nd-reflection' already exists with uuid 728f13cf-f1a9-4e0e-add7-357b93d052ee
Removing the openstack packages, clearing the data and reinstalling openstack did not help.

The problem seems to be an incompatibility  between nova-compute and the libvirt libraries.

Upgrading the libvirt libraries to rawhide did not help.

Finally, I used rpm to downgrade libvirt using downloaded packages from the fedora 20 repository, ignoring the dependency problems.
$ sudo rpm -U --oldpackage --nodeps libvirt*1.1.3*rpm
All seems well for now.



Monday, November 3, 2014

Openstack Nova Compute fails to start after updating to 2014.1.3-2.fc21

OpenStack nova compute service failed to start after the update to th e openstack-icehouse version 2014.1.3-2.fc21  - the reason appeared to be:

"Failed to add interface: can't add lo to bridge br100: Invalid argument"

This bug report, though marked as invalid, helped, The problem was a change in the file nova/network/linux_net.py.

The following exception had been in the wrong place earlier and was being ignored:
if (err and err != "device %s is already a member of a bridge; "
              "can't enslave it to bridge %s.\n" % (interface, bridge)):
       msg = _('Failed to add interface: %s') % err
       raise exception.NovaException(msg)

The interface for the flat network is set to 'lo' even if the nova.conf file does not define it. network['bridge_interface'] seems to be set to 'lo' in the following line:

iface = CONF.flat_interface or network['bridge_interface']

One workaround was to change the following line in ensure_bridge method:
<         if interface:
---
>         if interface and interface != 'lo':

Subsequently, I came across another workaround in a bug report by creating a dummy interface.

The virtual machines were stuck in 'powering on' state after the update. This time solving it was easy!

Tuesday, September 23, 2014

Experimenting with open source big data applications on a personal desktop

I decided to learn OpenStack, Hadoop, Elasticsearch and related open source software products using my quad core desktop. I had to raise the RAM to 16GB and add a 1 terabyte disk.

However, after the hardware upgrade, it has been remarkably simple to experiment and learn these tools using Fedora 20 repositories.

I am writing about my experiences in a monthly column in Open Source for You and will continue to post them on my site after a month or more of the publication.

I hope learning new tools is as effective as learning new languages to keep senility away after retirement :)

Saturday, August 23, 2014

Csound and x86_64 machines

I could not understand why Sugar TamTam activities wouldn't play any sound on x86_64 even though the problem seemed resolved! It took a while to realize that the problem was with x86_64 architecture. I could get the sound to play on an i686 virtual machine.

Thanks to realtime Csound programming using Python, I could trace the fault. The issue is illustrated by the following code in csoundSession.py:

        if csnd.csoundGetSizeOfMYFLT() == 8:
            pfields = csnd.doubleArray(n)
        else:
            pfields = csnd.floatArray(n)
The csound client code in Python and C used by tamtam activities assumes a float array.

The following line in csound.spec from rpm source makes the issue pretty clear:

# Csound is really dumb about 64-bit
Rebuilding csound on x86_64 with "%define useDouble 0" even for x86_64 resolved the problem with TamTam activities.

However, it is entirely possible that this workaround may cause some other applications which use csound to fail on x86_64.

Wednesday, August 13, 2014

OpenStack - Virtual Machine stuck in task state 'powering-on'

Today for the second time I had to search for the solution in http://dachary.org/?p=2939. Last time, I seemed to have selected the right keywords but it took much more effort today.

I just needed to reset task_state in instances table of the nova database:
mysql -e "update instances set task_state = NULL \
           where deleted = 0 and hostname = 'master'" nova
The problem may be caused by error in nova compute starting up as I use virtual machine manager as well.

Virtual machine manager creates images in /var/lib/libvirt/images which are readable by root only.

For some reason, nova-compute looks in this directory as well and gets errors like:
Stderr: "qemu-img: Could not open '/var/lib/libvirt/images/fedora20.qcow2': Permission denied\n"
I manually change the permissions to readable by all to overcome the problem.

Sunday, June 15, 2014

Running TamTam Activities on Fedora 20

While preparing an old machine to give to the children of our helper, I had to struggle a bit to get TamTam activities to run. I was using the Sugar environment on Fedora 20. The version of TamTam activities in the Fedora repository was old and did not work.

The solutions were as follows:
  • The tamtamorc.cfd file in tamtam/common/Resources/ needs an additional comma in line 62:

    $ diff tamtamorc.csd tamtamorc.csd.orig
    62c62
    < aindex, atrans, ifreq, iphase, itable, itabdur xin
    ---
    > aindex, atrans, ifreq, iphase itable, itabdur xin
  • On the x86_64 systems, in common/Util/Clooper, I needed to run make to make sure that aclient.so is built for the installed version of csound.