Archive for the ‘technikai infók’ Category

Nokia 9500 (és társai) unlock

Thursday, October 25th, 2007

Történt az, hogy 2 év után szolgáltatót váltottunk (Vodafone -> Pannon).
Szerettem volna, ha a Nokia 9500 Communicator-omat hivatalosan SIM kártyafüggetlenné teszik. Ezért tehát elfáradtam a West-Endbe lévő Vodafone kirendeltséghez, ahol kis várakozás után azt az információt kaptam, hogy ehhez bizony aláírási címpéldány kell (mert céges a telefon).

Ezt ott akkor is baromságnak gondoltam, mert bár mondhatni, hogy a szolgáltatófüggetlenítés határeset, de mégis inkább a telefon hardveréhez van több köze, hiszen nem kell ehhez semmifajta szolgáltatásnak meglennie a szolgáltatónál (amelyikhez a telefon simlock-olva van) és mindegy, hogy kitől van bele a SIM kártya. Tehát nem arról van szó, hogy emeltdíjas díjcsomagot szeretnék a telefonomhoz (értsd: inkább a telefonszámhoz) vagy még kérek 20 előfizetést vagy ilyesmi, hanem a szolgáltatást nem érintő, tisztán “hardveres” beavatkozásról van szó.
Onnantól kezdve, hogy ez telefont érintő “szervíz” és készpénzzel fizetek, nem értem miért kell bármiféle papír. Hiszen a telefont ledobhatom az emeletről, eladhatom, vehetek hozzá másik akkumulátort tehát szabadon rendelkezem vele így semmi értelme a szolgáltatófüggetlenítéshez papirokat kérni. (Nyílván a cégem felé lehet valami elszámolási kötelezettségem, de ehhez semmi köze a szolgáltatónak).

Meg persze elvihetem az “arab”-hoz is, hogy kódolja ki, de azzal az erővel már én is megcsinálhatom, akkor jobban érzem magam meg “olcsóbb” is.

Szóval miután tegnap a vodafone megszűnt számomra szolgáltatást nyújtani és még nem sikerült újra felkeresnem őket papírokkal felszerelkezve, reggelre kiégett a biztosítékom. Amúgy is volt még egy 3120-as amit ki kellett kódolni, ezt meg lehet tenni a http://unlock.nokiafree.org/ weboldalon. A 3120-ast 3100-ként kell kiválasztani és “GEN”-nek “Original”-t választani. További pár percembe telt, mire kiderítettem, hogy a listából nem választható 9500-ösnek mi a megfelelője. A megfejtés: ASIC-2. További megfejtések itt: http://www.nokia-tuning.net/index.php?s=asic

Minthogy asszem most bűncselekményt hajtottam végre, megyek és feljelentem magam.
De csak akkor, ha nincsenek sokan és nem kell hozzá aláírási címpéldány…

Melyik víruskereső a jobb…

Friday, October 19th, 2007

A legközelebb álló válasz talán az, hogy mikor-melyik…
Persze finomabb részletekbe is bele lehet menni, mennyi és mikori vírusmintákat tartalmaz, milyen gyakran frissítik, működik-e egyáltalán – mert ilyen is van, tapasztalatok szerint az E-Trust (Inoculan) csak akkor szól, hogy vírus van, ha már elindítottuk (és elkezdi kifejteni áldásos tevékenységét).

Vagy pl. a ClamAV le van maradva a régi vírusok felismerése tekintetében, bár ez manapság annyira nem érdekes, hiszen egy levelezőszerveren jellemzően újfajta vírusok próbálnak terjengeni, egy onehalf nem, hacsak nem valaki mókából ilyet küld valakinek, bár kétséges, hogy ez egy NT/2000/XP alatt egyáltalán képes-e valamit csinálni.

A vírusadatbázis frissességét úgy lehet ellenőrizni, hogy az ember kap egy új vírust és megnézi az összes víruskereső aktuálisan lefrissített változatával. Na persze ennél van egyszerűbb megoldás, a virustotal.com üzemeltet egy olyan szolgáltatást, melyen jelenleg 31 víruskereső aktuálisan frissített változata van és nekünk csak fel kell tölteni a kérdéses fájlt.

Példának okáért mellékelem a ma kapott “brand-new”, használt víruskeresőink által nem-nagyon felismert “gyanús fájlok” eredményeit:

1) http://www.virustotal.com/hu/resultado.html?34bff11f38f42cbee2fa81bd47173038

A(z) access.exe állomány feltöltve: 2007.10.19 13:53:07 (CET)

Eredmény: 17/32 (53.13%)

Antivírus

Verzió
Utolsó frissítés
Eredmény
AhnLab-V3 2007.10.19.0 2007.10.18
AntiVir 7.6.0.27 2007.10.19 Worm/Warezov.SN
Authentium 4.93.8 2007.10.19
Avast 4.7.1051.0 2007.10.18
AVG 7.5.0.488 2007.10.19 Downloader.Generic6.PFM
BitDefender 7.2 2007.10.19 Generic.Malware.dld!!.4333A34A
CAT-QuickHeal 9.00 2007.10.18
ClamAV 0.91.2 2007.10.17
DrWeb 4.44.0.09170 2007.10.19 Trojan.DownLoader.35874
eSafe 7.0.15.0 2007.10.15 suspicious Trojan/Worm
eTrust-Vet 31.2.5223 2007.10.19
Ewido 4.0 2007.10.19
FileAdvisor 1 2007.10.19
Fortinet 3.11.0.0 2007.10.19
F-Prot 4.3.2.48 2007.10.19 W32/Downldr2.AICW
F-Secure 6.70.13030.0 2007.10.19 Email-Worm.Win32.Warezov.sn
Ikarus T3.1.1.12 2007.10.19 Win32.SuspectCrc
Kaspersky 7.0.0.125 2007.10.19 Email-Worm.Win32.Warezov.sn
McAfee 5144 2007.10.18
Microsoft 1.2908 2007.10.19
NOD32v2 2603 2007.10.19 Win32/Stration.AAU
Norman 5.80.02 2007.10.18 W32/Downloader
Panda 9.0.0.4 2007.10.18 Suspicious file
Prevx1 V2 2007.10.19 W32.MALWARE.GEN
Rising 19.45.42.00 2007.10.19
Sophos 4.22.0 2007.10.19 Troj/StraDl-E
Sunbelt 2.2.907.0 2007.10.18
Symantec 10 2007.10.19 W32.Stration!dldr
TheHacker 6.2.9.099 2007.10.19
VBA32 3.12.2.4 2007.10.19 suspected of Win32.Trojan.Downloader (http://…)
VirusBuster 4.3.26:9 2007.10.18
Webwasher-Gateway 6.6.1 2007.10.19 Worm.Warezov.SN

További információ

File size: 4096 bytes
MD5: d3a68da3efb69d359065ce52d0615514
SHA1: ce6e78b9fe4b150d320e0c5e789b9f94a5bf7927
packers: UPX
packers: PE_Patch.UPX, UPX
norman sandbox: [ General information ]
* **IMPORTANT: PLEASE SEND THE SCANNED FILE TO: ANALYSIS@NORMAN.NO – REMEMBER TO ENCRYPT IT (E.G. ZIP WITH PASSWORD)**.
* File length: 4096 bytes.        

[ Changes to filesystem ]
* Creates file C:\WINDOWS\SYSTEM32\mbf32.exe.

[ Network services ]
* Opens URL: http://kadesuipontunhandesun.com/mbf32.exe.
* Connects to \”kadesuipontunhandesun.com\” on port 80 (TCP).
* Opens URL: kadesuipontunhandesun.com/mbf32.exe.

[ Security issues ]
* Starting downloaded file – potential security problem.

Prevx info: http://fileinfo.prevx.com/fileinfo.asp?PX5=26F78B2F0003CD1510F000D120933B00B79BCD14


Lehet látni, hogy pl. a ClamAV és a McAfee sem ismerte fel a vírust, de itt még mindig sokkal jobb a helyzet, mint a második példán:

2) http://www.virustotal.com/hu/resultado.html?6c18eb347437168ff96c38ec1822ce66

A(z) en.hta állomány feltöltve: 2007.10.19 13:53:42 (CET)
Eredmény: 6/31 (19.36%)

Antivírus

Verzió
Utolsó frissítés
Eredmény
AhnLab-V3 2007.10.19.0 2007.10.18
AntiVir 7.6.0.27 2007.10.19
Authentium 4.93.8 2007.10.19
Avast 4.7.1051.0 2007.10.18 JS:Feebs family
AVG 7.5.0.488 2007.10.19 Worm/Feebs
BitDefender 7.2 2007.10.19
CAT-QuickHeal 9.00 2007.10.18
ClamAV 0.91.2 2007.10.17
DrWeb 4.44.0.09170 2007.10.19
eSafe 7.0.15.0 2007.10.15
eTrust-Vet 31.2.5223 2007.10.19
Ewido 4.0 2007.10.19
FileAdvisor 1 2007.10.19
Fortinet 3.11.0.0 2007.10.19
F-Prot 4.3.2.48 2007.10.19
F-Secure 6.70.13030.0 2007.10.19
Ikarus T3.1.1.12 2007.10.19
Kaspersky 7.0.0.125 2007.10.19
McAfee 5144 2007.10.18 JS/Feebs.gen.aa@MM
Microsoft 1.2908 2007.10.19
NOD32v2 2603 2007.10.19 JS/Tivso.15.gen
Norman 5.80.02 2007.10.18
Panda 9.0.0.4 2007.10.18
Prevx1 V2 2007.10.19
Rising 19.45.42.00 2007.10.19
Sophos 4.22.0 2007.10.19
Sunbelt 2.2.907.0 2007.10.18
Symantec 10 2007.10.19 W32.Feebs@mm
TheHacker 6.2.9.099 2007.10.19
VBA32 3.12.2.4 2007.10.19 Trojan-Dropper.JS.Feebs
VirusBuster 4.3.26:9 2007.10.18

További információ

File size: 78874 bytes
MD5: 8cfacc22531b7cde7a2e5ed34d581a5b
SHA1: 0d3a72d2a60cc18b191f68bbde174eeb8f39271c

Itt a 31 víruskeresőből csak 6 gondolta, hogy ez mégiscsak valami ármány…

Természetesen ilyenkor az ember megpróbálja értesíteni a víruskeresőgyártó cégeket, de úgy tűnik, hogy ők nem kiváncsiak erre. Vagy egyáltalán nem teszik lehetővé fájl elküldését (vagy ha igen, nagyon eltitkolt helyen), vagy annyira megnehezítik a procedúrát, hogy az ember elküldi őket magában a meleg éghajlatra és nem foglalkozik vele. Pl. regisztráció szükséges – és küldjem emailben – ilyen meg olyan jelszóval, ilyen meg olyan formátumban tömörítve, mely emailt jó eséllyel megfogja valahol egy szerver – pl. a miénk, hiszen az minden futtatható (elméletben kártékony kódot tartalmazó) nem vírusként felismert fájlt is elhelyez egy kicsit pihenni, és csak késleltetve küldi tovább. Plussz értesítést küld, ha a “váróterem”-ben lévő fájlok száma csúnyán megnő.

Visszatérve a vírusirtógyártó cégekre. Az ideális hely az, ahol online, mindenféle egyéb munka nélkül (tömörítés, jelszó), kis kommenttel el lehet küldeni a mintát.

Jó példák:
ClamAV
http://clamav.sourceforge.net/cgi-bin/sendvirus.cgi
A minta küldési felületen minden megvan ami kellhet, sőt elküldéskor a saját motorjuk is ellenőrzi, hogy szerinte virus-e vagy csak nekem volt régi az adatbázisom (nálam általában az első…)

F-Prot
http://www.f-prot.com/virusinfo/submission_form.html
Point-and-click. Feltallózom a vírust, beírok valami kommentet (pl. a virustotal eredménylinkjét) és kész (Submission successful).

Virusbuster
https://support.virusbuster.hu/index.php?_m=tickets&_a=submit
Itt már üldözni kell egy kicsit a virus submit oldalt, és direkt link sincs kitéve, de még elmegy. Név/email (autofill), prioritás választása, file feltallózása, küldés, köszönjük…
(Közben tényleg jött tőlük egy “köszönjük” levél: “Köszönjük a beküldött mintát a néhány óra múlva megjelenő VirusBuster adatbázissal már Trojan.DL.Opnis.UT-nek ismerjük fel.”)

És a negatívumok:
Computer Associates E-Trust (Inoculan/InoculateIT)
http://home3.ca.com/Support/VirusSampleForm.aspx?
Felejtős. Autofill persze kitölt mindent, alul a file feltöltésnél az olvasható, hogy: “Attach the (preferably compressed and password protected) virus sample.”. Számomra ez azt jelenti, hogy “jó lenne, ha tömörítve és jelszavazva lenne” – de nem kizárólagos feltétel. Tömörítés (és jelszó) nélkül a submit után viszont a következőt kapjuk: “An error has occurred while uploading your file. Please go back and resubmit the form.
Make sure that you compress the virus sample using winzip, or pkzip, or any of a number of popular file compression utilities.”
Már évekkel ezelőtt jeleztem nekik… Nem minősítem jelzővel. Majd megkapják valahonnan.

Network Associates
https://www.webimmune.net/default.asp
Már volt róluk szó, változatos hibákkal tudják szórakoztatni az embert. Autofill nem működik és általában bejelentkezés után az jön, hogy a “Webimmune temporarily unavailable.” – küldjem email-ben… Most éppen a login sem működött, ez kaptam:
https://www.webimmune.net/validateLogin.asp
“A webhely nem tudja megjeleníteni a lapot
HTTP 500
A legvalószínűbb okok:
A webhely karbantartás alatt áll.
A webhely programozási hibát tartalmaz.”

Kaspersky:
http://www.kaspersky.com/scanforvirus
Van tallózás, küldés, szerintük: “You’re clean! Kaspersky Anti-Virus has not detected any viruses at this time in the file you submitted.” – Nincs lehetőség azt mondani, hogy “I disagree…”

Excel reloaded

Sunday, October 14th, 2007

És akkor álljon itt az Excel-es (Openoffice-os) XOR implementáció. Mivel az interneten nem találtam hasonló leírást, angolul (is) részletezem, hogy örüljenek más kontinenseken is…

Once upon a time, I wanted to do some basic XOR-ing in excel. Then I realized that there are no such thing a XOR. So I “developed” one and even though this is pretty simple to do, Google doesn’t seem to get such a solution, so I publish it here and now.

Since XOR is basically similar to add, eg.: (binary) adding or XOR-ing 0 vs. 1, 1 vs. 0 and 0 vs. 0 result the same, we only have to “do something” when there are two “1”-s to be dealt, as 1+1=2 but 1 xor 1=0.
Unfortunately to convert to binary, we need to enable Analysis Toolpak in Tools/Add-ins (in hungarian: Eszközök/Bővítménykezelő) to allow to use DEC2BIN (and HEX2BIN, whichever you want) then it is easy pie.

Let’s see 15 XOR 6
15 (decimal) will become 1111 “bin” after a DEC2BIN(15) and 6 will become 110. Adding the converted numbers as decimal will result in 1221. Then a SUBSTITUTE of “2”-s to “0”-s will be 1001, so after a BIN2DEC, you will get the result: 9.
(Doing “OR” instead of “XOR” would need a replacement of “2”-s to “1”-s)

xxx2yyy conversion fuctions have a limit of 0-511, so if your number is above, deal with it first.

So, if A1 and B1 contains the two (decimal) numbers to be xored, then C1 would be:
=SUBSTITUTE(DEC2BIN(A1)+DEC2BIN(B1),2,0)

Magyarul: Ha A1 és B1 tartalmazza a két összexorolandó (decimális) számot, akkor C1:
=HELYETTE(DEC2BIN(A1)+DEC2BIN(B1);2;0)
(angol excel vagy openoffice esetén az angolnál leírt képlet)
Az xxx2xxx függvények használatához engedélyeznünk kell az Eszközök/Bővítménykezelő-ben az Analysis Toolpak bővítményt melyek 0-tól 511-ig terjedő tartományban bírnak (csak) működni.

We get the result in binary, which we can convert with BIN2DEC or BIN2HEX (can also use HEX2BIN instead of DEC2BIN if we want to xor hex numbers right away)

Other ideas welcome / Egyéb ötletek jöhetnek

Zselatint mindenkinek…

Friday, August 10th, 2007

Akinek nem nálunk van a levelezése, elképzelhető, hogy találkozott már “You’re received a greeting card” és ehhez hasonló tartalmú levelekkel, melyben ha üdvözlet nem is, de egy jó adag exploitra mutató link van. Erre kattintva, gyengébben frissített gépek szintén “bezombulhatnak”.

Eddig is volt ilyen, de július elejétől szinte invázió van.
Ma megint jött egy “teljesen új”, és minthogy a szövegnek sok variációja van, mától a levelezőszerverünk szűrője az alábbi regex-nek megfelelő leveleket SPAM-nek (virus) minősíti:

http://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/\?

Tehát aki “http:// ip-cím /?” szöveget akarna a felénk küldendő levelébe tenni, az ne tegye… Sőt hosszútávon még a “/?” is lekerülhet a regex végéről…

Több infó a virusról:
http://vil.nai.com/vil/content/v_142621.htm

mystery solved: NetWare 3.x/4.x remirror starting at 88%

Tuesday, July 17th, 2007

Finally I took some minutes and checked that cosmetic issue, which symptoms in showing 88% percent remirror status right after the start of a remirroring (where it should be 0%) on earlier NetWares.

If install.nlm shows 42.949.680 or more data blocks (that is 171.798.720 sectors, approximately 163,84 GB) for a partition, then mirror algorithm will fail to correctly calculate the percentage.

Let’s say, we have 48.832.973 (0x2E921CD) data blocks, with 6627 (0x19E3) redirection blocks.
Then according to server.exe’s calculation, ~48.408.845 (~0x2E2A90D) “mirror blocks” should be mirrored.
There is an instruction “IMUL EBX*64h” which multiplies this value by 100 (0x64), but then the value will overflow the poor 32bit register, resulting in 0x1208A0914.
Then dividing the remaining 32bit part only (0x208A0914) by the number of data blocks (0x2E921CD) would result in 11 (0xB) which would be 99-11=88% complete.
So from then on, it will reach 99% by about mirrorring the 0xA699D-th block, then at next block it would “jump to” 12% (0xffffe10/0x2E921CD=0x57=87 -> 99-87=12%)
Then it would go to 99% “normally”

This only affects the calculation and display of the status percentage, not the mirroring procedure itself.
So even 3.x/4.x NetWares – more precisely the NetWare traditional file system – can handle large harddisk/block size, but seems like who wrote the “display percentage calculation” part wasn’t prepared enough…

Traditional file system’s “most important” size related limitations:
Maximum device size recognized (physical or logical): 2 TB
Maximum partition size: 1 TB
Maximum volume size: 1 TB
Maximum file size: 4 GB

Here is a more detailed comparsion on traditional FS versus NSS.

VBS – VS_FIXEDFILEINFO

Tuesday, May 29th, 2007

 

To make it short, I was writing a part of a login script in vbs which collects some version information on some “critical” software, and I was a bit suprised when I saw, that “getfileversion” returns 0.0.0.0 for Cisco Systems VPN Client files (such as ipsecdialer.exe). In this case, this happens, because the data part of it’s VS_FIXEDFILEINFO is not filled out properly (at all), …

… thus you can only rely on the “text based” stringfileinfo’s productfile information.

I was looking for several hours to find a method to obtain those parts with some simple commands or script, but all I could find referred to Visual Basic (not VB Script) or C.
“When I was young”, I wrote an assembly program (version.com on this page) to read data from VS_FIXEDFILEINFO, so I knew that implement it from the scratch would take some time, so I searched along…

Then I found an excellent site with excellent scripts, such what I needed: http://www.jsware.net/jsware/scripts.php3#fvinfo

Even more, I found some “comments” which I couldn’t even find it on Microsoft’s site:
Normally there is no VBScript method to return the information that shows when a file is right-clicked, then “Properties” is clicked, and the “Version” tab is selected.
I mean: Come on, Microsoft!?! Sometimes documenting that something cannot be done is better than nothing, at least I wouldn’t try to look for an “all-in-one” vbs command for it.

The script is neatly written and does the job. However, after some consideration, I decided not to put another 16K into the login script (tripling its size) just for read one screwed up application’s version number, I will just rely on the DisplayName value of the registry’s relevant uninstall key’s “DisplayName”, it is currently “Cisco Systems VPN Client 4.8.00.0440” on my system, so extracting the version number out of it would do the job.

