ONV PD3401G PoE Splitter Teardown & Review

Continuing my PoE series, I bought the ONV PD3401G, an active PoE splitter that is capable of extracting up to 60W (24V @ 2.5A) from the PSE. It is housed in a small aluminum extruded case that can be DIN rail mounted. This splitter is comparatively low-cost, about US$35, and more importantly, is capable of passing through Gigabit.

ONV seems to be quite a reputable company, so I believe their products shouldn’t be too badly designed. This unit can also be easily purchased on Aliexpress without having to go through some obscure distributor.

ONV PoE splitter, side view

ONV PoE splitter, front view

Internally it uses the LT4275A (marking LTGBT) for PD interfacing. The A variant of this chip supports up to 90W of power. On the power supply side, it uses a NCP1034 synchronous buck converter. The NCP1034 is capable of handling up to 100V, which is more than sufficient for PoE.

Looking inside, the in/out Ethernet ports are connected via a transformer, in order extract power from the center taps of each pair. We can see that the PCB traces for the input port pairs are thicker to carry the higher currents. Large beefy diodes form rectifier bridges for the data pairs.

PCB, top side

Surrounding the input port on the underside, there are a lot of unpopulated components; those were supposed to offer input protection, probably using some TVS of some kind. these are marked RD1 ~ RD8, one for each Ethernet wire.

Continue reading →

35C3 CTF Write-up: php

php (web)

PHP’s unserialization mechanism can be exceptional. Guest challenge by jvoisin.

Files at https://35c3ctf.ccc.ac/uploads/php-ff2d1f97076ff25c5d0858616c26fac7.tar. Challenge running at: nc 35.242.207.13 1

This challenge exposes a service written in PHP, and as you can guess, it has something to do with unserialization.

The single source file is straightforward to understand:

<?php

$line = trim(fgets(STDIN));

$flag = file_get_contents('/flag');

class B {
  function __destruct() {
    global $flag;
    echo $flag;
  }
}

$a = @unserialize($line);

throw new Exception('Well that was unexpected…');

echo $a;

Your goal is to get the flag printed by somehow getting the destructor of class B to execute.

Continue reading →

Extending ASUSWRT Functionality, Part 2

Following up from my earlier post, Asus has released faster and beefier routers. But perhaps the more important change here is that they have moved from MIPS in the RT-N56U to ARM in newer routers. I have also upgraded to the RT-AC68U for better reception and hopefully to fix the poor battery life experienced by my Android tablet.

the Asus N56U and AC68U routers, side by side

After upgrading, I noticed that the method I described back then no longer works. Someone also noticed this, as they translated key portions of my post into Chinese, while pointing out some of the steps that didn’t work.

In this post, I’ll summarize the key changes required to get it working again.

Continue reading →

Boot-time Device Tree Overlays with U-Boot

I bought a Banana Pi some time ago and have been using it as my go-to ARM box. Among the single-board computers I have, this Allwinner A20-based platform has the fastest CPU.

Similar to the (old) Raspberry Pi, it has a 26-pin GPIO header on one side that sports the same layout. This means that the 5V, 3V3 and I2C pins are the same as where they would be on the Raspberry Pi.

Device Tree & Overlays

On embedded systems, the Device Tree helps the kernel understand various peripherals that are connected to the board and how to initialize them. These hardware might be things like LDO regulators, various controllers, GPIO, etc which are generic, but yet needs certain configuration that should not be hard-coded into the kernel. To understand more about device trees I recommend you start with the Raspberry Pi documentation on this topic. There are more links at the end of this article.

To support Pi HATs and other non-HAT accessories, the Pi added a dtoverlay configuration parameter in the config.txt file. This allows you to specify, at boot time, Device Tree Overlays, which modify the board’s base device tree to specify additional peripherals like I2C devices, or to configure GPIO pins for certain purposes. The BeagleBone also has a similar mechanism to support its add-on boards via Capemgr. These mechanisms enable non-technical users to easily modify the device tree by simply editing a text file or running a command. Neither of these have been adopted into mainline Linux, so there is no provisions for doing quick overlays on other boards yet.

Fortunately for us, device tree overlay support has been merged into U-Boot, and the Banana Pi uses U-Boot for booting Linux. This means that U-Boot can perform the merging of device tree overlays with the base device tree, and pass the entire Flattened Device Tree (FDT) structure to the kernel during boot-up.

Before we get started, you will need the i2c-tools and dtc-overlay package, and the U-Boot source code for the mkimage tool (you did have to compile U-Boot for your Banana Pi right?)

Creating the Overlay

For this example, we will be attaching an INA219 current sensor to the Banana Pi over I2C. The kernel has drivers for this sensor in its hwmon subsystem and provides an easy way of reading values for us.

INA219 current sensor breakout board

The default I2C address on most INA219 breakout boards is with the address lines A0 and A1 grounded, giving it an address of 0x40. Also note that the shunt resistor is marked with R100, which denotes 0.1 mΩ or 100,000 µΩ.

My Banana Pi has 3 I2C buses:

$ i2cdetect -l
i2c-1   unknown         mv64xxx_i2c adapter             N/A
i2c-2   unknown         sun4i_hdmi_i2c adapter          N/A
i2c-0   unknown         mv64xxx_i2c adapter             N/A

We will try scanning each of the buses, and the one with device 0x40 will likely be the bus that is exposed via the GPIO headers. We can do this using i2cdetect:

# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

The last parameter to i2cdetect specifies the bus number, which is 1 in this case. We can see here that the INA219 has been correctly wired and detected, as it shows up in the I2C bus scan.

