Sida 1 av 2
APU2C4 problem
Postat: 6 augusti 2018, 19:41:35
av Jolles
Har en APU2C4 som betett sig underligt lite sedan från början.
Jag har kört den som brandvägg (OPNSense) sedan några månader med halvdant resultat.. Det började med att den inte alltid startade upp ordentligt utan krashade och behövde bootas några gånger innan den gick up med en trudelutt från en inbyggd högtalare.
Installation och setup av enheten sker helt med serie-sladd och jag lyckades hitta en
sån här som kopplas direkt mot moderkortet för att det skulle bli så rätt som möjligt och förhoppningsvis slippa eventuella rs232<-->usb adapter-problem.
Men nu häromdan skulle jag starta om en tjänst i opnsense varvid jag fick error om 'cannot allocate memory' men med bara 400mb av 4gb utnyttjat så tyckte jag meddelandet var lite underligt. Slutligen bootade jag om den men jag har inte fått upp den igen sen.
opnsense3.png
Allting ser bara helt wierd ut, och min förhoppning är att det inte är ram-minnet som är boven..
För sakens skull så kopplade jag bort den lilla ssd-disken (M.2-SSD) och startade upp igen medans jag följde i uppstarten, men det är inte så lätt som man kan tro
en teaser här:
Kod: Markera allt
FFrreeeeBBSSDD//xx8866 bboooott
DDeeffaauulltt:: 00::aadd((00pp33))//bboooott//llooaaddeerr
bboooott:: ESC[40;30;22m
ESC[12;1H ESC[m
C o n s o l e s : i n t e r n a l v i d e o / k e y b o a r d s e r i a l p o r t
Min första reaktion är om min terminal är felinställd, men allt står default och 115200 baud. Har även provat med nån mer än Minicom men jag är inte super-hajj på inställningarna.
Andra gissningen är att ram-minnet är korrupt.
Har någon någon gissning eller tips om vad som kan/bör göras? Garanti är det inte snack om iaf.
Re: APU2C4 problem
Postat: 6 augusti 2018, 20:22:37
av Zkronk
screen använde jag som terminalemulator när jag installerade pfSense på min APU2C4.
Med en USB-ansluten adapter till serieporten på baksidan.
Finns det inte memtest86+ inbyggt i den? Jag har för mig att jag körde det ett tag när jag precis fått hem maskinen för att kolla så RAM-minnet var schysst.
Re: APU2C4 problem
Postat: 6 augusti 2018, 20:51:45
av Jolles
Ditt screen-kommando där visade ingenting mer än en svart bild...
"8N1" vad innebär det?
Efter många om och men lyckades jag komma in i memtest igen vilket inte är så lätt när den skriver text lite vart den känner för.
Strax efter jag öppnat memtest:
MEMTEST1.png
En stund senare:
MEMTEST2.png
Re: APU2C4 problem
Postat: 6 augusti 2018, 23:04:44
av lond
Tror att jag använde mig av TeraTerm i Windows när jag installerade min med pfSense för snart 2 år sedan...
Dock så använder sig pfSense sig av 9600 8N1 (Data = 8 bitar, Parity = No, Stop = 1 bit).
/// Marcus
edit: 9600 8N1 är vad jag har ställt in i pfSense.....
Re: APU2C4 problem
Postat: 6 augusti 2018, 23:29:00
av Jolles
Ah, så det fanns inställningar i OS för baud/data/parity/stop iaf då. Jag har inte sett av något av det själv men har väl inte haft ögonen öppna helt
Just nu är det lite svårt oavsett, hårdvaran består ju iaf av ECC minnen påstår den själv och det låter ju bra. Får väl prova att blåsa in en ny image på SSD'n om det skulle ge något... lite skeptisk.
Fasinerande nog visade inte 'screen ... 8N1' någonting men '7N1' fick jag åtminstone lite galna tecken på skärmen, men avbrböts strax därpå med "screen is terminating".
"minicom -7" ger däremot samma resultat som "minicom -8".
Har testat lite blandade baudrates också men inget som visat sig bättre.
Re: APU2C4 problem
Postat: 6 augusti 2018, 23:57:11
av mrfrenzy
Har du tillgång till ett oscilloskop eller en microkontroller så kan du ju enkelt mäta tiden mellan två bitar och räkna ut baudrate.
Annars finns det några knep i linux, ställ baudrate till 115200, 8n1 och läs den råa bitströmmen som kommer in. Genom att räkna hur många dubblerade tecken det är så kan man klura ut baudrate och antal bitar/paritet.
Re: APU2C4 problem
Postat: 7 augusti 2018, 00:03:20
av sodjan
Bara lite tankar som kanske inte löser ditt problem...
De där exemplen med dubblerade tecken, är det då skriver kommandon till burken?
Om det är så, så ser det ut som ett typiskt exempel på "dubbla eko". D.v.s att du
har "local echo" påslaget i ditt terminalprogram (det visar vad som skickas) och
burkens terminal interface ekar också varje tecken tillbaka.
De där "ESC[..." koderna är ANSI/VT koder för terminalstyrning. Jag har inte
slagit upp vad det ska vara, men den första kanske "dubble hight, dubble width".
Texterna "C o n s o l e s :" antar kommer från burken enbart och är alltså inte dubbel.
Men skulle kanske visas med dubbel höjd/dubbel bredd på en terminal som förstår
ANSI/VT escape sekvenserna. (Kolla att du har VT100 (minst) emulering påslaget).
Memtest skickar ju massor av ESC-sekvenser och du måste ha en terminal som
stöder det (eller se till att du har valt en VTxxx emulering) för att få ordning på det.
Alla de där med "[n;mH" ser ut som cursor styrning. Kolla här och sök efter
"Cursor Home":
http://www.termsys.demon.co.uk/vtansi.htm
"
Cursor Home <ESC>[{ROW};{COLUMN}H"
> Genom att räkna hur många dubblerade tecken det är så kan man klura ut baudrate och antal bitar/paritet.
Ja, om texten är lite hur som helst. Men i detta fall, men en ren dubblering av uppenbart (?)
korrekta tecken, så satsar jag på "dubble echo". Alltså eko i båda ändar...
Avsaknaden av ANSI/VT emulering är ett annat stort problem, det kommer bara att
bli "skräp" på skärmen innan det är fixat...
Re: APU2C4 problem
Postat: 7 augusti 2018, 00:32:04
av mrfrenzy
Aah, du har förstås rätt Sodjan.
Det verkar som att det installerade operativsystemet använder en högre baudrate än bootloadern.
Vid boot:
FFrreeeeBBSSDD//xx8866 bboooott
Uppenbarligen för hög baudrate inställd i klienten
Efter boot på skärmdumparna:
Texten är korrekt men massa skräptecken, förmodligen rätt baudrate men fel inställd terminalemulering.
Personligen föredrar jag putty för den är ganska bra på att detektera och det är sen lätt att ändra i inställningarna.
Re: APU2C4 problem
Postat: 7 augusti 2018, 00:40:43
av Jolles
VT102 verkar det vara enligt minicom
vt102.png
"Local echo" var ju också nått nytt för mig
Man ska kunna toggla det on/off men det verkar inte fungera.
Re: APU2C4 problem
Postat: 7 augusti 2018, 00:55:21
av mrfrenzy
VT102 är vad din Minicom är inställd på, det är uppenbarligen fel eftersom du inte ser terminalen korrekt.
Denna inställning är antingen default eller hämtad från env i ditt OS.
Om man googlar lite säger många att dom har problem att ansluta till OPNSense terminal men vanlig PFSense går bra. Kanske går det att hitta något i manualen till OPNSense annars får du testa dig fram.
Re: APU2C4 problem
Postat: 7 augusti 2018, 12:37:39
av sodjan
> Vid boot:
> FFrreeeeBBSSDD//xx8866 bboooott
> Uppenbarligen för hög baudrate inställd i klienten
Är det där text som användaren skriver in?
Eller är det text som enbart loggas från burken?
Vid fel baudrate så skulle jag inte förvänta mig bara dubblerade tecken.
Det är väldigt osannolikt att det skulle bli rätt tecken alls, normalt
blir det bara "skräp".
Därmot om det skrivs in av en användare, och både terminalprogrammet
och andra änden ekar tecknen, så blir det absolut så där.
Om jag ändrar till "Local Echo:
Force on" i Putty så får jag:
Kod: Markera allt
$
$ sshhooww ttiimmee
7-AUG-2018 12:29:31
$
$ show time
7-AUG-2018 12:32:45
$
Notera att jag tror att telnet protokollet defaultar (fall-back) till "local echo on"
om den burk man kör emot inte negotierar telnet protokollet korrekt. Bättre
att ställa terminalen till "raw" istället och ställa in parametrarna manuellt.
> VT102 är vad din Minicom är inställd på, det är uppenbarligen fel
Vilken VT1xx emulering som helst borde klara de enkla ESC sekvenserna
för cursor adressering. Men byt gärna till VT220 eller "bättre" om det finns.
Re: APU2C4 problem
Postat: 7 augusti 2018, 23:39:51
av Jolles
> FFrreeeeBBSSDD//xx8866 bboooott
Är det där text som användaren skriver in?
Nej. Det är bara vad som dyker upp under boot-sekvensen.
Notera att det "ibland", eller så att säga på vissa ställen, blir helt rätt - alltså att texten "rendreras" som förväntat på skärmen; som exempelvis menyn till OPNSense, där jag kan göra några val innan den auto-bootar os.
Jag blev klart förvånad när jag vid lite meckande såg en login-prompt till min dator passera förbi i minicom fönstret, vet inte hur jag ska förklara.. Jag fick för mig en stund att det var mer än en seriell ström data jag lyssnade på då, och att det skulle kunna ge upphov till det underliga beteendet.
Jag har försökt sätta 'local echo' på flera sätt, men får ingen direkt bekräftelse på om det är av eller på, strömmen ser i princip detsamma ut ändå.
Re: APU2C4 problem
Postat: 8 augusti 2018, 00:16:23
av sodjan
OK, om det kommer dubbla tecken från burken så där utan vidare så är det underligt.
Jag tror dock fortfarande inte att fel baudrate kan ge det resultatet.
> ...som exempelvis menyn till OPNSense,
Ja, det beror ju på hur den skrivs. Man kan ju skapa en meny bara genom att skriva
ut ett antal rader utan att flytta markören med mer en CR och LF. Det fungerar alltid.
> Jag blev klart förvånad när jag vid lite meckande såg en login-prompt till min dator...
"min dator" är alltså den burk som vi talar om hela tiden? Det låter som att en login
process har triggats av någon anledning. Är du kopplad till en konsol-port där det
även går att logga in? En login process kanske kan triggas av att det kommer en CR
på linjen, jag vet inte... Eller så startar det en login process som en del av boot...
> Jag har försökt sätta 'local echo' på flera sätt...
"Local echo" har bara betydelse för sådant som du skriver själv från terminalen till datorn.
Om inte texten som visar dubbla tecken skrevs av dig, så har "Local Echo" ingen betydelse.
Det betyder helt enkelt att då du trycker en tangent så visas det på skärmen samtidigt
som det skickas till datorn. Sen så brukar de flesta terminal interface i datorer eka alla
tecken direkt, det ger en verifiering av att linjen är "hel", så därför stänger man av
det lokala ekot i terminalen.
> Jag fick för mig en stund att det var mer än en seriell ström data jag lyssnade på...
Ja, rent tekniskt kan det kanske vara flera olika processer i datorn som skickar data
på den där linjen (konsolen eller vad det nu är). Så visst kan det kanske vara så...
Notera att jag uttalar mig kring seriella terminal interface i lite generella termer,
jag vet inte ett smack om just vad en APU2C4 är eller hur just den fungerar.
Re: APU2C4 problem
Postat: 8 augusti 2018, 00:38:11
av Jolles
ååkej, "min dator" hänvisar jag till den jag sitter på alltså med skärm och tangentbord och all lyx, ledsen om jag var otydlig
Just därför blev jag lite förvånad när en loginprompt till denne dök upp i serie-strömmen - just därför slog det mig en tanke om en andra parallell ström..
Vad bra, då kan vi nog avfärda problemet med 'local echo'.
Jo jag tror bara det här problemet är relaterat till serie-kommunikation och dess inställningar i förhållande till varandra. Skulle väl egentligen kanske prova att ansluta serie-sladden till en annan maskin för att lättare kunna peka på problemet, men jag har tyvärr ingen annan att prova med just nu.
Re: APU2C4 problem
Postat: 8 augusti 2018, 01:24:49
av sodjan
Ah, OK...
Alltså samma dator som där du kör terminalemulatorn.
Okej... Är det något Linux system och det var en "login:" prompt du såg?
Hur vet du att den inte kom från APU burken? Det finns ingen "inloggning"
som är möjlig alls på den kanske?
Ett annat tips, slå på "loggning" i terminalemulatorn. Det brukar finnas i alla
olika emulatorer. Då får du en text fil som du enkelt kan gå tillbaka i och
klippa ut intressanta delar ur. Jag gör alltid det vid större uppdateringar
eller vid en omstart så att konsol texterna kan kontrolleras i efterhand.
Men hur som helst, jag har ingen bra förklaring till de där "FFrreeeeBBSSDD"
och liknande texter. Den kanske bara talar långsamt för att bli förstådd...