Anyway, hats off to JSWare for creating and publishing such a brilliant code sample for obtaining version info from the VS_FIXEDFILEINFO resource.

Nprinter history and comment page

Friday, May 11th, 2007

This page is to let people know what happened (and what not) in connection with the problem that exhibits when using Nprinter (for NT) on an XP with Novell Client 32. (Eg.: blue screen – DRIVER_IRQL_NOT_LESS_OR_EQUAL)
Here you can also express your comments regarding to this issue.
Since the current status of this issue at Novell is “Closed” (unresolved), please do leave your comment here, to raise the chance of this issue to be fixed.

In “short” (but really…):

  • I created “my” webpage on Nprinter on 2004.JUN.07. This is approximately more than a year after I needed to have nprinter on Windows 2000 and XP. Later on I started experiencing this issue on XP machines…
  • Time passed, I got mails and I also experienced the problem at other customers too.
  • I experienced a problem at a customer, where finally we had to buy some print servers to solve the problem, so I got “pissed off”, then I reported “NWClient 491SP2+PKA – nwsipx32.sys – DRIVER_IRQL_NOT_LESS_OR_EQUAL” to: Novell’s patchfeedback address on: Wednesday, May 24, 2006 11:44 AM (with screenshots and other details)
  • Same day I got answer from Earle Wells congratulating on how I detailed the problem and that I should use NDPS.
  • After several more letters on the same day, I “achieved” that we’ve reached to: “Good news! Engineering is willing to take a look at a kernel memory dump”
  • I sent dump, next day he informed me that they found the bug, but it would be too problematic to fix it and probably would never be fixed. An internal TID was also created, and service request ticket was closed.
  • I got several more letters from other “nprinter fan-s” and on 2006 August 17, I contacted my Novell “internal” / “problem-solver” friend to check if there is anything more we could do. Next day he wrote me back, that it is in the “wontfix” category, and he could talk about it in more detail for hours…
  • So I called him. As far as I remember, he explained that it is not even clear that this is a nwsipx32 bug (as sometimes it happens in tdi.sys which is XP’s part), and it is low priority and obsolete and so on (which I’ve already known/suspected).
    I also tried to ask what would be the cost of fixing this, but it is not the matter of money. I also got the internal mailing on this, saying:
       > The particular point at which the NULL pointer is being
       > dereferenced is within a Microsoft-supplied TDI compile-
       > time macro, and between the complexity of it & the fact that
       > this is release code with full optimization, its going to take a
       > couple hours of de-compiling the previous instructions to
       > root out what exactly was being referenced that was NULL.
       > After that of course comes “why”.
       > So it’s not something that is a slam-dunk or quickly
       > actionable, which doesn’t bode well for an NWSIPX32
       > issue being observed primarily
  • So the same day (2006.AUG.18) I contacted another friend of mine – who is my partner’s brother and working for Microsoft at Seattle -, asking whether there is any bugreport on TDI.SYS [based on: http://support.microsoft.com/kb/829120/en-us] or a patch/beta release of the file.
  • Next day I got a negative answer and also a suggestion that I should contact MS support starting from “support.microsoft.com“.
  • I answered that I don’t “believe” in having any result of a noname guy opening incident via web support, and even if I would, where to start at all…
  • Two days later (AUG.21) he mailed that he don’t really know where to start (and via OEM, VAP, Technet or what other channel) and he will ask around.
  • On 22nd, another friend of mine called me. I didn’t have any news on what he is doing lately, but it turned out that he is the Director of Support at Microsoft Hungary
  • He guided me what link should I use to let them have green light on this problem and he called me after he “saw” the incident getting started in their system. Then a hour later a support guy called me, I said I didn’t have much more information, but I made dumps available for them to download.
  • We agreed that they should look into dumps only where the BSOD happens in TDI.SYS (and not in NWSIPX32.SYS) as the issue exhibits itself sometimes in TDI.SYS, sometimes in NWSIPX32.SYS
  • On 23rd I got called from MS Hun. tech support that they need to escalate the problem to higher level, to debug the dump more thoroughly, and also because this really seems to be a “bug”, not a “support incident”. [id: SRQ060822600811]
  • On 24th, I got called saying the dump has been done, and the BSOD is Novell’s fault. I asked more (written) technical data, then later I got a a forwarded mail with also not to much technical information, mainly saying: “… basically the problem is caused by a novell driver that is not compatible to windows xp.”
  • Then I replied that I would really need more technical info to be able to “bounce back” the problem to Novell.
  • Finally I got a Windebug analysis with some comments.
    The most important was:
    “f88a9dac 805ce794 f8b79298 00000000 00000000 nwsipx32+0x4d3a < ---   Here we see the 3rd party driver loaded - but as we do not have the source code / symbols we cannot see the arguments passing up"
  • Then I realized I can also do a windebug analyze, so I downloaded and installed Windebug and some other required tools. I “analyzed” the rest of my dumps and created a very detailed analysis and comparsion on the different dumps.
  • On 28th, I forwarded my results to my friend at Novell Hungary.
  • On Sep. 1 MS contacted me to ask if they can close the incident.
  • I asked my friend at Novell on where are we. He said, his guy is on vacation, so I should hold on.
  • Time passed, then on Oct 11, I got an information from Novell that they assigned a priority to the bug. Even very low, but anyting can be higher than “wontfix”…
  • On FEB 23, 2007, I got a mail that says the bug is planned to be fixed in 4.91SP5.
    Though I don’t have permission to bugzilla, the link is here, and it’s main content is:
       What                 |Removed         |Added
    ———————————————————————
    Fixed in Milestone|—                     |4.91 SP5
  • Beginning of May I was informed that the status of this “issue” is “closed”. Not a “wontfix”, but basically closed without a solution.
  • I was also suggested that everyone having this problem should contact Novell and open an incident…

Since I believe it would be harder to convince people to do so I tried to support my already opened incident with the dozens of mails I received relating to this issue and I still would like your comment and some data (number of computers affected, maybe company name). The email field at the comment will not be published, so feel free to use your valid address if you would like to be notified upon any advancement.

NT4 és UDMA

Tuesday, February 27th, 2007

Lehetséges és egyszerű. Lássuk hogyan és miért:

Service Pack 3-ban van egy DMACHECK.EXE nevű utility. Vagy letölthető innen:
How to Obtain Dmacheck.exe for Windows NT

Ha a hardver támogatja, akkor ennek segítségével a bekapcsolt DMA támogatás csodákra képes.

Tesztként egy 27GB-os partíció szoftveres tükrözésének és CLIBench teszt programnak eredményei.

Előtte:

CLIBench:
Read average: 3078  kB/sec
Write average: 1649  kB/sec
CPU usage: 99  percent

Tükrözés CPU használata:

Tükrözés DMA nélkül

Tükör felépítésének ideje: 290 perc (!)

Bekapcsolás menete:

DMAcheck

(És egy újraindítás.)

Utána:

CLIBench:
Read average: 47716  kB/sec
Write average: 22745  kB/sec
CPU usage: 2  percent

Tükrözés CPU használata:

Tükrözés bekapcsolt UDMA-val

Tükör felépítésének ideje: 15 perc (!!!)

Forrás:
Unleash UDMA Love under NT
(Ha a fenti segédprogram nem segítene, itt további információt találsz.)

Windows 2003 server R2

Wednesday, October 18th, 2006

Hi,

I am a guest blogger at maques’s sparks. I just opened up a new category: winrant. I plan to post about annoyances in Windows World. I hope someday they will be fixed in a future version.

Situation: You want to add a domain controller to an existing Windows 2003 Small Business Server.

Install Windows 2003 server R2 and run dcpromo.

You will be faced with the error that ADPREP need to be run. (Sorry, no exact error message. Next time I’ll try to grab one.)

No problem, you insert Windows 2003 server R2 installation CD in SBS and run adprep /forestprep from the I386 directory. It will tell you, that it does not need to upgrade the AD. Running dcpromo on the new server will present the same error.

Solution: Run adprep from CD2 of Windows 2003 server R2 installation. There is a newer version, which will update the AD and you can add the domain controller.

Annoyance: please remove ADPREP from CD1 or better, replace it with a version, that displayes, there is a newer one on the other CD. Thanks, in advance.

What your mother didn’t tell you about ArcServe 6.x for NetWare…

Wednesday, October 18th, 2006

Yesterday I ran into that problem (again) that I cannot restore with ArcServe 6.x from other than session 1.

In case you’re also using a skeleton NetWare with a similarly old ArcServe and Google to search :-), here are the error messages:

E1058 Failed to read from media – Filemark detected
E1112 Failed to find session 2.
E0015 Job xxxx: Restore Operation Failed

As far as I remember, last time when I tried to look for the solution I failed, but now I found a relatively fresh solution/explanation at:
http://www.tek-tips.com/viewthread.cfm?qid=1238418&page=7
It refers to
http://software.groupbrowser.com/archive/t-110093.html as partial source.

I also devoted some more slice of my life to get further information on this, here is the compacted result.

When a tape drive is not recognised by tapesvr.nlm, then it uses the default settings, which is 1024 bytes for block size and “VTABLE” for format type as CA’s TEC356365 “explains”:

Prior to the latest device patch, if the tape device could not be matched to the Tapelist.dat file, Tapesvr.nlm would still load, but the device would be initialized with generic information for that device type. In those cases, drives could be initialized with an incorrect format type of VTABLE (instead of FSTSEEK) and an incorrect block size. The results could range from poor drive performance to the inability to restore backed up data.

So, when you try to restore from other than session 1 (eg.: session 2, 3, etc.), then you get the above mentioned error messages (the “inability to restore backed up data” part).
However, you can still restore files from any session, by issuing a “tapesvr enable vtrestore n” command on the NetWare console, obviously “n” is the session number to be deal with. (You should get a message like “VOLUME TABLE restore of session #n has been enabled”)

I strongly suspect, that this is not just 6.1/6.6, but (BAB-BrightStor ARCserve Backup) 11.x too.
As described in CA’s TEC356365, they “realised” that this is not good, so they created a patch, which instead of letting tapesvr.nlm start with the “standard settings” (1024/VTABLE), now display you the following warning message and tapesvr unloads.
“E6918: An un-certified/un-supported device has been detected! Check the Computer Associates technical support website for more information… ”

They also created an tapesvr.cfg option:
UnSupportedDeviceOverride=ENABLED” as they say: “ONLY to allow users to be able to use ‘certified’ devices without having to immediately down the server and remove the ‘uncertified’ devices in order to allow tapesvr to load“.

In fact, as TEC356365 also says, having an unsupported device, with default settings have the only problems of “poor drive performance” and “inability to restore backed up data“.

The latter was discussed previously, but actually I don’t really understand why ArcServe cannot just simply restore that damn session in VTABLE format automatically, why do I have to enter that cryptic “tapesvr enable vtrestore n” command?

As for speed, with the 1K/VTABLE settings I got “92,320 files 11,346,014 KB written to FULLSYS @190,742 KB/min”. After changing to 16K/FTSEEK, I got “92,349 files 11,211,035 KB written to FULLSYS @192,574 KB/min”.
Not much of a change. (I use CANWPABD by the way.)

Now you got the question, how can you change from 1K/VTABLE to bigger buffer and FTSEEK.
The answer is relatively easy. Use the latest tapelist.dat and see if you tape drive is in the file. I mean, yes, no matter what version of ArcServe you use, grab the latest tapelist.dat you can. Currently the newest seems to be available from “BrightStor ARCserve Backup r11.1 SP2 for NetWare [build 961]“.
I understand if you wouldn’t like the idea to download an 500MB kit to get that 30K file, so here is it for you: tapelist.dat [29688 bytes, 2006.SEP.12].

Copy the file to ARCSERVE.6\NLM directory, unload and reload tapesvr.nlm.
To check the settings, remove any tape from the device, then go to “Tape Server”, “Tape Device Management”, “Tape Drive Status” menu.

If you see change, then you can go to have fun. If you don’t you’re out of luck. You can get your favourite hexeditor, and overwrite a similar entry’s id [name] in the tapelist.dat and hope it would work, or wait for a newer tapelist.dat.

Passing by, I noticed an article on “validate.nlm” which you might also like. Quote:

What is VALIDATE.nlm?

In the distant past, …
… Therefore VALIDATE.nlm was never used for its intended purpose. ARCserve still requires VALIDATE.NLM. VALIDATE.nlm simply tells ARCserve that all drives are acceptable.

Good job, validate.nlm!