m-kozlowski

> So, by the 5second mark, board connects to the WiFi for the first time and immediately crashes after the very first nofuss HTTP request? Yup. That what it looks...

Good catch! There's no problem with [email protected]. Went back to [email protected] and the issue is back as well.

> Nofuss sets HTTP version to 1.0 Oh, didn't notice that. In that case response would be ``` < HTTP/1.1 200 OK < date: Mon, 21 Dec 2020 19:33:59 GMT...

[I think it is](https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html) Well, sort of, because gcc is the only compiller I've used that has it implemented;)

I'm suspecting that it's caused by UDP's lack of transmission control. Receiving replies for commands issued a while back gave me a hint. I've changed esp8266-proxy to [a esp-link](https://github.com/jeelabs/esp-link/), changed...

I think it's more about assuring correct datagram order than retransmission, but I'm still to lazy to disassemble my box, reprogram esp with esp8266-proxy firmware and capture network traffic;) IMHO...

``` root@nas:/usr/src/opendps# ./dpsctl/dpsctl.py -d 10.1.24.1 -q Warning: sent command 04, response was 0c. 00:22:10.379850 IP (tos 0x0, ttl 64, id 23997, offset 0, flags [DF], proto UDP (17), length 33)...

next: ``` root@nas:/usr/src/opendps# ./dpsctl/dpsctl.py -d 10.1.24.1 -q Error: protocol error (-2). root@nas:/usr/src/opendps# ./dpsctl/dpsctl.py -d 10.1.24.1 --ping Error: timeout talking to device 10.1.24.1. root@nas:/usr/src/opendps# ./dpsctl/dpsctl.py -d 10.1.24.1 --ping Error: protocol error...

Here are some of my observations: I have two mfc cards, one for workplace (A) and one for public transport (B) (A) is purely UID based, all sectors are filled...

As much as I would like you guys to succeed, I'm rather sceptical. I have no experience with unlocking overclocking, but i did remove whitelist from my t430 and t430s...