Imposto de Renda 2019 no Linux

Tentei instalar o programa de declaração de imposto de renda no Ubuntu 18.04 e tive alguns problemas:

$ chmod a+x IRPF2019Linux-x86_64v1.5.bin 
$ ./IRPF2019Linux-x86_64v1.5.bin 
/tmp/ijtmp_BAA7A551-D3D8-3B70-2DF2-FF72C5CFA51F/bin/xdg-open: 255: /tmp/ijtmp_BAA7A551-D3D8-3B70-2DF2-FF72C5CFA51F/bin/xdg-open: gnome-open: not found

Então instalei a libgnome2-bin para ver se resolvia o problema:

sudo apt install libgnome2-bin

Ao executar novamente notei que não havia instalado o Java 8 no meu computador, então segui estes passos para instalar:

How to Install JAVA 8 on Ubuntu 18.04/16.04, Linux Mint 19/18

Creio que o IRPF deveria ter uma forma mais inteligente de rodar no Linux, imagine uma pessoa leiga tentando instalar isso? Creio que este é um dos problemas que dificultaram o uso do Linux no Desktop.

Fake chip makes me nervous

I was trying to configure the Microchip/Atmel SAMD21 USART to work at 110BPS to use with an old ABNT CODI protocol.

I noticed that the Silabs CP2102 on Linux doesn’t support such low baudate:

$ sudo stty 110 cs8 -parenb -F /dev/ttyUSB0 
stty: /dev/ttyUSB0: unable to perform all requested operations

“Fortunately” I had a FTDI USB/Serial module that accepts this low baudrate. Then after spending many days trying to figure out why the communication at 110 BPS wasn’t working I decided to use the Logic Analyzer and discovered that the FTDI chip wasn’t generating the 110BPS.

Then I realized there are some FTDI fake chips that don’t work correctly at high speed. Now I can confirm they will not work correct at low speed either. Probably these fake chips use a microcontroller instead of a real IP for USB/Serial and they have loss of precision at low and high baudrates.

Then I decided to use two SAMD21 boards to test the communication, the first board will transmit at 110BPS and the second one will received the data at same baudrate. It worked fine.

Then I found a Prolific PL2303 USB/Serial dongle here and decided to test it. And to my surprise the PL2303 worked fine at 110 BPS and I could test it from computer to the board.

In the computer:

$ sudo stty 110 cs8 -parenb -F /dev/ttyUSB0
$ echo "Hello" > /dev/ttyUSB0

In the SAMD21 board:

nsh> dd if=/dev/ttyS0 of=/dev/console bs=1 count=10                             
Hello

So, never trust on your serial communication if you are using a USB/Serial from China.

Using a chinese ModBus temperature sensor

I’m testing this modbus SHT20 temperature and humidity sensor: https://www.aliexpress.com/item/SHT20-Temperature-Humidity-Sensor-Industrial-Grade-High-Precision-Temperature-Humidity-Transmitter-Monitoring-Sensor-Modbus-RS48/32923628973.html

There is not much information about this device at Aliexpress. Fortunately searching for the string XY-MD01 that was in the board returned this Russian web site: http://www.bizkit.ru/2018/11/14/5789/

It give a little more detail about the device. Also I found other website that used a different temperature sensor, but the modbus address and protocol is almost the same: https://techsparx.com/energy-system/modbus/linux-modbus-usb-rs485.html

The sample application worked correctly. All I did was to change the modbus_get_response_timeout() to include “&old_response_to_sec, &old_response_to_usec” as it was in the comments and changed the temperature division to: “(tab_rp_bits[0] / 10.0)”.

After some tests I got mbpoll working to read data as well:

$ sudo mbpoll -a 1 -b 9600 -r 2 -t 3 -P none /dev/ttyUSB0

It is nice as the Internet save our soul! I hope this post eventually help other people as well.

How to make VirtualBox to recognized USB Devices

By default VirtualBox on Ubuntu will not detect the USB Device. In order to get it working you need to install the Oracle Extended Package and add add your user to vboxusers group.

You can do it running these two commands:

$ sudo apt install virtualbox-ext-pack
$ sudo usermod -a -G vboxusers $USER

After doing it, please restart your computer (just doing logoff worked for me).

ImageMagick not authorized error

I was getting this error:

$ convert -density 150×150 +antialias -negate FILE1.PDF F1.png
convert-im6.q16: not authorized FILE1.PDF’ @ error/constitute.c/ReadImage/412. convert-im6.q16: no images defined F1.png’ @ error/convert.c/ConvertImageCommand/3258.

I found the solution here: https://stackoverflow.com/questions/52861946/imagemagick-not-authorized-to-convert-pdf-to-an-image/52863413#52863413

/etc/ImageMagick-6/policy.xml

policy domain=”coder” rights=”read|write” pattern=”PS”
policy domain=”coder” rights=”read|write” pattern=”EPI”
policy domain=”coder” rights=”read|write” pattern=”PDF”
policy domain=”coder” rights=”read|write” pattern=”XPS”

Accessing Internet from NuttX PPP Connection

As you know I was facing some issues to get PPPD connection working:

