Missing something on 700/1400 (R77.20.8x) ? strace on a 730

[APopisteru]

700/1400 were quite nice and powerful boxes. Were, because after a tremendous development effort, the new 1500 series were intorduced in 2019, leveraging a more powerful hardware architecture and, more important, bringing the SMB line to R80 world and unifying the management options - thus, the 700/1400 series will reach end of sale in May 2020 and, aligned with Support Life Cycle Policy, maintenance releases and/or bug fixes will be supplied until October 2022. That means a full 5 1/2 years lifecycle of the 700/1400 line, far beyond the common hardware obsolescence.

So, maintenance releases and/or bug fixes, no new software development. What if I need a tool (executable, user-space) which was not included in the software package (R77.20.87 JHF Build 990173004 General Availability release is the latest at the time of writing) and is not mandatory for the proper functioning of the platform, to be included in maintenance releases ? Remember - using even the executables supplied with the software package in expert mode is not supported, meaning that TAC will not assist you in troubleshooting the proper or improper usage of them.

Well, I could help myself and compile the tool for the platform. Disclaimer: the activities described in this post are neither  endorsed, approved nor supported by the organization - they are the result of individual explorations and described only for educational purposes; the results were not assessed by the rigorous QA routines applied to GA releases. Please read carefully the EULA regarding implications before any attempt to reproduce the procedures described in this post.

That being said, I would like to have the powerful OS tool, strace, running on my 730. Warning: tracing a process can heavily affect performance up to two orders of magnitude slow-down in syscalls, please think twice before using in a production environment.

A decent development environment is required. Mine is an oldish i5 gen3 / 8 GB DRAM running Ubuntu 16.04 x86_64 LTS. If running a newer version, the operations described might need to be adjusted to the environment.

A cross compiling set of tools is also required (you are not logged in as root, are you?):

sudo apt-get install -y wget curl git python \
gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf binutils-arm-linux-gnueabihf \
make gcc binutils patch build-essential bc\
flex bison gawk libncurses5-dev gettext autoconf automake autotools-dev xz-utils

run dpkg -L on gcc-arm-linux-gnueabihf, g++-arm-linux-gnueabihf and binutils-arm-linux-gnueabihf and record the install location, you might need it later.

Note: the GNU toolchain is not the original one used to compile the software release, you can run strings on binaries on the box to find out the original one, which is still freely available).

The source - I used strace-4.14 and not the latest version available on https://github.com/strace/strace because starting with version 4.15 strace is able to modify return/error code of the syscalls, and to inject signals upon their execution. Pretty dangerous!

Get the source, extract it and step in the source folder (adjust to your own $PWD

wget https://sourceforge.net/projects/strace/files/strace/4.14/strace-4.14.tar.xz
tar -xvf strace-4.14.tar.xz
cd strace-4.14

To keep it simple, configure the build for a statically linked executable on the target ARM architecture:

env \
CC=arm-linux-gnueabihf-gcc \
LDFLAGS="-static" \
AR=/usr/bin/arm-linux-gnueabihf-ar \
./configure --build x86_64-pc-linux-gnu --host arm-linux-gnueabihf

Review the Makefile and run

make

Note that statically linked binaries require at runtime the shared libraries from the glibc version used for linking.

Let's inspect it the output:

ps-101-ro@PS-101-RO:~/strace-4.14$ ll strace
-rwxr-xr-x 1 ps-101-ro root 1808548 mar 28 15:37 strace*
ps-101-ro@PS-101-RO:~/strace-4.14$ file strace
strace: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=6ea347bca3a91079c96b72fbfd59de6ffff70cb4, not stripped

Shrink the binary:

ps-101-ro@PS-101-RO:~/strace-4.14$ /usr/bin/arm-linux-gnueabihf-strip strace
ps-101-ro@PS-101-RO:~/strace-4.14$ ll strace
-rwxr-xr-x 1 ps-101-ro root 750976 mar 28 15:44 strace*

Use your favourite method (scp or sneakernet on FAT32 formatted USB) to load the executable in /storage folder on the 730. Mine runs:

[Expert@730]# uname -a
Linux 730 3.10.20-al-5.0-pr2 #1 SMP Wed Jun 19 10:20:09 IDT 2019 armv7l arm GNU/Linux
[Expert@730]# clish -c "show diag" | head -11
Current system info
-----------------------------------
Current image name: R77_990173004_20_87
Current image version: 004
Previous image name: R77_990172929_20_87
Previous image version: 929
Default image name: R77_990170952_20_31
Default image version: 952
Bootloader version: 68

Switch to /storage and give strace a try:

[Expert@730]# ./strace -V
strace -- version 4.14

Let's attach strace to a running process, say arping (if you're wondering what arping might do, think of gateway monitoring):

