<div dir="ltr">Wow great catch...the date value of your hex conversion corresponds with what I see in dhcpd.leases.<br>I can try and script for this, but should a bug be filed, or could this be a terminal issue (I get same result from console terminal and xterm/ssh session)?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 12:09 PM Rick Dicaire <<a href="mailto:kritek@gmail.com">kritek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Wow great catch...the date value of your hex conversion corresponds with what I see in dhcpd.leases.<div>I can try and script for this, but should a bug be filed, or could this be a terminal issue (I get same result from console terminal and xterm/ssh session)?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 8:32 AM Bruce Hudson <<a href="mailto:Bruce.Hudson@dal.ca" target="_blank">Bruce.Hudson@dal.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> ends = "_sz-"<br>
> starts = 5f:72:d1:6d<br>
<br>
> As shown above, 'ends' field does not have a hex value.<br>
> Any thoughts as to what's causing this?<br>
<br>
    I suspect this is just an anomaly cause by omshell's more<br>
generic output algorithm. Because all four bytes of the ends<br>
value correspond to printable characters, it displays it as<br>
a string instead of the raw octects. A (failed in this case)<br>
effort to be more user friendly.<br>
<br>
    Looking at the ord's of the four characters in hex:<br>
<br>
        "_sz-" ==> 5f:73:7a:2d<br>
-- <br>
Bruce A. Hudson                         | Bruce.Hudson@Dal.CA<br>
ITS, Networks and Systems               |<br>
Dalhousie University                    |<br>
Halifax, Nova Scotia, Canada            | (902) 494-3405<br>
</blockquote></div>
</blockquote></div>