https://acassis.wordpress.com/2019/02/10/debugging-pppd-using-quectel-m95-on-samd21-board/

Then I received a comment from Vladimir Novikov (thank you!) at that post commenting the issues was introduced some time ago at this commit:

https://bitbucket.org/nuttx/apps/commits/cddfda99f0a519681b894b7a12560406c4372cfb

And he suggested me adding this line to lcp.c:

          tptr = bptr;
+          bptr += 4;
          error = 0;

Before testing this suggestion I received an email from Quectel Brasil support (thanks Micael Lisboa) suggesting run this AT cmd:

AT+QACCM=0,0

Micael’s suggestion worked fine.

But I decided to contact the author of the modification (Xiao Xiang) and he explained that the bptr was already increased by 4 compared to original code. And in fact he was correct.

Anyway I decided to test Vladimir’s suggestion that also worked. So we need to investigate it in more details to understand what is happening.

BTW since the AT command was working for me I decided to follow with my tests.

After PPPD connection was established it was getting IP:

nsh> ifconfig
ppp0    Link encap:TUN at UP
        inet addr:100.75.210.38 DRaddr:192.168.254.254 Mask:0.0.0.0

But ping command was crashing:

nsh> ping 8.8.8.8

PINGup_assert: Assertion failed at file:armv6-m/up_hardfault.c line: 139
up_registerdump: R0: 20000a78 00000000 00000000 00004a64 20000819
20006f8c 20000a78 00000000
up_registerdump: R8: 00000000 00000000 00000000 00000000 20000414
20003fa0 0000b54f 00009dd6
up_registerdump: xPSR: 21000000 PRIMASK: 00000000
up_dumpstate: sp:         20003ee8
up_dumpstate: stack base: 20004040
up_dumpstate: stack size: 000007e4
up_stackdump: 20003ee0: 2000385c 000009c5 00000000 00000000 00000000
20000414 20003fa0 0000b54f
up_stackdump: 20003f00: 00009dd6 00000000 00013437 00000000 00000000
00000000 20000000 00000018
up_stackdump: 20003f20: 00000003 20003f58 00000000 00000c03 00000018
000010e3 20001e5c 00000ab9
up_stackdump: 20003f40: 00000000 00000000 00000000 20000a78 00000000
000002ab 20003fa0 00000000
up_stackdump: 20003f60: 20000819 20006f8c 20000a78 00000000 00000000
00000000 00000000 00000000
up_stackdump: 20003f80: 20000a78 00000000 00000000 00004a64 20000414
0000b54f 00009dd6 21000000
up_stackdump: 20003fa0: 20000a78 00004000 20006f8c 00004000 2000077c
00009d5d 00000000 0000b54f
up_stackdump: 20003fc0: 00000000 20000a78 00004000 00000000 20000a78
0000fd1d 20001f2c 0000b7f1
up_stackdump: 20003fe0: 00000000 0000b34b 200007f0 20000a74 00000000
0000ff3f 200007f8 00001ee9
up_stackdump: 20004000: 00000000 00001bcf ffffffff 00000000 20001de8
00020000 00000000 00000101
up_stackdump: 20004020: 00000000 00000000 00000000 0000144b 00000101
0000140f 00000000 00000000

After much debugging and with Greg’s help I noticed the “srcipaddr” was not aligned:

(gdb)
194       net_ipv4addr_hdrcopy(ipv4->srcipaddr, &dev->d_ipaddr);
(gdb) p &ipv4->srcipaddr
$1 = (uint16_t (*)[2]) 0x20000c41 
(gdb) p &dev->d_ipaddr
$2 = (in_addr_t *) 0x20000eac

See, it was at 0x20000c41 that is an odd address position.

Almost instantly Greg found the source of this issue: it was the TUN/TAP driver that was defining the read_buf at odd position:

 142   bool              read_wait;
 143
 144   uint8_t           read_buf[CONFIG_NET_TUN_PKTSIZE];
 145   size_t            read_d_len;
 146   uint8_t           write_buf[CONFIG_NET_TUN_PKTSIZE];

Moving the “size_t read_d_len;” to the line above read_buf[] fixed the issue!

Now ping is not crashing and I was able to ping the Google’s DNS 8.8.8.8:

nsh> ping 8.8.8.8
PING 8.8.8.8 56 bytes of data
56 bytes from 8.8.8.8: icmp_seq=0 time=1010 ms
56 bytes from 8.8.8.8: icmp_seq=2 time=1260 ms
56 bytes from 8.8.8.8: icmp_seq=2 time=370 ms
56 bytes from 8.8.8.8: icmp_seq=4 time=1080 ms
56 bytes from 8.8.8.8: icmp_seq=4 time=490 ms
56 bytes from 8.8.8.8: icmp_seq=5 time=870 ms
56 bytes from 8.8.8.8: icmp_seq=6 time=560 ms
56 bytes from 8.8.8.8: icmp_seq=7 time=930 ms
56 bytes from 8.8.8.8: icmp_seq=8 time=640 ms
56 bytes from 8.8.8.8: icmp_seq=9 time=1010 ms
10 packets transmitted, 10 received, 0% packet loss, time 10100 ms