Milyen gyári kódra gondolsz? Van erre minta? Ott hasal el, amikor le kellene tölteni Error 301, Error 404, vagy Error-1 a válasz. Nekem úgy tűnik - el sem jut oda, hogy lehessen bárhová letölteni. Ha van valakinek olyan mintakód részlete, ami segíthet és működik - érdekelne.

Ennyire szófukar leírásokkal nehéz mit kezdeni - először neked kell dolgoznod, hogy egyértelmű legyen, mi a helyzet és mit akarsz, de nagyjából el tudom képzelni: kliensként el szeretnél érni resource-okat a firmware-ből az Interneten nyilván egy kicsit módosított programkóddal, amibe tesztfüggvények kerültek vagy a gyári kódot teszteled, és mindez nem úgy működik, ahogy szeretnéd.

A 404-es valóban azt jelenti, hogy nem érte el az eszköz az adott oldalt, de a TLS-nek ehhez még nincs köze; az adott oldal vagy fájl vagy akármilyen erőforrás ebben az esetben tényleg nem található, amit el szeretnél érni.

A 301-es viszont olyan értelemben nem hibaüzenet, hogy a szerver tudja, hol az adott erőforrás, csak egy átirányítás szükséges hozzá, mert nem a kért címen van. Ez azt jelenti, hogy ha ezt nem tette meg "magától" a meghívott függvény, akkor a 301-es válaszban kapott URL-lel neked kell egy új kérést csinálnod, és akkor már megkapod a kívánt erőforrást (fájlt, akármit). Ez akár biztatónak is mondható.

HTTP 1-es hiba nem létezik, az az adott szoftvertől jövő valamilyen saját hibaüzenet lehet, vagy pedig HTTP 1xx, három számjegyű üzenet volt - bár ez sem valószínű, mert a 100-asok folyamatban levő kérések státuszai, és szerintem egy "normál" lekéréssel, a szokásos kliens oldali függvényekkel olyat nem kaphatsz. De nem vagyok biztos benne, eddig csak szervert írtam ESP-re. : -) VIszont ha az alap fejlesztőrendszer függvénye, API-ja van használva a lekéréshez, akkor ezt a doksiban könnyű megtalálni (hogy milyen visszatérési értékei lehetnek az adott függvénynek).

Nem 1-es, hanem "-1" hibaüzenetet kaptam, ami a chatgpt szerint létező hibakód. Van egy mintakódom, ebből talán jobban látszik a szándék:

Rájöttem, csak emiatt már nem akartam újra írni. Mindenesetre nem segít, mert az egy általános hibaüzenet, úgyhogy "pont ezt" nem jelenti, csak ilyen is történhet..

Mi lett azzal, amit a 301-es hibára válaszoltam, nem segített? És melyik hiba mikor jön elő? Csak ideraktad a kódot.

Mellesleg megnéztem ezt a linket, és lehet, hogy korábban volt ilyen fájl, de most biztosan nincs - miközben a favicon meg elérhető ugyanott. Https-sel is ugyanez az eredmény.

Az IP Info szerint valahol Angliában van.

ESP programvédelem – röviden

ESP8266/ESP32 esetén van lehetőség a program kiolvasásának megnehezítésére, de
nem 100%-os a védelem. Az ESP32-ben hardveresen elérhető a
Flash Encryption és Secure Boot funkció – ezzel a program titkosítva kerül a flash-be,
és csak az adott chip képes futtatni. ESP8266-nál nincs teljes hardveres titkosítás,
ott csak firmware titkosítás + OTA jelszavas frissítés használható.
A védelem bekapcsolása után a soros kiolvasás és SPI-flash dump értelmetlen lesz,
de fizikai támadás ellen nem véd.

Részletes leírás:
• ESP32 Flash Encryption dokumentáció
• ESP8266 Secure OTA leírás


Tipp: Olyan chipre fejlessz, ami a tokozaton belül van a flash!

Erről a linkről indultam: Eredeti link amiről PC-re lejött a fájl, de esp-re az említett hibákat kaptam.

