Bypassing Broken SIP ALG Implementations

The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.

The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.

[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.

The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.

Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.

Flashing Chips With A CNC

[Eberhard] needed to flash several hundred ATMegas for a project he was working on. This was a problem, but the task did have a few things going for it that made automation easy. The boards the ‘Megas were soldered to weren’t depanelized yet, and he had a neat and weird bed of nails programming connector. There was also a CNC machine close by. This sounds like the ideal situation for automation, and it turns out the setup was pretty easy.

The boards in question were for FPV/radio control telemetry adapter and thankfully the assembly house didn’t depanelize the 40 PCBs on each board before shipping them out. A very cool ATMega flashing tool handled the electrical connections between the computer and the microcontroller, but a real, live human being was still required to move this flashing tool from one chip to the next, upload the firmware, and repeat the process all over again.

The solution came by putting a few metal pins in the bed of a CNC mill, 3D print an adapter for the flashing tool, and writing a little code to move the flashing tool from one chip to the next. An extremely simple app takes care of moving the programmer to an unflashed chip, uploading the firmware, and continuing on to the next chip.

There’s still some work to be done that would basically tie together the Gcode and AVRdude commands into a single interface, but even now a complete panel of 40 PCBs can be programmed in a little over 10 minutes. You can check out a video of that below.

Continue reading “Flashing Chips With A CNC”

Repairing A Router Plagued By Capacitors

[psgarcha]’s modem/router comes straight from his internet provider, is on 24/7, and is built with the cheapest components imaginable. Eventually, this will be a problem and for [psgarcha], this problem manifested itself sooner than expected. Fortunately, there was a soldering iron handy.

The problems began with a boot loop – starting the router up, watching the blinking LEDs, and watching these lights follow the same pattern forever. Initially thinking this would be a problem with the firmware, [psgarcha] did the only thing he could do – take it apart. Inside, he found some bulging capacitors. Unsheathing his iron and replacing the obviously faulty components, [psgarcha] plugged the router in and had everything work. Great. Until those caps failed again a few months later.

There was obviously something wrong with the circuit, or wrong with the environment. Figuring it was hot out anyway, [psgarcha] replaced those caps again and added a fan and a small heatsink to the largest chip on the board. This should solve any overheating problems, but the real testing must be done in summer (or putting the router in a well-insulated enclosure). It’s an easy fix, a good reminder of exactly how often caps fail, and a great example of reducing the electronic cruft building up in landfills.

Bridging Networks With The Flip Of A Switch

The TP-Link TL-WR703n is the WRT54G for the modern era – extremely hackable, cheap, and available just about everywhere. Loaded up with OpenWRT, it’s capable of bridging networks: turning Ethernet into WiFi and vice versa. This requires reconfiguring the router, and after doing this enough times, [Martin] was looking for a better solution. The SOC inside the WR703n has two exposed GPIO pins, allowing [Martin] to choose between WiFi access point or client and between bridged or NAT/DHCP.

According to the OpenWRT wiki, there are a few GPIOs available, and after connecting these pins to a DIP switch, [Martin] could access these switches through the firmware. The hard part of this build is building the script to change the settings when the system boots. This script looks at the state of the GPIOs and changes the WiFi into client or access point mode and tries not to muck about with the DHCP somewhere off in the cloud. Yes, we just used cloud in its proper context.

The only other hardware to complete this build was a simple USB to serial converter that should be shoved into the corner of everyone’s workbench. Not bad for an extremely minimal soldering and configuration required for a something that’s extremely useful.

Hackaday Links: November 2, 2014

Russians blowing up capacitors! As we all know, electronics only work because of blue smoke. [kreosan] is releasing this blue smoke from a few hundred caps. Fun times, even if they are a large number of inert tube shields in their collection of caps.

[mayhugh1] over on the home model engine machinist forum has built an 18 cylinder radial engine. It’s based on the Hodgson 9-cylinder radial engine that has been around for a while. The crank case is machined from a 5″ diameter rod of aluminum. There’s a Picassa album of the engine being constructed as well.

[Richard] wanted a Minecraft server, but not just any Minecraft server; this one demanded a custom case. A grass block was the inspiration, acrylic the medium, and a quad-core Mini-ITX the guts of the project.

Halloween was last Friday, and as always the tip line filled up with costume builds. [Leif] built a Ghostbusters costume complete with Muon trap, [Jeff] printed out some steampunk post-apocolyptic goggles, and [Green Gentleman] made a death-a-corn, although we’re struggling to figure out why the last one isn’t called an acorn-‘o-lantern.

[Matthias Wandel], a.k.a. the dude,  is well-known in certain circles for being a wizard of wood. One of the first projects that put him on the map was a pantorouter – a router to cut mortises and tenons. He’s going back to his roots and building a bigger version. This version uses models of routers that are available outside North America, and in the latest video [Matthias] has it dialed in very well.

The Open Source Remote Control was an entry for The Hackaday Prize that didn’t make the final cut. It’s now an indiegogo project, and has some really cool tech we can’t wait to see in mainstream RC transmitters.

Another Internet of Things Board (But This One Has Lisp)

Using routers as dev boards has been a long and cherished tradition in the circles we frequent, and finally design houses in China are taking notice. There have been a few ‘Internet of Things’ boards in recent months that have taken the SoC found in low-end routers, packaged the on a board with USB, some GPIOs, and a fair bit of memory and called it a dev board. The ZERO Plus is not an exception to this trend, but it does include a very interesting feature when it comes to the development environment: this one uses Lisp as its native language.

The Zero Plus is pretty much what you would expect from a router SoC being transplanted to an Internet of Things board: it uses the Ralink RT5350 SoC, giving it 802.11b/g/n, has 32MB of RAM, 8 or 16 M of Flash, I2C, I2S, SPI, USB, two UARTs, and 14 GPIOs. There is support for a webcam, temperature and humidity sensor, displays, and Arduino via a breakout board that appears to contain a standard, DIP-sized ATMega328,

All of that could be found in dozens of other boards, though. What really sets this one apart is the Lisp development environment. Programming the Zero is exactly as elegant as you would expect, with a ‘toggle a LED according to what time it is’ program looking something like this:

(define LED_On (lambda ()(dev.gpio 11 “out” 1)))
(define LED_Off (lambda ()(dev.gpio 11 “out” 0)))
(define CurrentTime? (lambda ()
(int (time.strftime “%H” (time.localtime (time.time))))))
(define Night?
(lambda ()
(> ( CurrentTime? ) 16) (< ( CurrentTime? ) 23)
(if (Night?) (LED_On) (LED_Off)

Dev boards built around somewhat more esoteric programming language isn’t anything new; The Espruino brings Javascript to ARM microcontrollers, and the MicroPython project is an astonishing undertaking and successful Kickstarter that brings the BASIC for the 21st century to the embedded world. Lisp, though… I don’t think anyone expected that. It’s a great way to differentiate your product, though.

Playing Doom (Poorly) on a VoCore

Last May brought the unastonishing news that companies were taking the Systems on Chip found in $20 wireless routers and making dev boards out of them. The first of these is the VoCore, an Indiegogo campaign for a 360MHz CPU with 8MB of Flash and 32MB or RAM packaged in a square inch PCB for the Internet of Things. Now that the Indiegogo rewards are heading out to workbenches the world over, it was only a matter of time before someone got Doom to run on one of them.

After fixing some design flaws in the first run of VoCores, [Pyrofer] did the usual things you would do with a tiny system running Linux – webcams for streaming video, USB sound cards to play internet radio, and the normal stuff OpenWrt does.

His curiosity satiated, [Pyrofer] turned to more esoteric builds. WIth a color LCD from Sparkfun, he got an NES emulator running. This is all through hardware SPI, mind you. Simple 2D graphics are cool enough, but the standard graphical test for all low powered computers is, of course, Doom.

The game runs, but just barely. Still, [Pyrofer] is happy with the VoCore and with a little more work with the SPI and bringing a framebuffer to his tiny system, he might have a neat portable Doom machine on his hands.