Mastodon

Having a detailed look at the Netgear Nighthawk M5 Mobile LTE/Router

Dr . Watson

After gaining root access to the device in the first post of this series, we will have a closer look at the device and its firmware.

This post is documenting some internals of the device which is not the most exciting stuff to read. I mainly collected it here for documentation purposes.

All information in this post has been collected from a device running firmware version NTGX55_12.04.12.00.

Software

Netgear’s firmware is Linux-based and uses quite a lot of common open-source tools. They provide all modifications to GPL licensed code via their support area: NETGEAR Open Source Software for Programmers.

From what I can tell only their user interface and configuration management is developed by Netgear themself apart from a bunch of binary blobs provided by Qualcomm which contains the modem firmware which gets loaded to the baseband processor.

One curiosity catched my eye: there is a running X server on the device. It is used by the front-panel display of the device. A custom application developed by Netgear uses Webkit’s engine to render the touch screen interface which just like the web UI is based on HTML and Javascript.

Here is an almost complete list of open source software components which I found on the device:

  • atk (v2.28)
  • Avahi (v0.7)
  • bash (v4.4.23)
  • base-files (v3.0.14)
  • BusyBox (v1.29.3)
  • conntrack-tools (v1.0.1)
  • D-Bus (v1.12.10)
  • ddclient (v3.8.1)
  • dhcpcd (v5.2.10)
  • DiG (v9.11.5-P4)
  • Dnsmasq (v2.85)
  • ethtool (v4.19)
  • font-config (v2.12.6)
  • freetype (v2.9.1)
  • glib (v2.58.0)
  • hostapd (v2.8-devel)
  • iproute2 (iproute2-ss140804)
  • iptables (v1.6.2)
  • iw (v4.14)
  • libcap (v2.25)
  • libnfnetlink (v1.0.0)
  • Linux Kernel (v4.14.117)
  • miniupnpd
  • mtd-utils (v2.0.2)
  • nettle (v3.4)
  • OpenSSL (v1.1.1b)
  • pimd (v2.1.8)
  • pppd (v2.4.7)
  • strace (v4.24)
  • SystemD (v239)
  • tinyproxy (v1.8.3)
  • util-linux (v2.32.1)
  • wireless-tools (v30)
  • wpa_supplicant (v2.9)
  • Xorg (v1.20.1)
  • xz (v5.2.4)

Basic facts

Lets first have a look at the Kernel version:

$ uname -a
Linux sdxprairie 4.14.117 #1 PREEMPT Thu Aug 19 23:42:26 UTC 2021 armv7l GNU/Linux

/ # cat /proc/version
Linux version 4.14.117 (oe-user@oe-host) (clang version 6.0.9 for Android NDK) #1 PREEMPT Thu Aug 19 23:42:26 UTC 2021

Apparently the firmware has been built by Open Embedded as indicated by the kernel notice „oe-user„.

There is also a /target file lying around. I assume that „sdxprairie“ is Qualcomm’s name for the SDK/BSP which is used by Netgear.

$ cat /target
sdxprairie

The application processor of the Snapdragon X55 is a fairly low powered single-core ARM v7:

$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : Qualcomm Technologies, Inc SDXPRAIRIE
Revision        : 0000
Serial          : 0000000000000000

With around 780 MB of RAM:

$ free -m
             total       used       free     shared    buffers     cached
Mem:           781        387        393          0          0        142
-/+ buffers/cache:        245        535
Swap:          109          0        109

SoC details

Within the SysFS we can find some details about the SoC. More details about the meaning can be found in the Kernel documentation:

