The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,909 other followers

Archive for the ‘HEX encoding’ Category

Hardware MAC address formats (which I need for Wake-on-LAN.ps1)

Posted by jpluimers on 2022/07/06

Early june, I blogged about Wake-on-LAN from a Windows machine.

My plan was to adopt [Wayback/Archive.is] Wake.ps1 into Wake-on-LAN.ps1 (as naming is important).

One of the goals was to support multiple hardware MAC address formats, especially as Wake.ps1 had the below comment, but did support the AA-BB-CC-DD-EE-FF, though not the AA:BB:CC:DD:EE:FF hardware MAC address format:

<#
...
.NOTES
Make sure the MAC addresses supplied don't contain "-" or ".".
#>

A colon separated hardware MAC address would result in this error inside the call to the [Wayback/Archive.is] PhysicalAddress.Parse Method (System.Net.NetworkInformation) | Microsoft Docs:

Send-Packet : Exception calling "Parse" with "1" argument(s): "An invalid physical address was specified."

So I did some digging, starting inside the above mentioned blog post, and adding more:

  1. Wake.ps1 uses the [Wayback/Archive.is] Parse method in the [Wayback/Archive.is] PhysicalAddress.cs source code in C# .NET,  which contains code like this:
                //has dashes? 
                if (address.IndexOf('-') >= 0 ){ 
                    hasDashes = true;
                    buffer = new byte[(address.Length+1)/3]; 
                }
  2. The Perl script at [Wayback/Archive.is] wakeonlan/wakeonlan at master · jpoliv/wakeonlan that started my first blog post in this series which mentions:
    • xx:xx:xx:xx:xx:xx (canonical)
    • xx-xx-xx-xx-xx-xx (Windows)
    • xxxxxx-xxxxxx (Hewlett-Packard switches)
    • xxxxxxxxxxxx (Intel Landesk)

    I should rename the first one IEEE 802, as per this:

  3. The MAC address: Notational conventions – Wikipedia

    The standard (IEEE 802) format for printing EUI-48 addresses in human-friendly form is six groups of two hexadecimal digits, separated by hyphens (-) in transmission order (e.g. 01-23-45-67-89-AB). This form is also commonly used for EUI-64 (e.g. 01-23-45-67-89-AB-CD-EF).[2] Other conventions include six groups of two hexadecimal digits separated by colons (:) (e.g. 01:23:45:67:89:AB), and three groups of four hexadecimal digits separated by dots (.) (e.g. 0123.4567.89AB); again in transmission order.[30]

    The latter is used by Cisco (see for instance [Wayback/Archive.is] Cisco DCNM Security Configuration Guide, Release 4.0 – Configuring MAC ACLs [Support] – Cisco and [Wayback/Archive.is] Cisco IOS LAN Switching Command Reference – mac address-group through revision [Support] – Cisco), so another format to add:

    • xxxx.xxxx.xxxx (Cisco)
  4. [Wayback/Archive.is] PhysicalAddress.Parse Method (System.Net.NetworkInformation) | Microsoft Docs remarks:

    The address parameter must contain a string that can only consist of numbers and letters as hexadecimal digits. Some examples of string formats that are acceptable are as follows:

    • 001122334455
    • 00-11-22-33-44-55
    • 0011.2233.4455
    • 00:11:22:33:44:55
    • F0-E1-D2-C3-B4-A5
    • f0-e1-d2-c3-b4-a5

    Use the GetAddressBytes method to retrieve the address from an existing PhysicalAddress instance.

  5. After a bit more digging via [Wayback/Archive.is] “three groups of four hexadecimal digits separated by dots” – Google Search , I found that even more hardware MAC address formats are in use as per [Wayback/Archive.is] What are the various standard and industry practice ways to express a 48-bit MAC address? – Network Engineering Stack Exchange.

    I really do not have all the sources for the various representations for 48-bit MAC addresses, but I have seen them variously used:

    AA-BB-CC-DD-EE-FF
    AA.BB.CC.DD.EE.FF
    AA:BB:CC:DD:EE:FF
    AAA-BBB-CCC-DDD
    AAA.BBB.CCC.DDD
    AAA:BBB:CCC:DDD
    AAAA-BBBB-CCCC
    AAAA.BBBB.CCCC
    AAAA:BBBB:CCCC
    AAAAAA-BBBBBB
    AAAAAA.BBBBBB
    AAAAAA:BBBBBB

From the last list, which is far more complete than the others, I recognise quite a few from tools I used in the past, but too forgot the actual sources, so I took the full list from there and tried to name them in parenthesis after the links I found above and what I remembered:

  • AABBCCDDEEFF (Bare / Landesk)
  • AA-BB-CC-DD-EE-FF (IEEE 802 / Windows)
  • AA.BB.CC.DD.EE.FF (???)
  • AA:BB:CC:DD:EE:FF (Linux / BSD / MacOS)
  • AAA-BBB-CCC-DDD (???)
  • AAA.BBB.CCC.DDD (Cisco?)
  • AAA:BBB:CCC:DDD (???)
  • AAAA-BBBB-CCCC (???)
  • AAAA.BBBB.CCCC (Cisco / Brocade)
  • AAAA:BBBB:CCCC (???)
  • AAAAAA-BBBBBB (Hewlett-Packard networking)
  • AAAAAA.BBBBBB (???)
  • AAAAAA:BBBBBB (???)

Some additional links in addition to the ones above:

–jeroen

Posted in .NET, CommandLine, Development, Encoding, HEX encoding, Network-and-equipment, Power User, PowerShell, PowerShell, Scripting, Software Development | Leave a Comment »

including enumerations and JPEG compression examples for wPDF 4 Manual: Compression related properties

Posted by jpluimers on 2019/04/11

Since I was tracking down an issue having to to with generating DIB in a compressed PDF: [Archive.is] wPDF 4 Manual: Compression related properties

Property CompressStreamMethod

By modifying this property you can let the PDF engine compress (deflate) text. By using compression the file will be reasonable smaller. On the other had compression will create binary data rather than ASCII data. While “deflate” produces the smallest files, “run-length” compression is compatible even to very old PDF reader programs.

Property JPEGQuality

wPDF can compress bitmaps using JPEG. This will work only for true color bitmaps (24 bits/pixel) and if you have set the desired quality in this property.

Property EncodeStreamMethod

If data in the PDF file is binary it can be encoded to be ASCII again. Binary data can be either compressed text or graphics. You can select HEX encoding or ASCII95 which is more effective then HEX.

Property ConvertJPEGData

Note: Only applies to TWPDFExport.

If this property is true JPEG data found in the TWPRichText editor will not be embedded as JPEG data. Instead the bitmap will be compressed using deflate or run length compression. It is necessary to set this property to TRUE if the PDF files must be compatible to older PDF reader programs which are incapable to read JPEG data.

Note that EncodeStreamMethod does not do compression, but it does belong here because the encodings result in different PDF sizes.

The settings are not documented in more detail, so here are the enumerations explaining them in a bit more depth:

–jeroen

Posted in ASCII95, Delphi, Development, Encoding, HEX encoding, Software Development | Leave a Comment »

 
%d bloggers like this: