Hæ allir
Við, Viktor Antipov og Ilya Aleshin, munum í dag tala um reynslu okkar af því að vinna með USB tæki í gegnum Python PyUSB og aðeins um öfuga verkfræði.
Forsaga
Árið 2019, tilskipun ríkisstjórnar Rússlands nr. 224 „Um samþykki reglna um merkingu tóbaksvara með auðkenningarbúnaði og eiginleika innleiðingar ríkisupplýsingakerfis til að fylgjast með dreifingu vara sem eru háðar lögboðnum merkingum með auðkenningarbúnaði. í tengslum við tóbaksvörur“ tóku gildi.
Skjalið útskýrir að frá og með 1. júlí 2019 er framleiðendum skylt að merkja hverja tóbakspakka. Og beinir dreifingaraðilar verða að fá þessar vörur með framkvæmd alhliða flutningsskjals (UDD). Verslanir þurfa aftur á móti að skrá sölu á merktum vörum í gegnum afgreiðslukassann.
Einnig, frá 1. júlí 2020, er dreifing ómerktra tóbaksvara bönnuð. Þetta þýðir að allir sígarettupakkar verða að vera merktir með sérstöku Datamatrix strikamerki. Þar að auki - mikilvægt atriði - það kom í ljós að Datamatrix verður ekki venjulegt, heldur öfugt. Það er, ekki svartur kóði á hvítu, heldur öfugt.
Við prófuðum skannana okkar og það kom í ljós að flesta þeirra þarf að endurnýja/endurþjálfa, annars geta þeir einfaldlega ekki unnið eðlilega með þetta strikamerki. Þessi atburðarás tryggði okkur mikinn höfuðverk, því fyrirtækið okkar hefur mikið af verslunum sem eru á víð og dreif um stórt landsvæði. Nokkrir tugir þúsunda peningakassa – og mjög lítill tími.
Hvað átti að gera? Það eru tveir valkostir. Í fyrsta lagi: Verkfræðingar á staðnum endurnýja og stilla skannana handvirkt. Í öðru lagi: við vinnum fjarstýrt og, helst, náum yfir marga skanna í einu í einni endurtekningu.
Fyrsti kosturinn var augljóslega ekki hentugur fyrir okkur: við þyrftum að eyða peningum í heimsóknir til verkfræðinga og í þessu tilfelli væri erfitt að stjórna og samræma ferlið. En það sem skiptir mestu máli er að fólk myndi vinna, það er að við myndum hugsanlega fá margar villur og líklegast ekki standast frestinn.
Annar kosturinn er góður fyrir alla, ef ekki fyrir eitt. Sumir söluaðilar voru ekki með fjarblikkandi verkfærin sem við þurftum fyrir öll nauðsynleg stýrikerfi. Og þar sem frestarnir voru að renna út varð ég að hugsa með eigin höfði.
Næst munum við segja þér hvernig við þróuðum verkfæri fyrir handskannara fyrir Debian 9.x OS (allar sjóðsvélar okkar eru á Debian).
Leysið gátuna: hvernig á að blikka skanna
Victor Antipov greinir frá.
Opinbera tólið sem seljandinn veitir virkar undir Windows og aðeins með IE. Tækið getur blikkað og stillt skannann.
Þar sem markkerfið okkar er Debian, settum við upp usb-redirector miðlara á Debian og usb-redirector biðlara á Windows. Með því að nota usb-redirector tól, sendum við skannann frá Linux vél til Windows vél.
Tól frá Windows söluaðila sá skannann og blikkaði hann jafnvel venjulega. Þannig komumst við að fyrstu niðurstöðunni: ekkert veltur á stýrikerfinu, þetta er spurning um blikkandi samskiptareglur.
Allt í lagi. Við keyrðum blikkið á Windows vélinni og fjarlægðum sorpið á Linux vélinni.
Við tróðum sorpinu inn í WireShark og ... urðum sorgmædd (ég mun sleppa nokkrum smáatriðum um sorphauginn, þær hafa ekki áhuga).
Það sem sorphaugurinn sýndi okkur:
Heimilisföng 0000-0030, af Wireshark að dæma, eru USB þjónustuupplýsingar.
Við höfðum áhuga á hluta 0040-0070.
Ekkert var ljóst frá einum sendingarramma nema MOCFT-stafirnir. Þessir stafir reyndust vera stafir úr fastbúnaðarskránni, sem og stafir sem eftir eru til loka rammans (fastbúnaðarskráin er auðkennd):
Hvað táknin fd 3e 02 01 fe þýddu hafði ég persónulega, eins og Ilya, ekki hugmynd um.
Ég skoðaði eftirfarandi ramma (þjónustuupplýsingar hafa verið fjarlægðar hér, fastbúnaðarskráin hefur verið auðkennd):
Hvað varð ljóst? Að fyrstu tvö bætin séu einhvers konar fasti. Allar síðari blokkir staðfestu þetta, en fyrir lok sendingarblokkarinnar:
Þessi rammi var líka heimskulegur, þar sem fastinn hafði breyst (auðkenndur) og einkennilegt nokk var hluti af skránni. Stærð yfirfærðra bæta skráarinnar sýndi að 1024 bæti voru flutt. Ég vissi aftur ekki hvað bætin sem eftir voru þýddu.
Fyrst af öllu, sem gamalt BBS gælunafn, fór ég yfir staðlaðar sendingarreglur. Engin samskiptaregla send 1024 bæti. Ég byrjaði að rannsaka vélbúnaðinn og rakst á 1K Xmodem samskiptareglur. Það leyfði að senda 1024, en með fyrirvara: fyrst aðeins 128, og aðeins ef engar villur voru, jók samskiptareglan fjölda bæta sem send voru. Ég hafði strax flutning upp á 1024 bæti. Ég ákvað að rannsaka sendingarreglur, og sérstaklega X-mótaldið.
Það voru tvö afbrigði af mótaldinu.
Í fyrsta lagi XMODEM pakkasniðið með CRC8 stuðningi (upprunalega XMODEM):
Í öðru lagi, XMODEM pakkasniðið með CRC16 stuðningi (XmodemCRC):
Það lítur svipað út, nema SOH, pakkanúmer og CRC og pakkalengd.
Ég horfði á byrjun seinni sendingarblokkarinnar (og sá aftur fastbúnaðarskrána, en þegar inndregin með 1024 bætum):
Ég sá kunnuglega hausinn fd 3e 02, en næstu tvö bæti höfðu þegar breyst: það var 01 fe, og varð 02 fd. Þá tók ég eftir því að annar kubburinn var nú númeraður 02 og skildi þannig: fyrir framan mig var númerið á sendireitnum. Fyrsti 1024 gírinn er 01, sá seinni er 02, sá þriðji er 03 og svo framvegis (en auðvitað í hex). En hvað þýðir breytingin frá fe í fd? Augun sáu minnkun um 1, heilinn minnti á að forritarar telja frá 0, ekki 1. En hvers vegna er þá fyrsti reiturinn 1, en ekki 0? Ég hef ekki enn fundið svarið við þessari spurningu. En ég skildi hvernig seinni blokkin er talin. Annar kubburinn er ekkert annað en FF – (mínus) númer fyrsta kubbsins. Þannig var annar reiturinn merktur sem = 02 (FF-02) = 02 FD. Síðari lestur á sorphaugnum staðfesti ágiskun mína.
Þá fór eftirfarandi mynd af sendingunni að koma fram:
Upphaf sendingar
fd 3e 02 – Byrja
01 FE – sendingarteljari
Flutningur (34 blokkir, 1024 bæti flutt)
fd 3e 1024 bæti af gögnum (skipt í 30 bæta blokkir).
Lok sendingar
fd 25
Eftirstandandi gögn á að samræma við 1024 bæti.
Hvernig lítur endarammi blokkarútsendingarinnar út:
fd 25 - merki til að loka sendingum á blokk. Næsta 2f 52 - restin af skránni allt að 1024 bæti að stærð. 2f 52, af samskiptareglunni að dæma, er 16 bita CRC eftirlitsumma.
Fyrir gamla tíma, bjó ég til forrit í C sem tók 1024 bæti úr skrá og reiknaði út 16 bita CRC. Að ræsa forritið sýndi að þetta er ekki 16-bita CRC. Stupor aftur - í um þrjá daga. Allan þennan tíma var ég að reyna að skilja hvað það gæti verið, ef ekki tékksumma. Þegar ég var að rannsaka síður á ensku komst ég að því að X-mótaldið notar sinn eigin eftirlitssummuútreikning - CRC-CCITT (XModem). Ég fann engar C útfærslur á þessum útreikningi, en ég fann síðu sem reiknaði þessa tékksummu á netinu. Eftir að hafa flutt 1024 bæti af skránni minni yfir á vefsíðuna sýndi vefsíðan mér tékksummu sem passaði algjörlega við eftirlitssumman úr skránni.
Húrra! Síðasta gátan var leyst, nú þurfti ég að búa til minn eigin vélbúnað. Því næst miðlaði ég þekkingu minni (og hún var aðeins í hausnum á mér) til Ilya, sem þekkir öfluga verkfærakistuna Python.
Að búa til forrit
Ilya Aleshin greinir frá.
Eftir að hafa fengið viðeigandi leiðbeiningar var ég mjög „ánægður“.
Hvar á að byrja? Það er rétt, frá upphafi. Frá því að taka sorp úr USB tenginu.
Ræstu USB-pcap
Veldu tengið sem tækið er tengt við og skrána þar sem við munum vista sorphauginn.
Við tengjum skannann við vél þar sem innfæddur EZConfigScanning hugbúnaður fyrir Windows er settur upp.
Í því finnum við hlutinn til að senda skipanir í tækið. En hvað með liðin? Hvar get ég fengið þær?
Þegar forritið byrjar er búnaðurinn spurður sjálfkrafa (við sjáum þetta aðeins síðar). Og það voru þjálfun strikamerki úr opinberum búnaðarskjölum. DEFALT. Þetta er liðið okkar.
Nauðsynleg gögn hafa borist. Opnaðu dump.pcap í gegnum wireshark.
Lokaðu þegar EZConfigScanning er ræst. Staðir sem þú þarft að fylgjast með eru merktir með rauðu.
Þegar ég sá þetta allt í fyrsta skipti missti ég hjartað. Ekki er ljóst hvar á að grafa næst.
Smá hugarflug og-og-og... Aha! Í sorphaugnum út - Er inOg in это út.
Ég googlaði hvað URB_INTERRUPT er. Ég komst að því að þetta er gagnaflutningsaðferð. Og það eru 4 slíkar aðferðir: stjórna, trufla, jafnhraða, magn. Þú getur lesið um þá sérstaklega.
Og endapunktsföngin í USB-viðmótinu er hægt að fá annað hvort með „lsusb –v“ skipuninni eða með því að nota pyusb.
Nú þurfum við að finna öll tæki með þessu VID. Þú getur leitað sérstaklega eftir VID:PID.
Það lítur svona út:
Þannig að við höfum nauðsynlegar upplýsingar: P_INFO skipanirnar. eða DEFALT, fjallar um hvar á að skrifa skipanir endpoint=03 og hvar á að fá svarendapunkt=86. Það eina sem er eftir er að breyta skipunum í hex.
Þar sem við höfum þegar fundið tækið, skulum við aftengja það frá kjarnanum...
...og skrifaðu á endapunktinn með heimilisfanginu 0x03,
... og lestu síðan svarið frá endapunktinum með heimilisfanginu 0x86.
Skipulagt svar:
P_INFOfmt: 1
mode: app
app-present: 1
boot-present: 1
hw-sn: 18072B44CA
hw-rev: 0x20
cbl: 4
app-sw-rev: CP000116BBA
boot-sw-rev: CP000014BAD
flash: 3
app-m_name: Voyager 1450g
boot-m_name: Voyager 1450g
app-p_name: 1450g
boot-p_name: 1450g
boot-time: 16:56:02
boot-date: Oct 16 2014
app-time: 08:49:30
app-date: Mar 25 2019
app-compat: 289
boot-compat: 288
csum: 0x6986Við sjáum þessi gögn í dump.pcap.
Frábært! Umbreyttu strikamerki kerfisins í hex. Það er það, þjálfunarvirknin er tilbúin.
Hvað með fastbúnaðinn? Allt virðist vera eins, en það er blæbrigði.
Eftir að hafa tekið algjörlega upp á blikkferlinu skildum við nokkurn veginn hvað við vorum að fást við. Hér er grein um XMODEM, sem var mjög gagnleg til að skilja hvernig þessi samskipti eiga sér stað, þó almennt séð: Ég mæli með því að lesa hana.
Þegar þú horfir á sorphauginn geturðu séð að rammastærðin er 1024 og URB-gagnastærðin er 64.
Þess vegna - 1024/64 – við fáum 16 línur í blokk, lesum fastbúnaðarskrána 1 staf í einu og myndum blokk. Að bæta við 1 línu í blokk með sérstöfum fd3e02 + blokkanúmer.
Næstu 14 línur eru bættar við fd25 +, með því að nota XMODEM.calc_crc() reiknum við tékksummu allrar blokkarinnar (það tók mikinn tíma að skilja að „FF – 1“ er CSUM) og síðasta, 16. línan er bætt við. með fd3e.
Svo virðist sem það sé það, lestu fastbúnaðarskrána, smelltu á kubbana, aftengdu skannann frá kjarnanum og sendu hann í tækið. En það er ekki svo einfalt. Skipta þarf á skannanum í vélbúnaðarham,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Hvaðan er þetta lið?? Frá sorphaugnum.
En við getum ekki sent heila blokk í skannann vegna 64 takmörkanna:
Jæja, skanninn í NEWAPP blikkandi ham samþykkir ekki hex. Þess vegna verður þú að þýða hverja línu bytes_array
[253, 10, 22, 78, 44, 78, 69, 87, 65, 80, 80, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]Og sendu síðan þessi gögn í skannann.
Við fáum svarið:
[2, 1, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]Ef þú skoðar greinina um XMODEM kemur í ljós: gögnin hafa verið samþykkt.
Eftir að allar blokkir hafa verið fluttar ljúkum við flutningnum END_TRANSFER = 'xfdx01x04'.
Jæja, þar sem þessar blokkir bera engar upplýsingar fyrir venjulegt fólk, munum við sjálfgefið setja upp fastbúnaðinn í falinn ham. Og bara ef við á, munum við skipuleggja framvindustiku í gegnum tqdm.
Reyndar, þá er þetta spurning um litla hluti. Það eina sem er eftir er að pakka lausninni inn í forskriftir til fjöldaafritunar á skýrt skilgreindum tíma, til að hægja ekki á vinnuferlinu við kassana og bæta við skráningu.
Samtals
Eftir að hafa eytt miklum tíma og fyrirhöfn og hárið á hausnum gátum við þróað þær lausnir sem við þurftum og náðum líka tímamörkum. Á sama tíma eru skannanir nú endurræstir og endurþjálfaðir miðlægt, við stjórnum greinilega öllu ferlinu. Fyrirtækið sparaði tíma og peninga og við öðluðumst ómetanlega reynslu í öfugvélabúnaði af þessu tagi.
Heimild: www.habr.com