SysFS EntryValue
/sys/devices/soc0/accessory_chip0
/sys/devices/soc0/chip_family0x5e
/sys/devices/soc0/chip_nameSDX55
/sys/devices/soc0/familySnapdragon
/sys/devices/soc0/foundry_id1
/sys/devices/soc0/hw_platformMTP
/sys/devices/soc0/image_crm_version:ntgrbc-fwbuild6
/sys/devices/soc0/image_variantMAATANAZA
/sys/devices/soc0/image_version00:BOOT.SBL.4.1-00231
/sys/devices/soc0/machineSDXPRAIRIE
/sys/devices/soc0/ncluster_array_offset0xb0
/sys/devices/soc0/ndefective_parts_array_offset0xb4
/sys/devices/soc0/nmodem_supported0xffffffff
/sys/devices/soc0/nproduct_id0x410
/sys/devices/soc0/num_clusters0x1
/sys/devices/soc0/num_defective_parts0xd
/sys/devices/soc0/platform_subtypeInvalid
/sys/devices/soc0/platform_subtype_id5
/sys/devices/soc0/platform_version65536
/sys/devices/soc0/pmic_die_revision131072
/sys/devices/soc0/pmic_model65568
/sys/devices/soc0/raw_device_family0x6
/sys/devices/soc0/raw_device_number0xb
/sys/devices/soc0/raw_id207
/sys/devices/soc0/raw_version2
/sys/devices/soc0/revision2.0
/sys/devices/soc0/select_image0
/sys/devices/soc0/serial_number27453XXXX
/sys/devices/soc0/soc_id357
/sys/devices/soc0/vendorQualcomm
$ cat /sys/devices/soc0/images
0:
        CRM:            00:BOOT.SBL.4.1-00231
        Variant:        MAATANAZA
        Version:        :ntgrbc-fwbuild6
1:
        CRM:            01:TZ.FU.5.9-00147
        Variant:        EATAANBAA
        Version:        :CRM
11:
        CRM:            11:MPSS.HI.2.0.c3.5-00010-SDX55_CPEALL_PACK-1.403198.3
        Variant:        sdx55.gennatch.prod
        Version:        :ntgrbc-fwbuild6

Kernel command line

$ cat /proc/cmdline<br>noinitrd rw rootwait console=ttyMSM0,115200,n8 androidboot.hardware=qcom msm_rtb.filter=0x237 androidboot.console=ttyMSM0 lpm_levels.sleep_disabled=1 firmware_class.path=/lib/firmware/updates service_locator.enable=1 net.ifnames=0 atlantic_fwd.rx_ring_size=1024 pci=pcie_bus_perf rootfstype=ubifs rootflags=bulk_read root=ubi0:rootfs ubi.mtd=24 androidboot.serialno=105d0dc7 androidboot.baseband=msm

Kernel log

Unfortunately, I was not able to capture early kernel log messages. I assume those are only printed via a serial port and lost as the circular buffer for the kernel log has not been set up.

More details…

Feel free to contact me if I missed any particular detail which is interesting for you.

Seminar: Camera-based PCB Analysis for Solder Paste Dispensing

2013-12-02_20.02.29

The lectures during my last semester were largely focused on digital image processing. Combining this with the inspiration for 3D printing, I gathered through my trip though South Korea, resulted in the following seminar paper. Seminars are a compulsory part of our curriculum which I like due the self-contained work and the ability to pick an individual topic.

Over the past year, I’ve built my own Kossel 3D printer. The Mini Kossel is based on a novel parallel delta kinematic which was developed by Johann C. Rocholl, a Google engineer from Germany.

This paper is targeting the automation of solder paste dispensing onto printed circuit boards by using computer vision and RepRap robots.

Full Slides as PDF
Full Paper as PDF
Source Code at GitHub

Seminar: Image Processing and Content Analysis

Camera-based PCB Analysis for Solder Paste Dispensing

Steffen Vogel (steffen.vogel@rwth-aachen.de)
Academic Advisor: Wei Li (wei.li@lfb.rwth-aachen.de)
Institute of Imaging & Computer Vision (LfB)
Rheinisch-Westfälische Technische Hochschule (RWTH), 52056 Aachen

1 Abstract

