I have a number of capture files that I am trying to merge. The merge files are from linux servers (both Ubuntu and Centos), a Macbook Pro and from a Windows machine. They all play nice with the exception of the mac dump.
But when I try to merge the files from the mac I get this error:
"mergecap: Record 222 of "scenario_4_mbp.pcap" has an interface ID which does not match any IDB in its file."
I looked at the specific packet and it is a Dropbox LAN sync Discovery Protocol. For my purposes I don't even care about it, and I would just as soon like to filter it out but I cannot seem to get the filter correct.
I tried to filter with:
ip.proto != db-lsp-disc
ip.proto not db-lsp-disc
but I get an error and nothing is filtered.
Assuming I am able to apply a display filter how do I save the file sans the dropbox packets? And ultimately, will this solve my merge issue?
I can read and open the file just fine with Wireshark, but I cannot merge it with the other files from the scenario.
Then this is probably a bug in mergecap. Please file a bug on the Wireshark Bugzilla, and, if possible, attach to the bug capture files that demonstrate the bug.
I have the same problem, and the offending file in my case was also created with tcpdump on a MacOS machine.
I was able to solve the problem by opening the offending file in Wireshark, which has no problem with it, then doing a "Save As" into a new .pcapng file, then running mergecap again replacing the offending file with the newly created copy.
Saving as a regular .pcap file seemed to work, too, but there are comments in the file (interface names, at least) that regular .pcap strips out.
Related
I am using Ghostscript to convert pdf1.3 to pdf/a-1b using this command:
gs -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE -sColorConversionStrategy=sRGB -sDEVICE=pdfwrite -sOutputFile=output.pdf PDFA_def.ps input.pdf
The PDFA_def.ps is customized to use the srgb icc profile. Except that change it is the standard def file which comes with GS 9.26.
Now comes the tricky part:
1- running this conversion locally on a ubuntu 18.10, GS 9.26 it works fine an i get a valid pdf/a
2- running the same command in a docker container (ubuntu 18.10. GS 9.26) creates a pdf/a as well, which is considered to be valid
However, in the first scenario I can process the file using mustang (https://github.com/ZUGFeRD/mustangproject) to create a valid electronic invoice. In the second scenario (docker container) this fails, since the file is not considered to be valid pdf by mustang.
checking both pdf files I would have expected them to be identical since i am running the same converison on it. However they are not. The PDF create in the dockerfile is 10 bytes smaller and shows some different metainformation in the file itself.
I suspect that there must be some "hidden depdencies" that make GS to act different on my host system compared to a docker container, but it feels entirely wrong and I am running out of means to debug further.
Does anyone know, wether GS has some more depdencies that might cause the same command to produce different results?
The answer is 'maybe'. It depends on how Ghostscript was built for starters.
I assume you are using a package, and not building from source yourself. In which case there are a number of dependencies including; FreeType, LibJPEG, JBIG2dec, LibTIFF, JPEG-XR, LCMS2, LibPNG, OpenJPEG, Expat, zlib, potentially IJS, CUPS and X-Windows, depending on what devices were built in.
Any or all of these could be system shared libraries instead of being built using the specific version shipped by Artifex. They could also be different versions on the two systems.
That said, I think its 'unlikely' that this is your problem. However, without seeing the PDF files I can't tell you why there is a difference. Differences in the metadata are to be expected, since that includes a date/time stamp.
I'd really need to see examples of the original and the two output PDF files to be able to comment further.
[Edit]
Looking at the files they have been produced compressed (unsurprisingly) which can obviously lead to differences in size if there are small differences in the input streams. So the first task was to decompress the files.
That done I see there are, essentially, no differences between them. One of the operating systems is using a time zone 7 hours behind UTC, the other is in UTC so where one of the systems is time stamping with (eg)
2019-04-26T19:49:01Z
The other is using
2019-04-26T12:51:35-07:00
So instead of Z (for UTC) you get -07:00 which is where the extra 10 bytes are coming from. Other than that, the Unique IDs are (as you would imagine) different, the Length values for the streams are different for the streams containing dates, and the startxref is different because the streams are different lengths.
Both files claim to be compatible with PDF/A-1b. In short I can see no real differences between them. Since you are using a tool to further process the files, I'd suggest you try taking the PDF file from your working system and try processing it on the non-working system, and vice versa, it seems to me that the problem may be the later processing rather than the PDF file itself. Perhaps you have different versions of that tool on the two systems.
For what it may be worth, Ghostscript can be induced into creating a ZUGFeRD file directly, see this bug report and this commit to the repository.
I have a configuration using a Linux Jenkins master and a Windows 10 slave. I'm using it to do an msbuild operation on the slave and generate an install executable as an artifact. I have this working on a Jenkins Windows 10 master system (same one I'm using as a slave), and this all works fine. However, when I run the same job remotely I get the dreaded "CS1031" error:
Properties\AssemblyInfo.cs(1,1): error CS1031: Type expected [C:\slave2Workspace\workspace\SDB Projects\CCMonitor\CCMonitor\CCMonitor\CCMonitor.csproj]
This is pointing at the first character in the file. If I omit the job step with the Change Assembly Info plugin, everything works fine and I get the output correct. What I found was that the AssemblyInfo.cs file was missing the characters 0xEB 0xBB at the front of the file -- these somehow got dropped in the translation. Sounds like a character set issue, but it is only an issue with this plugin step.
Is there something that needs to be configured differently?
thanks!!
So I had this same issue today and found the solution. Not sure if you ever figured this one out, so I wanted to drop the solution just in case.
Turned out to be an encoding issue. The assembly file is encoded UTF-8 with signature. As a workaround to avoid the characters being added to the beginning of the file, change the encoding to UTF-8 without signature.
I did this by opening the files in notepad++ and then selecting Encoding -> Encode in UTF-8
If you are working with Visual Studio (2017 in my case)
Open the file with the problem
Select File | Save As
On the Save button there is drop down with option stating Save with Encoding
In the list with encodings select UTF-8 without signature
VS may tell you that there is already such file, you select to overwrite it.
Commit>Push with your source control (git in my case), and voila - that's it.
After capturing some packets with Wireshark, I want to keep record of them i.e: I want to generate a binary file with the captured packets. Therefore I click on:
File -> Save as
among the different extensions, you can select "Visual Networks traffic capture (.)" which apparently generate a binary file without extension.
I have been unsuccessfully looking for more info about this type on Internet. Can somebody tell me what is this extension? Is this file format compatible either with Windows and Linux?
Thanks.
Those files are from software from a company called Visual Networks:
http://web.archive.org/web/20010119000200/http://www.visualnetworks.com/
Fluke bought them in 2005:
http://www.washingtonpost.com/wp-dyn/content/article/2005/12/02/AR2005120201910.html
and they now appear to be owned by NetScout - if you try going to http://www.visualnetworks.com, you end up at NetScout's site.
The files are from their Visual UpTime software; support for those files was added back in 2001.
I can't find the documentation on any of their possibly-now-no-longer-offered software, so I don't know whether they put a standard extension on the files. Some of the files I have, from bugs and e-mail messages, have the extensions ".vn", ".cap", ".pkt", and ".vis", so I don't know which, if any, of those are the "standard" extension.
So Wireshark doesn't know what extension to put on the files, and doesn't provide one.
Extensions aren't "compatible" with OSes. File formats are compatible with programs that read the files; Wireshark can read Visual Network files on all OSes on which it runs. And there isn't an extension for those files, anyway.
The Windows and OS X desktop environments tend to recognize file formats based on extensions, so, without an extension, you probably won't be able to open a file by double-clicking on it. Some free-software desktop environments used on OSes such as Linux may also look at the beginning of the file to determine the file type, and would be OK with files without an extension, and newer versions of the database they use have an entry for Visual Networks files - but they don't have a MIME media type for them, so Wireshark can't register as the reader for those files, so double-clicking probably won't work there, either.
So, to open one of those files from the GUI, you'd have to use the File -> Open menu item in Wireshark, or anything else in the GUI that lets you say "open this file with this program".
However, the native file formats for Wireshark are pcap and pcapng, and if you've captured traffic with Wireshark, you should really save them in pcap or pcapng format unless you want to read the capture in a program that doesn't understand pcap or pcapng but does understand some other format that Wireshark can write.
When I plug my IPhone (6 Plus) to my Windows computer, I see some "Local Storage" (named in Turkish "Yerel Disk") icons in DCIM folder. Any idea what are these, could it be viruses??
There might be a possible answer.
https://discussions.apple.com/thread/6585223?start=15&tstart=0
I have the same problem. And I didn't remember my photos were altered (cropped, photo filters applied, etc.) at all.
For the solution of removing those mystery files:
Disconnect IPhone with Windows machine
Settings --> Safari --> Clear History and Website Data
reconnect IPhone with Windows machine, double check DCIM and subfolders.
Then they disappear.
*** The above solution works for me. But the solution makes those files even more mystery. Why deleting Safari related Data (I assume "Clear History and Website Data" does the function as it described) could clean files inside DCIM ? ( Another assumption: files inside DCIM are photos related. Actually not sure)
The only technical details I find is a comment in https://discussions.apple.com/thread/6585223?start=15&tstart=0
"""
Lawrence Finch
Mar 14, 2015 5:39 PM
Re: Windows explorer see's multiple "Local Disk" files in the iphone DCIM folders
in response to CrazyRoadBiker
CrazyRoadBiker wrote:
(PS - I managed to look inside of some of the "local disk" files and they seem to contain a modified XML structure. Why Apple doesn't just put an XML file in the folder that is standard and able to be recognized by Windows, I have no idea. . .)
The metatdata files are a standard image metadata format (.AAE), and Windows understands it. But you have to use the Camera and Scanner wizard to import the images. It understands those files, but Windows Explorer does not.
"""
So...
recently, My company need me to do something on application cache, and I read this article: http://www.codemag.com/Article/1112051, I followed his steps,but it cannot work by using vs2013, it will show you the right page, but when you press f12 in chrome, it will show some error:Application Cache Error event: "Failed to parse manifest localhost:xxxxx/Home/manifest", and actually app cache didn't work. but when I use vs2010 it works just fine! since vs2013 has a lot more files in the mvc project, I cannot figure out what's wrong. Now I need some vs2013 tools which are not included in vs2010, so I really need the vs2013 version of this app cache program. It's quite in a hurry, can anyone help me? thanks a lot!
Please follow these steps to see if it helps.
Step 1: Run Windows System File Checker("sfc /scannow")
It allows you to scan for file corruption and restore Windows system files such as DebuggerProxy.dll. If System File Checker finds a problem with DebuggerProxy.dll or other critical system file, it will attempt to replace the problematic files from DLL Cache (%WinDir%\System32\Dllcache). If the DebuggerProxy.dll file is not in the DLL Cache, or the DLL Cache is corrupted, you will be prompted to insert the Windows installation disc to recover the original files.
To run System File Checker:
1.Click the Start button.
2.Type "cmd" in the search box... DO NOT hit ENTER yet!
3.While holding CTRL-Shift on your keyboard, hit ENTER.
4.You will be prompted with a permission dialog box.
5.Click Yes.
6.A black box will open with a blinking cursor.
7.Type "sfc /scannow" and hit ENTER.
8.System File Checker will begin scanning for DebuggerProxy.dll and other system file problems (be patient - the system scan may take a while).
9.Follow the on-screen commands.
Step 2:Make sure your ISO installation file is correct.
You can download the ISO file from the website below.
http://www.microsoft.com/en-hk/download/details.aspx?id=40787]
Before you install it, I suggest you use this tool http://support.microsoft.com/kb/841290 to verify hash of the ISO. Any discrepancy would indicate that the file was corrupted. Here is a blog about how to use the tool.
The sha1 value of ISO is "E61419E51F42254EE07DECF628B85C9861286250".
Then try reinstall it.