Guy Harris
changed
bug 9202
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
CONFIRMED
|
| Hardware |
x86
|
All
|
| Ever confirmed |
|
1
|
| OS |
Windows 7
|
All
|
| Severity |
Major
|
Enhancement
|
Comment # 1
on bug 9202
from Guy Harris
There are two issues here:
1) a latent bug, where the padding is calculated incorrectly for the
"hardware" option in the SHB, which is currently not a problem but would be
exposed if the second issue is fixed;
2) an enhancement request, asking for an shb_hardware option to be put into
the SHB.
The former's been fixed in the trunk with r52273, so this bug is for the second
issue.
The pcap-ng spec is a bit vague on it:
An UTF-8 string containing the description of the hardware used to create
this section.
with examples of
"x86 Personal Computer" / "Sun Sparc Workstation" / ...
Such an option would be more likely to say "x86 Personal Computer" or
"{x86-64,AMD64,x64,...} Personal Computer" than "PC-mike". "PC-mike" sounds
more like an shb_hostname option, unless "mike" is part of the hardware. :-)
On Macs, a raw model code can be gotten as the hw.model sysctl, e.g.
"MacBookPro10,1". There may be ways of either getting the "marketing name"
from the OS or converting a model code to a "marketing name", e.g. "MacBook Pro
(Retina, 15-inch, Early 2013)"
There may be similar mechanisms on SPARC-based machines from Sun^WOracle.
On random PCs running {Windows,Linux,*BSD,Solaris,Hackintoshed OS X, etc.},
that's another matter - and that's the most likely case.
Another possibility would be to try to get a count of CPU cores, the clock rate
of the cores, perhaps the type of the cores, and the amount of main memory, or
something such as that (perhaps also some summary of the secondary storage
subsystem).
You are receiving this mail because:
- You are watching all bug changes.