Two of the main challenges for PCB prototyping are the time-consuming setup of involved machines and their economic feasibility for small laboratories and hobbyists. This paper tries to offer solutions for both of these issues:

  1. The complex setup process of industrial machines can be accelerated by computer vision. It is preferable to automate this process as far as possible to enable the operation by untrained personnel and hobbyists. The workflow can be further simplified by not relying on external CAD data. This includes: detection of components, pads and footprints; mapping between available components and footprints and planning of shortest tool paths.
  2. The adaption of proven 3D printers allows to lower the costs for such machines. The lightweight and fast kinematics of parallel 3D-delta robots like the RepRap Mini Kossel are perfectly suited for the assembly of PCBs. Only the print head has to be exchanged between the individual steps of the process.

This work presents a workflow to control DIY 3D printers for the purpose of PCB assembly. By using cheap and easy-obtainable parts like proven RepRap 3D printers, this technique is viable for small laboratories, FabLabs and hobbyists. During the seminar, a analysis and control software for RepRap printers was written. Hence, we focus on the overall workflow and tools and less on algorithms and theory.
Here, the task of solder paste dispensing was chosen to be explored in detail. This work establishes the groundwork for more complex task like the pick and placing of electronic components.

2 Motivation

The ongoing miniaturization of electronic products like smartphones and Ultra Books has led to a new form factor for electronic components. Surface-mounted devices (SMD) are already widespread in electronic design and production. As a result, previously used through-hole components are gradually phased out. This miniaturization of SMD components is an ongoing trend and raises the barrier for hobbyists to produce PCBs themselves. Soldering and placement of 0401-sized resistors or BGA packages is not possible by hand any longer.

This work is motivated by the vision to build an all-in-one machine for the complete process of prototype PCB assembly (PCBA). To accelerate the development process and to reduce the costs, all of these tasks can be handled by a single workbench 3D printer / CNC mill. The PCB production process roughly can consists of the following steps:

  1. Isolation milling or pen plotting of PCB traces
  2. Drilling of holes and contours
  3. Solder paste dispensing for SMD pads with a syringe
  4. Pick-and-place of SMT components with vacuum
  5. Soldering with hot air, a hot plate or by a laser

For the scope of this paper, the process of solder paste dispensing was chosen. This task offers the biggest margin to profit from computer vision. Industrial mass production uses stencils to apply solder paste onto the PCB. For small prototype assemblies the fabrication of stencils is not worthwhile. Therefore, solder paste is applied manually with a pressurized syringe, which is hold by hand.
The dispensing of solder paste requires the knowledge exact solder pad positions and dimensions. Traditionally, this information is exported by CAD design tools and is required to produce the stencils.
But sometimes the CAD data is not available or stored in an inaccessible proprietary format. This paper presents techniques to gather the pad locations and dimensions by means of computer vision.

Fig. 1: Solder paste dispensing techniques
Fig. 1: Solder paste dispensing techniques
smd0805
Fig. 2: 0805-sized resistor
Seminar: Camera-based PCB Analysis for Solder Paste Dispensing weiterlesen

HIDeKey

Als Abschlussprojekt und Vorbereitung auf meine Betreuertätigkeit für die Mikrocontroller-AG des MMI’s habe ich mich näher mit dem USB-Bus und dem darauf aufbauenden HID-Protokoll befasst.

HIDeKey ist ein kleiner USB-Stick, der als HID-Tastatur vom Rechner erkannt wird und beliebge Zeichenketten und Tastenkombinationen an den Host-Rechner senden kann.

Mein Ziel war es ein kleinen Hardware-Dongle zu entwickeln welcher Passwörter, TANs und Onetime-Tokens direkt an jeden beliebigen Rechner senden kann. Meine Passwörter sind im verschlüsselt EEPROM des Mikrocontrollers gespeichert. Beim Drücken, des Tasters auf dem Stick, wird das Passwort eingegeben.

Als Hardware nutze ich die zuvor vorgestellten USBasp Programmieradapter aus China, deren Firmware ich durch eine eigene ersetzt habe. Mit einem zusätzlichen Taster lässt sich so über ein kleines Menü zwischen 10 User-Passwort-Kombination wählen.

Neue Passwörter können mit einem kleinen Konsolen-Programm direkt über den Rechner einprogrammiert werden.

HIDeKey soll auch zur Generierung von One Time Passwords (OTP) genutzt werden können. Da er sich wie ein gewöhnliche USB-Tastatur verhält, kann er auch unterwegs am Schlüsselbund in Internet-Cafes und Rechner-Pools genutzt werden.

