Gallery

# ST Link V2 Upgrade

Fig 1 - Modified PCB

Intro

ST put out a video ages ago showing some mods to their low cost debugger. They added some LEDs and a 5V output, not
very useful. Here's some tips for turning your ST Link into a general purpose ARM debugger while still maintaining
the original looks and function of the device.

To get the new functionality, we need to flash the debugger itself with new firmware. An open source project called
Black Magic Probe exists which gives us a choice between
SWD or JTAG, no need to install drivers(BMP is a standard serial device!), painless build and reload workflow on
linux and optionally UART.

Prerequisites

ST Link V2 debugger

Another ST Link or a discovery board

Soldering iron and enameled wire

A working ARM GCC install

Various other linux command line tools that are unavailable on your distro or fail to build just for you

Building

Luckily the BMP firmware has few dependencies and the ones it has are submodules with the make file doing all the work
(´ ・ω・` )

You shouldn't get any warnings or errors and have two new files: blackmagic.bin and blackmagic_dfu.bin

ST Link V2 SWD header

You'll want to solder a header to CN1 on your target debugger, the pin out is provided below.

Fig 2 - CN1 Header

Now connect the two debuggers together.

Flashing

To flash we need to use either the official ST tool or a combination of texane stlink util to do a full erase and OpenOCD to unlock the flash region. Neither of these tools
will be used after flashing is complete.

If any of the flashing steps fails, remember we don't have a NRST signal so you'll need to manually reset the device.

If all went well you can now connect the debugger via USB and you'll see two new devices under /dev/. The first is
the debug target itself, the second is a serial port we can use to communicate with the target.

Fig 3 - Debug Header

The debugger pin out remains the same as the original however the bottom row except pin 2 are connected to ground.
Next we'll make 6 and 4 actually function as UART ( ´_ゝ`)

Adding UART

Take a knife to the back of the PCB, cutting the connection from the ground plane to pins 6 and 4.

Fig 4 - UART

Run two wires from U1 pin 12 and 13 to 6 and 4 respectively.

Fig 5 - Don't burn your fingers

Try not to forget this is a direct CPU connection so RS232 will almost certainly not work.

Congratulations you now have a self contained debugger and serial port that will work with a heap of different ARM
platforms.

References

https://github.com/blacksphere/blackmagic/wiki

https://wiki.paparazziuav.org/wiki/STLink

http://www.st.com/resource/en/datasheet/stm32f405og.pdf

http://www.st.com/resource/en/datasheet/stm32f103tb.pdf

# SOHO Network

Outline

So in preparation for moving into our new office/house I've been tasked with designing and implementing a network that
can function as both a secure business LAN and a private end point for users.

The biggest challenge was finding a way to securely deal with multiple networks and services while keeping costs minimal
and avoiding purchasing additional equipment. We could have easily gone with customer supplied gateways into a concentrator
as local ISP's allow multiple PPPoE logins over a single link. But since we have HFC available I wanted to try a
more elegant solution.

The decision to go with HFC means telephony must travel over IP or there is no cost savings to using cable. This means
we must also become the telco for land-line services. VoIP has several advantages to using POTS, namely significant
savings in line rental(As of writing this article the cost per line for direct PSTN access is 4 times the cost of
using a remote trunking service), however it is at the expense of increased management and creating a single point
of failure.

Care must also be taken to ensure the arrangement meets and exceeds the users demands and expectations of the service
and to not encumber access to any functionality otherwise available.

Implementation

Fig 1 - Topkek Topology

Above shows the pseudo layout at the L2 level. Separation is handled via VLAN's naturally, wireless separation is done
through DD-WRT bridges, see: VLAN Detached Networks.
Phones are locked to ports and ignore broadcast, a change of MAC on one of these ports will immediately disable it
until the original device is restored, as a further measure SNMP trap events are sent the moment one of these ports
are down. A 'General' port is used between the router and switch to prevent iSCSI traffic (several Gbps) from flooding
the router. Only Virtual Machines assigned with an appropriate virtual adapter have access to private networks, VLAN
tagging is done by the hypervisor and not by the VM's.

As far as hardware is concerned, the backbone of the network consists of a Dell PowerConnect 5524 with battery backup, this Layer 2 switch handles most of the security enforcement. For routing we have a Juniper SRX210HE,
this is in charge of providing the zone based firewall, NAT, DHCPv4, SLAAC, 6in4 tunneling and sFlow for monitoring.

An out of band switch connects IPMI, SNMP and various management interfaces together and can only be accessed physically
from the rack or by administrators over VPN.

Layer 3

VLAN100 is confined to the Guest zone, it has an independent firewall and security
policies from the main public network, this interface is rate limited to prevent DoS and penetration attempts from
Guest to Trust via the internal data plane. Customer VLANs are a mirror image of this.

VLAN1 and 2, which is part of the Trust zone
consists of a IPv4 inbound services policy and respective NAT, IPv6 uses a per server policy set. Inter-VLAN routing
is provided for 1<->2 access on a case by case basis through the firewall:

Lastly the usual barrage of DoS and brute force attacks from the Internet are dealt with using a screening filter.
RPF is enabled on all interfaces with an exception for DHCPv4 broadcasts.

Telephony

A PBX server running FreePBX is used for routing VoIP, everything is SIP end to end until it reaches the PSTN, CoS
means little to no latency and no dropped calls, I've tested this extensively on ADSL2+ and even on a problematic
line voice is clear and reliable.

Customers are provided with DID(s) at a monthly rate with call excess added on, free voicemail is also available. In
the next few weeks I'll write a script to pull CDR from FreePBX and automatically generate invoices, but since there
will only be two users initially this is low priority. I'm also considering switching to sipXecs, but it is less
supported and will need to be tested extensively.

CoS/QoS

All WAN bound traffic is classified by a rule set, based on the originating zone and type of traffic we can assign
packets to an appropriate queue on the egress interface. The switch also prioritizes VLAN3's traffic to insure large
LAN transactions like those created by SMB do not affect voice quality.

Remote Access and Authentication

VPN is provided using SoftEther VPN Server, the built in access lists can be assigned to RADIUS accounts allowing the
single server instance to provide access to all or some networks.

We use RADIUS where possible for unified sign on, this is managed by the local Active Directory server which of course
machines must join before they can access anything interesting.

Conclusion

¯\_(ツ)_/¯Fig 2 - Me as a sysadmin

Besides software configuration we're also moving to a much larger rack (18U -> 40U) and as such need to re-cable
everything. It will be nice to have room for cable management and a rack thats properly setup to handle it.

In time I will write some tutorials on JunOS and other network technologies as I'm still learning myself.

# Perfect Iced Coffee

Makes 2 Liters.

Ingredients

Instant Coffee 60 cm3

White Sugar 120 cm3

Water (+85 +100° C) 500 mL

Water (-20 +4° C) 500 mL

Milk (+4° C) 1 L

Method

Mix coffee, sugar and hot water together until sugar grains saturate. Recommended baking time is 60-90 seconds at +85°
C.

Extreme care should be taken to insure water does not exceed +100° C or it will become highly volatile when exposed
to contaminants.