Is it possible to obtain file path from IPP headers? - printing

I writeing printing web application which simulate printer behavior. It uses IPP protocol to receive document within printing request.
I can obtain some information about print job from IPP attribute code 0x42 in IPP headers:
filename - full file path (it's my aim) in case of Notepad++ and only filename if I print document from MS Word
user name - from OS
Can I obtain full file path from IPP independent from application? May be I can achieve this with additional request?

0x42 specifies just the value type - in this case it probably represents type nameWithoutLanguage.
Filename
Short answer: There is no standard way to obtain the file path from ipp headers.
Depending on the ipp client implementation (e.g. the windows printer driver) you might be able to use some other attributes. There are various options how a driver could submit a print job.
Jobs sent via the ipp operation PRINT_JOB (0x0002)
The file is being added as stream of bytes (formatted in a specific print-job-language like postscript or pdf) . Most implementations set the job attribute job-name to the name of the original filename or filepath.
Jobs sent via the ipp operation PRINT_URI (0x0003)
This method is rarely used but would provide a URI where the printer would have to load the file or data to print from. The URI includes a path.
Username
As for the username there is a standard ipp attribute available: requesting-user-name. It is the ipp clients (e.g. windows printer driver) responsibility to set the this value. RFC 2911 Section 3.2.1.1 Print-Job-Request says:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by
the client as described in section 8.3.

Related

How to create a custom JMeter Pre-Processor to convert a json payload into MQTT Binary packet

I need a JMeter Pre Processor which will convert a JSON String into a MQTT packet i.e binary data. The binary data will then be sent over the web socket using the JMeter web socket plugin - https://github.com/ptrd/jmeter-websocket-samplers
I am relatively new to JMeter and would appreciate any help on this. Please refer to my earlier question for the project scenario :
Testing a MQTT Client using JMeter
You kindly provided the link to the documentation which says:
The request-response sampler, as well as the single-read and single-write samplers, support both text and binary frames. For binary frames, enter the payload in hexadecimal format, e.g. 0xca 0xfe or ba be
So
Text data can be sent as they are (JSON is more or less plain text)
Binary (non-text) data needs to be converted to hex first
So you need to determine what exactly you need because your current requirement is a little bit vague and contraversial.
If you're looking for a function to convert string to hex - you can go for JSR223 PreProcessor and something like:
def hex(byte[] data) {
def rv = new StringBuilder();
data.each { aByte ->
rv.append('0x').append(String.format("%02x", aByte)).append(' ');
}
return rv.toString();
}
Demo:
More information on Groovy scripting in JMeter: Apache Groovy - Why and How You Should Use It

How to validate a message in pcap?

I have a requirement to expand required tree in decoded parameters of pcap file and validate a message in it.
Example:
Open "Transmission Control Protocol" as shown in screenshot and and validate for the message "This is an ACK to the segment in frame: 278".
Need to develop an automation script in Java for validating messages in pcap files . Currently am using jnetpcap lib.
Appreciate your inputs!.
You can't, without protocol analysis by yourself. A pcap file doesn't include such massages.
The message "This is an ACK to the segment in frame: 278" was generated by wireshark after TCP session analysis by itself. Even the frame number 278 was assigned by wireshark. A pcap file only contains packets' data.

Is there a way to determine the Physical Sector Size for removable drives with file systems other than NTFS (like FAT16, exFAT...)?

I need a function to get the Physical Sector Size for all kind of system drives, in Win7 or higher.
This is the code that I've used until today, when I found out that it's not working with my external USB HDD (exFAT file system) and with my USB MP3 Player (FAT16). In these cases the function DeviceIoControl fails and I get the exception: "System Error. Code 50. The request is not suported". But it works very well with NTFS volumes.
function GetSectorSize(Drive:Char):DWORD;
var h:THandle;
junk:DWORD;
Query:STORAGE_PROPERTY_QUERY;
Alignment:STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR;
begin
result:=0;
h:=CreateFileW(PWideChar('\\.\'+UpperCase(Drive)+':'),0,FILE_SHARE_READ or FILE_SHARE_WRITE,nil,OPEN_EXISTING,0,0);
if h=INVALID_HANDLE_VALUE then RaiseLastOSError;
try
FillChar(Query,SizeOf(Query),0);
Query.PropertyId:=StorageAccessAlignmentProperty;
Query.QueryType:=PropertyStandardQuery;
if not DeviceIoControl(h,IOCTL_STORAGE_QUERY_PROPERTY,#Query,SizeOf(Query),#Alignment,SizeOf(Alignment),junk,nil) then RaiseLastOSError;
result:=Alignment.BytesPerPhysicalSector;
finally
CloseHandle(h);
end;
end;
According to MSDN:
File Buffering
Most current Windows APIs, such as IOCTL_DISK_GET_DRIVE_GEOMETRY and GetDiskFreeSpace, will return the logical sector size, but the physical sector size can be retrieved through the IOCTL_STORAGE_QUERY_PROPERTY control code, with the relevant information contained in the BytesPerPhysicalSector member in the STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR structure. For an example, see the sample code at STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR. Microsoft strongly recommends that developers align unbuffered I/O to the physical sector size as reported by the IOCTL_STORAGE_QUERY_PROPERTY control code to help ensure their applications are prepared for this sector size transition.
This same quote also appears in the following MSDN document:
Advanced format (4K) disk compatibility update
Which includes the following additional information:
The below list summarizes the new features delivered as part of Windows 8 and Windows Server 2012 to help improve customer and developer experience with large sector disks. More detailed description for each item follow.
...
•Provides a new API to query for physical sector size (FileFsSectorSizeInformation)
...
Here’s how you can query for the physical sector size:
Preferred method for Windows 8
With Windows 8, Microsoft has introduced a new API that enables developers to easily integrate 4K support within their apps. This new API supports even greater numbers of scenarios than the legacy method for Windows Vista and Windows 7 discussed below. This API enables these calling scenarios:
•Calling from an unprivileged app
•Calling to any valid file handle
•Calling to a file handle on a remote volume over SMB2
•Simplified programming model
The API is in the form of a new info class, FileFsSectorSizeInformation, with associated structure FILE_FS_SECTOR_SIZE_INFORMATION
FILE_FS_SECTOR_SIZE_INFORMATION structure
This information can be queried in either of the following ways:
•Call FltQueryVolumeInformation or ZwQueryVolumeInformationFile, passing FileFsSectorSizeInformation as the value of FileInformationClass and passing a caller-allocated, FILE_FS_SECTOR_SIZE_INFORMATION-structured buffer as the value of FileInformation.
•Create an IRP with major function code IRP_MJ_QUERY_VOLUME_INFORMATION.
•Call FsRtlGetSectorSizeInformation with a pointer to a FILE_FS_SECTOR_SIZE_INFORMATION-structured buffer. The FileSystemEffectivePhysicalBytesPerSectorForAtomicity member will not have a value initialized by the file system when this structure is returned from FsRtlGetSectorSizeInformation. A file system driver will typically call this function and then set its own value for FileSystemEffectivePhysicalBytesPerSectorForAtomicity.
Your principal error is that you try to get physical sector size from a volume handle rather than from that of an underlying physical device (\\.\PhysicalDriveX). Device's physical sector size doesn't depend on FS and shouldn't be confused with a logical sector size defined by FS properties.

CUPS returns 'complete' on jobs which are still printing

I am communicating with CUPS using IPP protocol. I have all drivers for my printers installed in CUPS (using .ppd file) and printers got latest firmware.
When I query a job which a printer printing right now it says that the job's state is 'complete' before the printer even finish printing. It seems that the CUPS marks the job as 'complete' when it finish 'uploading' the file.
I would not expect this behaviour and I basically need to know when exactly the printer printed last paper for a job.
The code looks as follow. The self.printer().ippPrinter() is an instance of node-ipp and it points to a printer. To read the the state of the job I am using attribute 'job-state'.
var msg = {
"operation-attributes-tag": {
'job-id': id
}
};
self.printer().ippPrinter().execute("Get-Job-Attributes", msg, function(err, res){
var attributes = res['job-attributes-tag'];
self.setAttributes = attributes;
callback.call(self, attributes);
});
Does anyone know why I am having this issue or .. how to make it working?
Thank you!
CUPS can only forward job-states received from the printer. A lot of printer drivers and protocols work like 'fire and forget'.
Usually IPP printers allow CUPS and other clients to monitor the current job-state until it's finished/printed. Some manufacturers don't implement IPP properly and classify submitted jobs as printed - even if the printer has a paper jam!
Conclusion:
If your printer does not fully support IPP you probably won't be able to check for 'printed successfully'.
RFC 8011 5.3.7.1
If the implementation is a gateway to a printing system that never provides detailed status about the Print Job, the implementation MAY set the IPP Job’s state to ’completed’, provided that it also sets the ’queued-in-device’ value in the Job’s "job-state-reasons" attribute
#Jakub, you may well be communicating with CUPS using IPP... But are you sure that CUPS is communicating with the print device via IPP?
You can check this by running
lpstat -h cupsservername -v
This should return the device URI assigned to each print queue, which CUPS uses to address the actual printing device:
If that URI does contain ipp://, ipps://, http:// or https:// CUPS indeed talks IPP to the print device and you should be able to get actually correct status messages.
But if you see socket:// then CUPS is configured to use the AppSocket method (sometimes also called 'HP Jet Direct' or 'IP Direct Printing') to forward jobs. This is a "fire and forget" protocol. Basically it is the same as if you did run netcat print-device 9100 < myprintfile to shovel the printable data to port 9100 of the printer. The CUPS socket backend handling this spooling to the printer will not get any other acknoledgement from the printer than what TCP/IP provides confirming that the last packet was transfered. Hence it has to close down its process and report to the CUPS daemon successful-ok, even if the printer is still busy spitting out lots paper and will maybe never complete the full job because it runs into a paper jam...
If you see lpd:// the situation is similar (but uses port 515).
You may have success with a full status reporting by switching the CUPS-to-printdevice path from AppSocket or LPD to IPP like so:
sudo lpadmin -p printername ipp://ipaddress-of-printer
or
sudo lpadmin -p printername http://ipaddress-of-printer:631

How to get Excel version and macro security level

Microsoft has recently broken our longtime (and officially recommended by them) code to read the version of Excel and its current omacro security level.
What used to work:
// Get the program associated with workbooks, e.g. "C:\Program Files\...\Excel.exe"
SHELLAPI.FindExecutable( 'OurWorkbook.xls', ...)
// Get the version of the .exe (from it's Properties...)
WINDOWS.GetFileVersionInfo()
// Use the version number to access the registry to determine the security level
// '...\software\microsoft\Office\' + VersionNumber + '.0\Excel\Security'
(I was always amused that the security level was for years in an insecure registry entry...)
In Office 2010, .xls files are now associated with "“Microsoft Application Virtualization DDE Launcher," or sftdde.exe. The version number of this exe is obviously not the version of Excel.
My question:
Other than actually launching Excel and querying it for version and security level (using OLE CreateOLEObject('Excel.Application')), is there a cleaner, faster, or more reliable way to do this that would work with all versions starting with Excel 2003?
Use
function GetExcelPath: string;
begin
result := '';
with TRegistry.Create do
try
RootKey := HKEY_LOCAL_MACHINE;
if OpenKey('SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe', false) then
result := ReadString('Path') + 'excel.exe';
finally
Free;
end;
end;
to get the full file name of the excel.exe file. Then use GetFileVersionInfo as usual.
As far as I know, this approach will always work.
using OLE CreateOLEObject('Excel.Application'))
you can get installed Excel versions by using the same registry place, that this function uses.
Basically you have to clone a large part of that function registry code.
You can spy on that function call by tools like Microsoft Process Monitor too see exactly how does Windows look for installed Excel - and then to do it exactly the same way.
You have to open registry at HKEY_CLASSES_ROOT\ and enumerate all the branches, whose name starts with "Excel.Application."
For example at this my workstation I only have Excel 2013 installed, and that corresponds to HKEY_CLASSES_ROOT\Excel.Application.15
But on my another workstation I have Excel 2003 and Excel 2010 installed, testing different XLSX implementations in those two, so I have two registry keys.
HKEY_CLASSES_ROOT\Excel.Application.12
HKEY_CLASSES_ROOT\Excel.Application.14
So, you have to enumerate all those branches with that name, dot, and number.
Note: the key HKEY_CLASSES_ROOT\Excel.Application\CurVer would have name of "default" Excel, but what "default" means is ambiguous when several Excels are installed. You may take that default value, if you do not care, or you may decide upon your own idea what to choose, like if you want the maximum Excel version or minimum or something.
Then when for every specific excel branch you should read the default key of its CLSID sub-branch.
Like HKEY_CLASSES_ROOT\Excel.Application.15\CLSID has nil-named key equal to
{00024500-0000-0000-C000-000000000046} - fetch that index to string variable.
Then do a second search - go into a branch named like HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer ( use the fetched index )
If that branch exists - fetch the nil-named "default key" value to get something like C:\PROGRA~1\MICROS~1\Office15\EXCEL.EXE /automation
The last result is the command line. It starts with a filename (non-quoted in this example, but may be in-quotes) and is followed by optional command line.
You do not need command line, so you have to extract initial commanlind, quoted or not.
Then you have to check if such an exe file exists. If it does - you may launch it, if not - check the registry for other Excel versions.

Resources