Sourcecode & Schaltpläne etc. gibt es wieder per git. In meinem Wiki ist auch noch etwas Dokumentation gesammelt.

HIDeKey ist wie die meisten meiner Prrojekte als OpenSource veröffentlicht. Ich freue mich über jede Verbesserung, Erweiterung oder andere Beiträge zu diesem Projekt 🙂

elektro:camp(«2011.5»)

Wie letztes Jahr steht dieses Jahr wieder ein elektro:camp an.

Nachdem wir uns vergangenen Oktober gemeinsam beim Fraunhofer ITWM in Kaiserlautern getroffen haben, geht es dieses Jahr nach Stuttgart in die Hochschule der Medien:

Freitag 27.  + 28. Mai 2011, Hochschule der Medien, Stuttgart.

Zwei Tage lang treffen sich Entwickler/Hacker & Interessierte um über

  • Smart Metering
  • Home Automation
  • Renewable Energy
  • Home Displays & User Interfaces

zu diskutieren und in Form eines Barcamps kleine Vorträge zu halten. Ursprünglich wurde geplant das Camp jedes Jahr zu veranstalten. Mit dem Treffen im Mai läuft es vielleicht sogar bald auf einen halbjährigen Turnus hinaus 😉

Aus aktuellem Anlass wird es hoffentlich auch eine Diskussion über Geigerzähler und den Aufbau eines unabhängigen Sensornetzwerkes geben.

Neben flukso.net und mysmartgrid.net wird auch unser Projekt, volkszaehler.org, wieder dabei sein. Ich freue mich euch dort zu sehen 😉

MATLAB powered NXT omniwheel robot

Kurz vor Weihnachten beendeten wir unser Erstsemsterprojekt „MATLAB meets LEGO Mindstorms“ an der RWTH Aachen.

Während dieser Pflichtveranstaltung sollten wir die Lerninhalte der Vorlesung „Mathematische Methoden der Elektrotechnik“ durch Steuerung von LEGO Mindstorms NXT Robotern unter MATLAB vertiefen. Das Projekt ist eine Pflichtveranstaltung im 1. Semester meines Studienganges (Elektrotechnik, Informationstechnik und Technische Informatik) und wird durch alle Lehrstühle unserer Fakultät als 10-tägige Blockveranstaltung vor Weihnachten durchgeführt.

Ich wurde dem Institut für vernetzte System (MOBNETS) zugeteilt. Etwas verwundert war ich dann am ersten Tag, als wir auf Englisch begrüßt wurden. Aber naja, später werden wir vermutlich sowieso dazu gezwungen werden.

Während der ersten Woche lernten wir die eigens für das Projekt entwickelte „RWTH Mindstorms NXT-Toolbox“ kennen und haben an einigen vorgegebenen Versuchen gearbeitet.

In der zweiten Hälfte des Projektes durften wir dann in einem Wahlversuch selber kreativ werden und einen eigenen Roboter konstruieren.

Meine beiden Kollegen und ich haben uns für einen Roboter mit omnidirektionalem Antrieb entschieden. Das Prinzip dieses etwas außergewöhnlichen Antriebes wird das folgende Video deutlich.

Die Konstruktion der „Omniwheels“ war komplizierter als Anfangs angenommen. Dafür sind wir glücklicherweise recht schnell auf den nötigen Zusammenhang zwischen Fahrtrichtung und den drei Motorgeschwindigkeiten gekommen.

Als Projektabschluss mussten alle Gruppen ihren Roboter präsentieren. Unsere Präsentationsfolien gibts hier.

Features

  • Omniwheel-Antrieb
    • Bewegungsfreiheit in 360°
    • Drehen auf der Stelle
  • intuitive Fernsteuerung über zweiten NXT-Brick
    • durch Neigung des Controllers (Beschleunigungssensoren)
    • Schalter zur Steuerung des Programmablaufs
  • Signal-Hupe
  • akustischer Abstandswarner

Bilder