IP-címmel hivatkozni valamire nem ugyanaz, mint domain-névvel - sok esetben nem működik, ahogy most sem. Nem próbáltad ki azt az URL-t, amit a kódba raktál vagy raktak.

Esetleg nem működnek az eszközön a DNS-lekérdezések, azért került oda IP-cím? Mindenesetre az eredeti URI-t kellene használni, amire az előbb is hivatkoztál, ez nálam is működik.

Leírtam... Több módon próbáltam nem csak IP címmel - ami akkor egyébként böngészőből még működött. hanem a linken szereplő https, http protokollokkal. Azaz nameserverrel és nélküle, de mindegyik alkalommal a mikrokontrolleres próbálkozásnál az említett hibákat kaptam, ami úgy tűnik a https miatt van és nincs tanúsítvány. De mivel látom a kérdést sem értik sokan, küzdök tovább, hgy egy egyszerű zipet ebben a nagy IT káoszban hogyan tudjak letölteni egy célhardverre, https protokollal, ha már az ftp-t is kinyírták.

Nekem az benne a furmány (mert én is nézegettem), hogy maga szerver elvileg nem (sem IP címmel, sem DNS-el) érhető el, de maga a fájl pedig letöltődik, és ránézésre teljesen ép.

Belenézve is, bár ugye binárisról a fene mondja meg...

Leírtam, hogy http-vel is elérhető az oldal, tehát semmi köze a cert-ekhez.

Miután megmutattad a domain nevét, leírtam, hogy most is működik, csak nem IP-címmel.

Azt is leírtam korábban, még látatlanban, hogy 301-es átirányítás lehetséges a letöltés során, amit lehet, hogy neked kell kezelned. Ezt nem igazán érted, hogy mit jelent és nem is nézel utána.

Mindenesetre most, hogy a részletek összeálltak, be is bizonyosodott, mivel tökéletesen látszik a böngészőben, hogy mi történik letöltéskor - lásd a képet. Ez egy szokásos megoldás, mikor www-vel nyitsz meg egy weblapot és az rögtön átirányít a saját www nélküli címére.

Próbáld ki így, és működni fog: http://worldofspectrum.org//pub/sinclair/games/m/ManicMiner.tzx.zip

Még a dupla perjelet esetleg ki lehet venni a .org és a pub közül, bár a szerver láthatóan kezelni tudja, mindenesetre felesleges.

Probáltál valahogy* TCP dump-ot készíteni a forgalomról?
Wireshark-ba betöltve látni lehetne mi is folyik a vonalon.

* Anno én az ENC28j60-s fejlesztésnél egy buta hub-bal oldottam meg, hogy a PC is megkapja az összes csomagot, ami az ENC küldött és fogadott, és így tudtam rögzíteni, de manapság biztosan vannak szofisztikáltam megoldások. Pl. egy router ami támogatja a dump mentést, vagy linux alapu és ssh-n be lehet rá jelentkezni, stb.

Teljesen felesleges, az átirányítás a probléma és a megoldás kulcsa. Az első kérdéseiben írta, most is ott áll, hogy olyan visszatérési értéket is kapott, hogy 301, vagyis minden működik nála, ami a kommunikációt illeti.

Csak valószínűleg a www nélküli változatra nem gondolt vagy elfelejtette kipróbálni, a 301-et meg ugyanolyan hibának vette, mintha nem lehetne elérni az adott resource-ot.

Olyat mondani, hogy “kipróbáltam és nem jó”, az semmi, nem információ, csak a tévedésekhez alkalmas. A próbálkozásokat fegyelmezetten dokumentálni kell, melyik sorban milyen szöveggel milyen visszatérési érték jött, különben pillanatok alatt át lehet ugrani dolgokat. De nem írtam volna ezt, ha nem nevez értetlennek. : -)

Még egy plusz infó, ha ez az a framework, rákerestem, valamint segítség, hogy ne nekem kelljen leírni:

https://avantmaker.com/references/esp32-arduino-core-index/esp32-ht...rects/

a 301-hez mondjuk tényleg nem kell, a -1 -re irtam.

Más: kiderült, hogy az S3-asból annak idején 1.0-ás hardverváltozatút sikerült vásárolnom, kettőt is. Azokon a chip 48-as lábára volt kötve a WS2812B RGB LED, ami, ahogy később rájöttek, zavarta az SPI memóriákkal való kapcsolatot, így áttették a 38-asra.

Ezt kellett utólag megvalósítani. Szerencsére tettek a LED adatlába elé egy nulla ohmos ellenállást, persze 0402-est - ezt kiforrasztottam (visszafelé nem biztos, hogy vállalnám), és a LED-et vékony vezetékkel rákötöttem a tüskesoron megtalálható 38-as lábra.

A vezetéket nem rögzítettem - tartva a magasságot középtájt meg kellene pöttyinteni egy kis melegragasztóval -, mert úgyis külső LED lesz majd használva. Természetesen működik, nincs vele gond. : -)

Jut eszembe, ezek a LED-ek eleve specifikáción kívül vannak használva, ami meglepett: ez a WS2812B-mini (3,5 x 3,5 mm) elvileg 3,7 V-tól felfelé működik, az 5050-es változat pedig 3,5 V-tól. : -) A mini V2-es változata is, sőt van még egy 2020-as, még kisebb kivitelű, és az is.

Kipróbáltam a linket. Böngészőből (firefox) lejön, a célhardver (ESP) nem tölti le. Hibát dob. Pedig kap IP-t kap netet.

A link . Eredmény http hiba: 301. PC firefox meg letölti.

Mi akadályoz abban, hogy feltöltsd egy olyan tárhelyre ezt a fájlt, ahonnan az esp -vel letudod húzni?

Ha 301-es hibát kapsz, akkor írasd ki, hogy mi jön vissza a válasz fejlécében ("Location"), és azt az URL-t próbáld letölteni - az előző képen van a segítség. Vagy használd a http.setFollowRedirects()-et, ha működik.

A böngészőben is megnézheted a Network fülön, ahogy én is tettem, hogy a böngésződ végül is hol találja meg a fájlt, az sem érdektelen.

Az org és a pub között miért van 2 perjel?

Idézném magamat: "Még a dupla perjelet esetleg ki lehet venni a .org és a pub közül, bár a szerver láthatóan kezelni tudja" Vagyis az adott szerveren semmit sem változtat, hogy egy vagy kettő van ott, ki lett próbálva. Én még nem is láttam olyat, hogy ne lett volna figyelmen kívül hagyva a duplázás, bár ez mérsékelten bizonyító erejű. : -)

Nem hinném, hogy egy ekkora oldalon lenne terheléselosztás, ami miatt különböző szerverekkel esetleg másként viselkedhetne egy kérés, de még bármi kiderülhet.

Már reszelem jobbról, balról, de az alap probléma nem a per jelekkel van, vagy szintaktikai dolgokkal. A probléma az, hogy ahogyan változtatják a szabványokat egyre használhatatlanabb és lassabb lesz a hozzáférés egy user, vagy eszköz számára, a hackerek meg azt csinálnak, amit akarnak. megszüntették az ftp támogatását, de ha egy publikus ftp-ről akarnék leszedni adatot, akkor már nem is működik az, ami nemrég, gond nélkül ment. Ha http - azt nem támogatják, a https-hez meg tanúsítvány kell. Beáldoztam nem kevés memóriát a tanúsítványhoz, így legalább már az oldalak nem rúgnak ki, csak éppen kiválasztani nem tudom egyszerűen az általam letölteni kívánt fájlt. Igen - régebben én is vétettem olyan pont hibát, hogy egy napig kellett keresgélnem, mire meglett. De itt sajnos "Az új jobb!" szellemeivel kell megküzdenem, ha kifogástalanra akarom megírni a szoftvert. Az sem mindegy, milyen platformon. Arduino ide alól belefutottam 100 hibába, amihez - mint kiderül egyetlen kapcsolót kellett volna átkapcsolni az ide felületen. Ebben is próbálkozom, de mellékvágányként minipythonból is készítettem szoftvert, ami meg működött fél órán belül. Azaz nem a linkekkell, vagy a beállításokkal küzdök, hanem a hülye, túlspirált szabványokkal, amik a C-t egyre kevésbé kultiválják. Attól félek így- ha elkészül és működik is - jön egy újabb szabvány és mehet a kukába. Sebaj, született 3 új szabadalmam, hogy ne kelljen a sok hülye multira támaszkodni. Előbb-utóbb csak változik jó irányba is valami. Egy Senior soha nem adja fel!

A kihívás... Meg is lett az eredménye. 4 órám ráment, de kiderült, hogy a tanúsítvány csak akkor tud jó lenni, ha time szerverrel is hitelesített idő van hozzá. Egye meg a radai rosseb...

Reszeled, vagyis csinálsz valamit, de nem a válaszokkal jössz, nincs párbeszéd, hanem másról kezdesz írni. Én csak az eredeti probléma megoldásában tudnék segíteni, de azt szerintem te nem akarod. Megfelelő rugalmassággal (próba, elemzés, javítás, próba, elemzés, javítás) pár perc alatt a végére lehetne jutni ilyesminek. de erre a folytatásos történetre nekem nincs időm, nem is erre vállalkoztam. Mi ez az egész?

És milyen https-ről van szó már megint? Leírom, utoljára, hogy kipróbáltam, hogy http-vel is működik az a szerver, vagyis a problémának semmi köze a tanúsítványokhoz. Abba ne is menjünk bele, hogy egy kliensnek amúgy sincs szüksége tanúsítványra, csak a man-in-the-middle támadások kivédéséhez kell, aminek ilyen esetben szinte semmi jelentősége. A tanúsítványok ellenőrzése kikapcsolható, az átvitel anélkül is titkosított lesz. Az ESP32 esetében pl. az sdkconfig-ban engedélyezni kell a "Skip server certificate verification by default"-ot, és akkor ez is le van tudva, bár az Arduino Core-ban lehet, hogy másként megy, meg kell keresni, esetleg programozottan is kikapcsolható, nem kell a config,

És be is bizonyítottam, hogy a fájl letölthető, elmondtam, hogy mi a 301-es válasz, és több módszert is mutattam rá, hogy hogyan megszerezni a keresett resource-ot. Mintha a falnak beszélnék. A legegyszerűbb konkrétan kiíratni a konzolra a 301-es response headerjének megfelelő mezőjét, a "Location"-t, ha jól emlékszem - lejjebb megvan -, mert nálad valamiért nem ugyanaz, mint nálam, vagy valami tévedés történt a próbák közben. Erre én is kíváncsi lennék, ez lett volna a jutalmam a segítségért, de ebből semmi sem lesz.

Egyébként korábban szándékosan nem reagáltam rá, de miután újra és újra visszatérsz ehhez: értelmetlenek az ilyen kirohanások ismeretek nélkül.

Az FTP-t egyrészt azért cserélték le a legtöbb helyen, mert nem biztonságos protokoll - ránézésre, ugye, ez nem derül ki, de attól még tény. Minden nyíltan megy át a hálózaton a jelszóval kezdve, és menet közben nyitogat portokat, így még a terheléselosztás is macerás vele nagyobb helyeken. _Nem illik bele_ a HTTP/HTTPS protokollra épülő rendszerekbe, amik a háttérben szintén nagyon összetettek is lehetnek, ha egy egyedi szervernél nem is látszik - és a böngészők profiljába sem illik bele, mert bonyolultabb a HTTP/HTTPS protokollal való letöltésnél, valamint más felhasználói felületet kíván.

