I have few stations which run my automation system based on pytest.
For some reason I have one station which running same Python version and same packages installed but when trying to run it fails since:
pytest_runtest_makereport(item, call) receive item as object of _pytest.python.Function instead of _pytest.nodes.Node
I use this hook in my code to do some stuffs and see that item received incorrectly and while trying to get some info from the test item it fails since the info I look for does not exists.
If someone knows why does it happen I will be glad to hear :-)
I'm considering using Matlab Compiler to distribute software for a price. I'm investigating (very) simple methods to discourage re-distribution without annoying users. Any recommendations?
One thought is to email a user a license key and have them input this during the installation process to be verified on a license server. If the key matches what is on the server, the installation proceeds as usual, otherwise, a warning message is shown to inform the user to purchase another license. However, this method requires a specified function to run only during the installation process, and not thereafter (so as not to annoy the user). Is this possible using Matlab Compiler or otherwise?
I suppose I could create a file on the user's disk that the program looks for when it starts (if it exists, then it is not being run for the first time), but if the user copies the whole directory, that file would get copied too.
In order to create an effective licensing system, you have to link it to one or more properties of a user machine (MAC address, OS ID, hard disk serial numbers, CPU serial numbers, etc...).
If you don't to this, you are just going to release licenses that can be transferred from one user to another. If one user decides to spread his license file worldwide, you are doomed because everyone could potentially take that license file and use it to unlock your application.
But if you link your license files to one or more properties of a user machine, as mentioned above, you must be able to obtain these properties either:
before the user decides to buy your application;
when the user activates his license.
First Scenario
You release your software as a trial. When it is started for the first time, you set an expiration date in the registry or in a file well hidden somewhere. You check against the expiration date when the application starts and, once it is reached, you throw an error and you don't let the used play with your application anymore.
Within the application, you create a Register Now button somewhere. When it is clicked, the application retrieves the machine properties and passes them to the web page / form that will be opened to let the user perform the payment. That page will be in charge to validate the machine properties, receive the payment and, finally, deliver a valid license code based on these properties.
Within the application, you must implement the same logics that allowed your form to create the license code, because you will need to use them in order to validate the code itself every time your application starts. A pseudo-code example:
mp1 = GetMachineProperty1();
mp2 = GetMachineProperty2();
mp3 = GetMachineProperty3();
lc = GetLicenseCode();
if (~strcmp(sha1([mp1 mp2 mp3]),lc))
errordlg('Invalid license code!');
return;
end
This is the simplest path. But keep in mind that if one or more properties of the user machine change (because he changes a device or reinstalls his OS), his license will be invalidated and you will have to provide a customer assistance service that takes care of this kind of situations.
Second Scenario
This one is much harder. You will not be able to know the user's machine properties in advance. So your licensing system will work on a two-steps basis. You release a unique code (called LID for example) when the used purchases your application. Then, once the user inserts that it in your application, your application must send it back together with the machine properties. The final key (called LKey for example) is then computed and sent back to the user.
mp1 = GetMachineProperty1();
mp2 = GetMachineProperty2();
mp3 = GetMachineProperty3();
lkey = GetLicenseKey();
if (~strcmp(sha1([mp1 mp2 mp3]),lkey))
errordlg('Invalid license code!');
return;
end
Machine Properties
The first solution has been provided to you through a comment: the MachineGuid value located in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography. It's pretty solid. But it will only work on Windows machines. Use winqueryreg to access the registry.
Another good alternative is the Window Domain Controller Security ID, which is another machine-specific unique identifier. You can retrieve it using Java code within Matlab:
wdc_sid = com.sun.security.auth.module.NTSystem.getDomainSID();
or through the Windows registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership. The registry approach should be the one to use if you want to maintain a certain backward compatibility with old Matlab releases. Unfortunately, the Window Domain Controller Security ID is another identifier that is available only on machines that run under Windows.
If you want to adapt your licensing system to every possible OS and environment, you have to use a more generic approach, based on universally accessible hardware properties: MAC adresses, hard disk serials and such things. As far as I know, the most reliable property is the MAC address, because its uniqueness, althrough not granted, is almost certain and it's very unfrequent to change a network adapter (there are more chances to break an hard disk actually). Retrieve the MAC adresses of the machine network adapters using Java code as follows:
mac_addrs = '';
net_int = java.net.NetworkInterface.getNetworkInterfaces();
while (net_int.hasMoreElements)
mac_addr = net_int.nextElement.getHardwareAddress();
if (~isempty(mac_addr))
mac_addrs = [mac_addrs, '-', sprintf('%.2X',typecast(mac_addr,'uint8'))];
end
end
mac_addrs = mac_addrs(2:end);
The above computation produces a character array that represents the result of the concatenation of all the MAC addresses found on the machine. Again, for compatibility reasons, this may not work on old Matlab releases, so you have to use a much more complex approach, described here.
[EDIT]
This approach to retrieve the MAC address based on the underlying OS could be easier:
switch computer('arch')
case {'maci','maci64'}
[~,a]=system('ifconfig');
c=strfind(a,'en0');if ~isempty(c),a=a(c:end);end
c=strfind(a,'en1');if ~isempty(c),a=a(1:c-1);end
% find the mac address
b=strfind(a,'ether');
mac_add=a(1,b(1)+6:b(1)+22);
case {'win32','win64'}
[~,a]=system('getmac');b=strfind(a,'=');
mac_add=a(b(end)+1:b(end)+19);
case {'glnx86','glnxa64'}
[~,a]=system('ifconfig');b=strfind(a,'Ether');
mac_add=a(1,b(1)+17:b(1)+33);
otherwise,mac_add=[];
end
I found it in the comments of this article.
Take a look at this example: a USB device in Windows 7 is reported to have Device instance path(DevinstPath) USB\VID_1EAB&PID_0501\7&25C389C1&0&1 and I know exactly that it corresponds to the so-called hardware-key(hwkey) in registry.
Now my question is: When my KMDF driver code has WDFDEVICE handle for that USB device, how can I know its DevinstPath?
I know I can
send a BusQueryDeviceID to achieve the so-called device-id USB\VID_1EAB&PID_0501;
send a BusQueryInstanceID to achieve the so-called instance-id 1 .
But I don't know how to get the so-called "instance-path". Could some kernel guru kindly tell me how I can get that?
MSDN doc seems really vague on this!
BTW: I also realize that user-layer function SetupDiGetDeviceInstanceId actually returns the DevinstPath -- although it is named "InstanceId".
Device instance path can be queried using DEVPKEY_Device_InstanceId, using either WdfDeviceAllocAndQueryPropertyEx or IoGetDevicePropertyData (passing the WDM physical device object)
Device Instance id is autoincrement sequence.
You can find HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum in registry;
Rules:NextPareneID.XXXXXXXX.N
XXXXXX use UUID Calculation crc32 values(test ok)
N is 1~9
Device Instance id format is N&PareneID&random's number&index
enter image description here
CUPS has 3 fields that are used in issue reporting,
printer-state (enum): Either idle, processing or stopped.
printer-state-message: Plain text human readable explanation.
printer-state-reasons: Listed description of the printer state, as described in RFC8011 p.152 this is where the real issue reporting happens. It has a list of comma delimited keywords describing the state of a printer eg. 'media-needed' or 'toner-low'
When testing a Zebra LP 2844 on Ubuntu 16.04 (and mac but let's keep this simple for now) using the Zebra EPL2 Label Printer driver, I get the following results.
----Printer out of paper----
Status Enum: processing
Status Message: printer-state-message: 1 textWithoutLanguage {Waiting for
printer to become available.}
Status Reason: printer-state-reasons: 1 keyword {none}
----Printer rejecting jobs----
Status Enum: idle
Status Message: printer-state-message: 1 textWithoutLanguage {Rejecting Jobs}
Status Reason: printer-state-reasons: 1 keyword {none}
As you can see, the 'Printer out of paper' issue and most issues that prevent the printer from printing resolve as 'processing' and never give me more information. You could figure out how long the printer has been 'processing' and deduce if there is a problem from there, but besides that being janky, the cause of the issue would remain unknown.
Meanwhile, the 'Printer rejecting jobs' state tells me absolutely nothing (remember, the Status Message is just human readable plain text and is not parsable due to there being no guidelines on what is put there). Besides hiring someone to read state-message there is no way for my program to know there is an issue.
This is not the case with all printers, for example, this is the output from a Brother HL-L2380DW
----Printer out of paper----
Status Enum: processing
Status Message: printer-state-message: 1 textWithoutLanguage {Waiting for job to complete.}
Status Reason: printer-state-reasons: 2 keyword {cups-waiting-for-job-completed, media-needed-error}
Of the 3 printers tested so far (HP, Brother, and Zebra), the Brother HL-L2380DW was the only printer to properly communicate issues. If you wish to test it yourself you can run this crude CUPS tool I tossed together in java https://github.com/Vzor-/cupstool More data helps!
I do not know if the issue lies with cups or with the manufacturers. Either way I need a way forward, be it as a fix or a group I can help to make a fix.
Edit: It seems Zebra does not make or maintain its own Linux drivers.
From Michael Sweet,
Kyle,
Status reporting is complicated, but in general the problem with
driver-based queues can come from the driver not implementing STATE:
message support (typically because the printer's communication channel
does not provide support) or from the printer itself not supporting
any kind of status reporting.
In the case of the Zebra printer, it does not support in-band status
reporting so the CUPS-bundled driver has no way of getting status from
the printer that way. It also does not support the SNMP Printer MIB
for status, so we don't even get out-of-band status... :/ Sadly,
these kind of printers often do not support status reporting, which is
funny given that many are deployed in industrial settings where remote
monitoring is common...
Printers that implement IPP (typically all printers these days except
label printers - so 98%+ of printers) support the IPP
printer-state-reasons keywords for status, in addition to other IPP
attributes and (in many cases) SNMP Printer MIB properties as well.
So it seems this is mostly just an issue with some label printers.
I have multiple 512MB SDSC cards that seem to block after getting a read single block command. I get back the expected data which I wrote before, but the card seems to stop returning anything but 0xFF afterwards. Even simple commands like CMD13 (request status) do not send back anything but 0xFF. While these commands did return normal before the read command was used.
The entire code does work with another SDHC card. Attempting reinitialization does not work until the card has had its power removed. I am using SPI mode.
I am running out of ideas what the issue might be.
The addressing scheme for SDHC and SDSC is slightly different: SDHC requires SECTOR id while SDSC needs BYTE address. Maybe that's the case with CMD17.