We now need to find out which device tree node this bus corresponds to:

$ readlink /sys/class/i2c-adapter/i2c-1/of_node
../../../../../firmware/devicetree/base/soc@1c00000/i2c@1c2b400

In order to figure out the symbolic name for this I2C bus, we can grep from the kernel’s live device tree, parsed with the help of the dtc utility:

# dtc -I fs /proc/device-tree | grep 1c2b400
...
    i2c2 = "/soc@1c00000/i2c@1c2b400";

Continue reading →

PoE: Quick Guide & Cheap Hardware

I have been looking around for Power over Ethernet (PoE) devices to supply power to some networking hardware that will be located in a remote location, without a convenient power outlet. These networking hardware do not have built-in PoE support, so I have to find both an injector and a splitter device.

PoE is typically found on enterprise networking equipment, which usually means a higher price tag. Not wanting to spend a ton on PoE hardware, I did some research to understand what was required to make it work.

Hopefully this will help you understand PoE, how it works, and what to look out for when shopping for PoE hardware that are suitable for your needs.

PoE Quick Guide

Active vs Passive

Passive adapters are very simple, and you will see them mostly as an RJ45 socket with pigtails for power and Ethernet. These adapters do not contain or require any circuitry, which also explains why they are the more inexpensive option between the two.

Photo of a passive PoE injector & splitter pair, sold on Adafruit

Active PoE (the real Power over Ethernet) on the other hand requires some negotiation between the two devices, called the PSE (power sourcing equipment) and the PD (powered device).

There are several PoE standards. 802.3af, 802.3at and the newer 802.3bt. The difference is mainly in the maximum power is made available to PDs:

  • 802.3af – 15.4W
  • 802.3at – 30W
  • 802.3bt – 60W to 100W

802.3bt was just ratified in the last year (2017). In the time span before the 802.3bt standards was ratified (~8 years!), some companies like Linear Technolgy & Cisco Systems took it upon themselves to find other means of carrying up to 60W. The result was LTPoE++ and UPOE, an evolution of the existing 802.3af/at standards, but may not be compatible with the final standard arrived at by committee.

Mode A or B

The Cat5 cable has 8 wires, forming 4 twisted pairs. For 10/100Mbps, only 2 pairs are used: pair 1/2 for Tx and pair 3/6 for Rx.

The modes refer to how power is delivered to the device:

  • Mode A: pairs 1/2, 3/6
  • Mode B: pairs 4/5, 7/8

PoE mode A & B wiring diagram

Mode A uses the data pairs for power. This mode is well suited for very old cabling which didn’t connect all 4 pairs end-to-end. You might see some manufacturers calling this mode End-span wiring. To carry power over the same data cables, phantom power delivery is used (more on this later).

Mode B uses the unused (or spare) pairs for power. You might see this being referred to as Mid-span. This type of wiring is easier because it knows the pair is not carrying any data and thus can be wired directly.

Unlike mode A, mode B in this form cannot be used to carry power for Gigabit networks, because a Gigabit connection will require all 4 pairs for data transmission. Power must therefore be delivered via centre-tapped transformers, or what is known as phantom power. How this works is explained in a 1944 US Army video on telephone electronics.

Power Capacity

The committee decided that two pairs of Cat5 wire should only carry up to 30W of power; which two pairs will depend on whether mode A or B wiring is used.

For higher power capacity like 802.3bt (PoE++) or the non-standards-based UPOE and LTPoE++, the other 2 pairs will be paralleled up, making use of all 4 pairs to carry higher currents.

PoE wiring diagram for 4-pair based PoE

For Gigabit Ethernet (1000Mbps), because all 4 pairs are used to carry data, power (regardless of which pairs used) must be delivered via phantom power delivery.

Why use Active PoE?

In short, because it is safer.

It was designed with the consideration that not all network equipment can accept power, whether via the data pairs or spare pairs.

During the detection phase, the PSE will apply 2.7V to 10V to check for a known resistance. This voltage is low enogh and also for a brief period such that it wouldn’t matter if the device on the other end is shorted. A device that was not designed for PoE would thus never see any higher voltage beyond the detection phase.

Graph depicting voltage vs time during various PoE phases

In contrast, passive PoE makes the full voltage and current available on the data/spare pairs. If the remote end is using a magnetics configuration that shorts out the centre taps, the 30W of power would just melt the port (one would assume).

Integrated PSE controller chipsets will also contain features like overcurrent protection, thermal cut-offs and surge protection, etc. which all contribute towards keeping your PDs safe from harm.

Finding Low-Cost PoE Hardware

It was quite a daunting task, trawling AliExpress for PoE injectors & splitters. The description or specifications for items are also not accurate; it’s like finding a USB cable listed as capable of carrying 2A when in fact it does not.

While passive injectors are the cheapest option, most of them are not meant for Gigabit Ethernet. Recall that Mode B wiring is the easiest and most low-cost method for building a passive device, and that is what you will mostly find. This wiring configuration does not pass through all 4 pairs and thus cannot be used for Gigabit.

Most active PoE splitters output 12V, or 5V via USB. This is largely due to the fact that these devices were meant for IP cameras, which operate at that voltage. If your target device uses a non-standard voltage, you will have difficulty finding a suitable (and yet low-cost) splitter.

Here’s a list of hardware I’ve found; which one is suitable for you depends on your requirements:

  • Do you need 1000Mbps, or just 10/100Mbps would suffice?
  • What voltage does your target device require?
  • How much power does it require? 13W, 30W?

Continue reading →