Ennek ellenére sok helyen ott van még; pl. tárhelyszolgáltatóknál én is mindig elértem FTP-vel a tárhelyemet, de az egy közvetlen, névre szóló kapcsolat egy szolgáltató és egy felhasználó között. Sőt FTPS is létezik, ami egy FTP + TLS, vagyis ugyanúgy TLS-sel van titkosítva, mint a HTTPS, Windows-alapú tárhelyeken szokták használni (a 990-es port a defaultja), de az sem old meg minden problémát.

Szóval publikus letöltésre tökéletesen megfelel a webes fájlletöltés - a változtatásoknak ezekben a világot működtető, alapvető technológiákban meg szoktak lenni a gyakorlati okai, többnyire nem a divat vezérli őket és nem "a multik" találják ki. És még jelszavakat is be lehet állítani a webes fájlletöltésekhez egy webszerver (host) konfigurációjában, lásd: a basic és digest authentication-ök. Elfogadhatóan biztonságosak, mivel HTTPS esetén már védett csatornán közlekednek a jelszavak. Az előzőt nagyon könnyű, az utóbbit szoftveresen kicsit nehezebb használni, hirtelen az IP-kamerák jutnak eszembe, amiknél gyakran találkozni lehet ezzel a beállítással.

Fájlcserére a modern megoldás az SFTP - ma már sokszor ezt értik "FTP" alatt -, ami az SSH kapcsolatnak, minden távoli elérés alapjának egy bővítménye. Az SSH egy kiválóan dokumentált és jól használható technológia, ami nemcsak shell-elérésre való, vagyis távoli terminálnak, hanem porttovábbításra (rendkívül egyszerűen, néhány paraméter megadásával a kliens oldalon is), fájlcserére stb., és ott van minden Linux szerveren.

Az SSH biztonsági megoldásai annyiban másabbak, hogy nem a tanúsítvány-kiadókra támaszkodik, hanem a szerverek megadják neked a lehetőséget, hogy elfogadd a publikus kulcsukat. Persze hiába sorolom ezeket, ki kell próbálni és tanulni ezekről, hogy összeálljon a kép. És mindez az összetettség nem jelenti, hogy annyival lassabb lesz maga az adatátvitel, aminek számtalan oka van, tudnám sorolni.

Az SSH-nak sokféle konfigurációja van, ami a hitelesítést illeti, például jelszó helyett bejelentkezhetsz tanúsítvánnyal is stb. Megértéséhez ismerni kell többek közt az aszimmetrikus titkosítás módszerét, a publikus és privát kulcsok használatát (abszolút alapvető manapság), egy kicsit az ezt következő szimmetrikus kulcscseréket és a kulcsok védelmének módszereit is, ill. hogy miért van szükség mind a két módszerre (sebesség, egyebek).

Az ESP32-n az mbedTLS és az lwIP remekül és elég könnyen használható, és megvannak hozzájuk az alapvető példaprogramok, semmi extrát sem kell tudni-csinálni hozzájuk. Ami a lassúságot illeti, az ESP32 meglepően sok TLS-re épülő kapcsolatot elvisz egyszerre gond nélkül. Persze ha van elég memóriája, de ez újabban nem gond.

Ami a szabványokat illeti, a biztonság és gyakran a használhatóság szempontjából is a legrosszabb, amit tehetsz, hogy saját eljárásokat találsz ki - már ha arról van szó, mert simán leírtál több száz szót konkrétumok nélkül.

Válaszokat nem kaptam, csak nagyívű kioktatást. Lassan ezért nem is fórumozok. Leírtam pontosan, hogy mi a célom és ehhez kerestem megoldást, bármilyet. Akár mintakódot, amivel el lehet indulni. De az nem segítség, ha lenézed a másikat. Nem varázsszavakra van szükségem, meg rövidítésekre. 88 óta programozok vagy 100 nyelven, csak ezt a mikrokontrollert nem ismerem. Nem Linux szervert akarok használni, nem repülőgép anyahajót szeretnék készíteni, csak egy nyamvadt zip fájlt letölteni és kicsomagolni. Szerintem a kód elég konkrétum volt. Részemről itt a vége.

Egészségedre.