[Expert@730]# PIDOFARP=`ps -ef | grep -v grep | grep arping | OFS=" \t" awk '{print $2}'`
[Expert@730]# strace -v -e trace=sendto -o /storage/strace.out -p $PIDOFARP -f
strace: Process 4451 attached
^Cstrace: Process 4451 detached

and check the output:

[Expert@730]# tail /storage/strace.out
4451 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
4451 sendto(22,"\0\1\10\0\6\4\0\1\0\34\177s\rw\254\21k\32\270\312:\312\204\277\254\21k\274", 28, 0, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ARP), sll_ifindex=if_nametoindex("WAN"), sll_hatype=ARPHRD_ETHER, sll_pkttype=PACKET_HOST, sll_halen=6, sll_addr=[0xb8, 0xca, 0x3a, 0xca, 0x84, 0xbf]}, 20) = 28

QED

If your're interested, I posted the exercise of having hping3running on 730 (why would someone want to run hping from the firewall and not through the firewall?).

Stay healthy, stay secured!

[PhoneBoy]

I can see how this might be useful.
One tool I'd like to see is tcptraceroute, if you're taking suggestions. 😬
Obviously goes without saying this is completely unsupported.

[APopisteru]

Monsieur est servi!

tcptraceroute , which hardly could be described as maintained, depends on libnet (more recently on libnet1) and libpcap. Only libpcap-1.9 was smoothly compiled from the currently maintained github repository (git clone, git checkout origin/libpcap-1.9.1, configure with build and host and make install), libnet.so & tcptraceroute were compiled using more obscure & tedious manual procedures.

Extract the attach archive in /storage.  Tested with the following flags:

[Expert@730]# ./tcptraceroute -d -n -i WAN -m 20 -w 10 -t 8 203.0.xxx.yyy 80
debug: tcptraceroute 1.5beta7
debug: Compiled with libpcap version 1.9.1 (with TPACKET_V3); libnet 1.3-dev (API 110)
debug: o_numeric set to 1
debug: device set to WAN
debug: o_maxttl set to 20
debug: o_timeout set to 10
debug: o_tos set to 8
debug: entering getinterfaces()
debug: ifreq buffer set to 32
debug: Successfully retrieved interface list
debug: Discovered interface lo with address 127.0.0.1
debug: Discovered interface WAN with address 172.xxx.yyy.24
debug: Discovered interface LAN1 with address 192.xxx.yyy.1
debug: Discovered interface br0 with address 10.154.xxx.yyy
debug: Discovered interface br1 with address 10.34.xxx.yyy
debug: Discovered interface br2 with address 10.14.xxx.yyy
debug: Discovered interface LAN3.830 with address 192.xxx.yyy.1
debug: Discovered interface LAN2.830 with address 192.xxx.yyy.1
debug: leaving getinterfaces()
debug: Determined source address of 172.xxx.yyy.24 to reach 203.0.xxx.yyy
debug: Setting o_syn, in absence of either o_syn or o_ack
debug: debugoptions():
debug:         TEXTSIZE: 1024        SNAPLEN: 92     IPTOSBUFFERS: 12
debug: ALLOCATEID_CACHE: 512        datalink: 1    datalinkoffset: 14
debug:         o_minttl: 1          o_maxttl: 20        o_timeout: 10
debug:          o_debug: 1         o_numeric: 1          o_pktlen: 0 
debug:       o_nqueries: 3        o_dontfrag: 0             o_tos: 8 
debug:      o_forceport: 0             o_syn: 1             o_ack: 0 
debug:            o_ecn: 0        o_nofilter: 0 o_nogetinterfaces: 0 
debug:      o_trackport: 0      datalinkname: ETHERNET     device: WAN
debug:       o_noselect: 0            o_dnat: 0               isn: 1789831824
Selected device WAN, address 172.xxx.yyy.24, port 39969 for outgoing packets
debug: pcap filter is: 
		(tcp and src host 203.0.xxx.yyy and src port 80 and dst host 172.xxx.yyy.24)
		or ((icmp[0] == 11 or icmp[0] == 3) and dst host 172.xxx.yyy.24)
Tracing the path to 203.0.xxx.yyy on TCP port 80 (www), 20 hops max
debug: Generating a new batch of 512 IP ID's
debug: Sent probe 1 of 3 for hop 1, IP ID 28506, source port 39969, SYN 
debug: null pointer from pcap_next()
debug: received 68 byte IP packet from pcap_next()
debug: Received ICMP packet
debug: displayed hop
 1  debug: Not attempting to resolve RFC1918 address 172.17.xxx.yyy
172.17.xxx.yyydebug: Not attempting to resolve RFC1918 address 172.17.xxx.yyy
  0.217 ms

Hope this helps,

andreip