четверг, 11 августа 2016 г.

GSM modem woes

I've had a task to send SMS messages over a bunch of GSM USB modems.

Gnokii proved to work well with Nokia phones only, so I have written a custom perl script to send AT commands directly.

It took some time to program encoding the SMS in packet mode, but the main difficulty was unreliability of the modems and/or USB subsystem of linux.

Sometimes /dev/ttyUSBx devices stopped responding. Unplugging the modems by hand seemed unworthy thing to do, so I searched the internet for solutions.

At first I have found usbreset.c and fortunately it could recover the /dev/ttyUSBx devices, but it required /dev/bus/usb/... path to work on, so I searched again and found a method of mapping ttyUSB to /dev/bus/usb here.

Then I have added the following function to my perl script and called it during modem initialization if the modem did not reply to the first AT command.

sub usbreset($) {
        my ($device)=@_;
        use File::Slurp;
        require 'sys/ioctl.ph';
        my ($rdev)=(stat($device))[6];
        return if !$rdev;
        my ($major,$minor)=($rdev>>8,$rdev&255);
        my $path="/sys/dev/char/$major:$minor/../../../..";
        my $bus=read_file("$path/busnum");
        my $dev=read_file("$path/devnum");
        my $ctl=sprintf('/dev/bus/usb/%03d/%03d',$bus,$dev);
        open my $fd,'>',$ctl || return;
        # USBDEVFS_RESET from linux/usbdevice_fs.h
        my $res=ioctl($fd,_IO(ord('U'),20),0);
        return if !defined $res;
        return 1;

I'll have to monitor the modems for some time to find out if there are other problems with them.

Feel free to use this piece of code if you like (public domain).

пятница, 18 марта 2016 г.

VLAN calculation algorithm design

I've had a task to automate calculation and setting up VLANs on switches of our regional network.

The task was naturally split into two phases:
  1. calculate VLAN numbers on the switches and trunks;
  2. synchronize switch configurations to the calculated result.
The first one was not quite obvious, a new algorithm needed to be designed. The second was done by another programmer.

I have designed and implemented the algorithm. Key points:
  • We have list of devices, trunks, client port VLANs on each device as input data. VLAN sets for each trunk is the output. The network has multiple loops for redundancy.
  • VLAN should be included on a trunk if it is two-way on the trunk, this means that we can spread VLANs from their endpoints on the graph and then calculate VLANs on trunks as intersection of sets of one direction and the other.
  • We spread VLAN set from each device as a bit vector. Each trunk has two associated  VLAN sets, one for each direction.
  • If we use STP protocol, then VLANs should be unified across each group of connected cycles (which have a common trunk).
  • If we use ERPS, then the VLANs should be unified starting from most outer half-loop to the base loop.
  • We can prune VLAN propagation if the trunk already contains all VLANs from the propagation set (an exception was necessary for multiply connected non-switch devices), thus runtime is reduced significantly.
I used perl and Bit::Vector module. The first version did not prune VLAN propagation and it took 1-2 minutes to complete on our network topology (more than 1600 devices), and after implementing the pruning it takes just 4 seconds (including database queries).

The following article was invaluable for understanding multi-ring ERPS topologies:
D. Lee, K. Lee, S. Yoo and J. K. K. Rhee, "Efficient Ethernet Ring Mesh Network Design," in Journal of Lightwave Technology, vol. 29, no. 18, pp. 2677-2683, Sept.15, 2011.

вторник, 15 марта 2016 г.

Reflections on the ancient ruins

When travelling in Greece I have visited Delphi and Athens. Watching the ruins in Delphi I wondered why all the buildings were destroyed and how.

And suddenly I have noticed a bronze peg in one of the stones. What is that?
Other stones had pits in them, but no pegs. Probably the stones of columns were connected with bronze pegs. They could be poured in via a small opening with molten bronze.

I have noticed only a few such pegs, but many pits. Also I have noticed that many of the pegs have holes from a wooden core. Bronze was not cheap at that time, armour and weapons were made of it. And the wooden inserts could be used to save bronze and reduce costs.

Next I thought: if the bronze was costly, it was logical for looters to try and get it.

So probably it was looters who finished the column destruction to get the bronze pegs. (Disclaimer: I'm not an archaeologist)

пятница, 26 февраля 2016 г.

upgrade-routeros script

I have finished "upgrade-routeros" perl script for safe and client-friendly graceful upgrade of RouterOS on ASBR and BRAS MikroTik routers.

It solves some problems automatically, which required manual work before.
  • BGP route updates don't propagate instantly. If we just upgrade the software by rebooting an ASBR, the traffic would be blackholed or looped for several minutes. To solve this problem, we need to disable BGP peers and wait for route propagation. Then we may safely reboot the router as the traffic is not directed to it any more. The new script waits for 5 mintes to let the network converge.
  • PPPoE sessions should be terminated gracefully. Otherwise cheap CPEs may hang or stop reconnecting automatically. To solve it, the script disables PPPoE servers before rebooting and waits for PPPoE sessions graceful termination before rebooting the BRAS.
  • PPPoE sessions should last for at least 2 hours to avoid upsetting clients. For this problem the script limits max-session to just one and waits for 2 hours before proceeding with disabling PPPoE servers.
This allows quite graceful software upgrade, provided that the network has at least N+1 redundancy in ASBR and BRAS.

After upgrade the script checks if the upgrade was successful, upgrades routerboard firmware if needed, then re-enables BGP peers and/or PPPoE servers. The script uses MikroTik::API perl module.