Following on from APNIC’s (Asia Pacific NIC) earlier assessment that they would need to request the last available /8 blocks, they have now been allocated 39/8 and 106/8, triggering IANAs (Internet Assigned Numbers Authority) final distribution of blocks to the RIRs (Regional Internet Registries).

APNIC which is the fastest growing Internet region is expected to be the first regional NIC to run out of IP address space within 3 to 6 months time.

Over the last few months I have been trying to improve the management of our collection of Polycom Soundpoint IP telephones. They were initially configured by some friendly consultants with static IPs and no registration to our SIP proxy which meant that the media servers were configured to route to the IPs of phones instead of the extension. (I KNOW, what on earth were they thinking?) The stupidity of this configuration became even more indefensible when it became clear that the same company had sold us both the SIP proxy, and a TFTP based telephone provisioning server!

There seems to be a fair bit of confusion and misinformation on the net about how to:

• Tell a Polycom phone to use a dedicated Voice VLAN that is separate from an untagged PC VLAN completely automatically
• Tell a Polycom phone to provision it’s (SIP) configuration data from TFTP (or HTTP) completely automatically

The good news is that both of these are trivially done with simple modifications to your DHCP server’s configuration.

I am going to assume that you have an ethernet network with VLAN ID 2 used for PC data and VLAN ID 3 used for VoIP (Quite likely you are reserving VLAN ID 1 for management, but it’s not important here)

To get a phone to pass through the “PC” VLAN to it’s second ethernet port while it itself uses a separate “Voice” VLAN, you need to do the following:

• Configure the ethernet switch port connected to the Polycom phone as a “hybrid” trunk with VLAN ID 2 untagged and VLAN ID 3 tagged
• Configure the DHCP server running on VLAN 2 to serve DHCP option 128 as a “String” with the contents “VLAN-A=3;”
• (Re)boot the phone… (If you have already been manually configuring things you may want to do a factory reset of the phone to make sure you haven’t broken something)
• At this point the phone should boot, receive an IP on VLAN 2, see that there is DHCP option 128 telling it to use VLAN 3, switch automatically to VLAN 3, and send out another DHCP request on that VLAN (You of course need to have a DHCP server setup on VLAN 3 also or the phone will fail here…)

This has solved our VLAN configuration option, but what about the rest of the SIP config? For that we need to tell the phone where to find our TFTP provisioning server:

• Configure the DHCP server on VLAN 3 (The Voice VLAN) to serve option 66 as a “string” with the contents “tftp://my.tftp.server.address/” (Set this to the IP or DNS of your TFTP server)

The setup, placement and contents of the Polycom configuration files on the TFTP server are left as an exercise for the reader as there are plenty of examples of how to do that.

Dutch security researcher Niels Teusink has discovered a method of attacking wireless presenter devices allowing remote code execution on the host PC by sending arbitrary keystrokes to the presenter dongle!

The full description and source code is in his blog post Hacking wireless presenters with an Arduino and Metasploit

Kurt Grandis carried out an awesome Django vs .NET experiment at his company:

Almost two years ago I was in a rather unlikely situation in that I was running a software engineering department containing both a C# team and a Python team…It slowly dawned on me that I had a perfect test bed. Here we had two teams using different technology stacks within the same department…they shared the same development processes, project management tools, quality control measures, defect management processes. Everything was the same between these groups except for the technologies. Perfect! So like any good manager I turned my teams into unwitting guinea pigs.

With the result:

We found the average productivity of a single Django developer to be equivalent to the output generated by two C# ASP.NET developers. Given equal-sized teams, Django allowed our developers to be twice as productive as our ASP.NET team.