That's extremely strange.  Is this a wired connection or wireless?  Does the unit work if you assign it a static IP?  Have you tried doing a factory reset by holding down the "+" button on the remote while connecting the power?

I assume from your message that it had been working okay for some time with firmware 58 or earlier?

This is over a wired connection.  Note, moreover, that it does successfully
DHCP; i.e., it's request is honored and it receives an address assignment
from the DHCP server -- a Cisco 1721 router.  However, as I noted the
router is showing that the transmitted client-id / mac address / user name
is that ASCII string I reported.....  Not too sure what would happen if I
had two Squeezebox 3's on the same net as the high end of the MAC
address for both would likely be the same and as such what the Cisco
sees as the MAC address would likely be the same for the two devices.

If I tell it to use a static IP, it works fine.

As to a factory reset, I did that just now at your request.  Wired ethernet,
and use DHCP.  It got an address assignment (10.30.0.44) and here's
what I see on the Cisco:

router#show ip dhcp binding 
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
10.30.0.44   5371.7565.657a.6562.    Aug 02 2006 10:17 AM    Automatic
                    6f78.2f30.3030.3432.
                    3030.3642.3136.30

10.30.0.46   0100.0740.c6cf.3d       Aug 01 2006 02:39 PM    Automatic

So, same behavior.

The Squeezbox 3 had been doing more sane DHCP before sending it's
MAC as its MAC.  It's a brand new Squeezebox 3 which was sent to me
from SlimDevices last wednesday.  I don't know offhand which rev. of
the firmware it had -- whatever your shipping/fulfillment folks have
in the units on the shelf.

I'll grab a tcp dump in a minute and add it to this bug report.

Here's some Cisco IOS "debug ip dhcp server packet" and "... events" output from the DCHP server (Cisco 1721)

009087: Aug  1 10:33:48.731 PDT: DHCPD: DHCPDISCOVER received from client 5371.7565.657a.6562.6f78.2f30.3030.3432.3030.3642.3136.30 on interface FastEthernet0.
009088: Aug  1 10:33:48.731 PDT: DHCPD: Sending DHCPOFFER to client 5371.7565.657a.6562.6f78.2f30.3030.3432.3030.3642.3136.30 (10.30.0.44).
009089: Aug  1 10:33:48.735 PDT: DHCPD: broadcasting BOOTREPLY to client 0004.2006.b160.
009090: Aug  1 10:33:49.739 PDT: DHCPD: DHCPREQUEST received from client 5371.7565.657a.6562.6f78.2f30.3030.3432.3030.3642.3136.30.
009091: Aug  1 10:33:49.739 PDT: DHCPD: Sending DHCPACK to client 5371.7565.657a.6562.6f78.2f30.3030.3432.3030.3642.3136.30 (10.30.0.44).
009092: Aug  1 10:33:49.739 PDT: DHCPD: broadcasting BOOTREPLY to client 0004.2006.b160.
009093: Aug  1 10:33:52.007 PDT: DHCPD: DHCPINFORM received from client 0049.6e74.6572.4d61.7070.6572 (10.30.218.163).
009094: Aug  1 10:33:52.007 PDT: DHCPD: Sending DHCPACK to client 0049.6e74.6572.4d61.7070.6572 (10.30.218.163).
009095: Aug  1 10:33:52.007 PDT: DHCPD: unicasting BOOTREPLY to client 0003.ba21.f7c5 (10.30.218.163).

Let me know if you want the raw TCP packet dump also: I have it. 

Created attachment 1391 [details]
TCP packet trace of DHCP dialog between Squeezebox 3 v59 and Cisco 1721

Hi Dan, you are seeing a new dhcp feature that was added to the firmware since version 56. The dhcp request now includes a client-id and vendor-id in the lease request, this is the information you are seeing on your router/packet dump. Please see bug 1264 and bug 2738 for more details.

Richard

I understand what you're saying.  However, inspection of the TCP packet dump shows there
to be a problem nonetheless.  Specifically the "Type" subfield is missing from the client-identifier
field.  The packet dump shows

    0x3d -- client identifier code
    0x17 -- length of client identifier (23 bytes)
    --- single byte "Type" field missing ---
    "Squeezebox/..."

See Section 19.4 of RFC 2132 for further details.  A "Type" field of 0x00 is probably what
you want.

FWIW, the entire DHCP request decomoses as

   0x35 0x01 0x01  --> DHCPDISCOVER (Section 9.6)
   0x3d 0x17 "Squeezebox/..." --> Client identifier (Section 9.14)
   0x3c 0x0b "SlimDevices" --> Vendor class identifier (Section 9.13)
   0x37 0x03 subnet mask option, router option, dns option --> Parameter Request List (Sect 9.8)

P.S. I suppose that technically, the "Type" field is not missing and instead is an "S" and the client
      identifier is "queezebox/<ascii-fied MAC>".  However, going by RFC 2132 a type of 0x00
      should be used when the identifier contains a value other than a hardware address (as
      is the case here).  At any rate, when I configure my DHCP server to assign a static IP based
      upon the client identifier "queezebox/00042006B160" it works.

P.P.S. I'd recommend against putting a 0x00 in the Type field and continue doing what you're doing
         until such time that someone reports a serious problem with their DHCP server hating 0x53 ('S')
         as the Type field.  For example, I can live with my Cisco disliking the type field ad generting some
         suboptimal / misleading (to me) log warnings as long as the Cisco will still process the requqest
         and hand out a DHCP assignment.  What I'd hate to see is you change it to be a 0x00 as per the
         RFC and then get bit by someone's DHCP server treating the Type field as part of the client identifier
         itself and then seeing it as a NUL terminator and thinking that the client identifier is an empty string.

I'm misquoting RFC 2132 when I read it to say that the
Type should be 0x00.  It's referring to the "hardware
type" when you use the client identifier field for an
RFC 951 (BOOTP) htype/chaddr style field.  Looks like
RFC 2132 gives no guideance whatsoever on what to set
for the Type field in general and is possibly ambiguous
in thhe type-value pair case (i.e., which "type" --lower
case "t" -- do they mean: "hardware type" or Client-identifier
"Type").  So, lacking any guideance whatsoever from the
RFC, I'd say there's nothing wrong at all with the
Squeezebox using "S" for it's type field.  No harder
to manage than the hardware/media types used in BOOTP.

Anyhow, thanks for looking at this one.

This problem has bitten one customer:

As per forum post: http://forums.slimdevices.com/showthread.php?t=25633

MikeGilpin Wrote:

I upgraded to 6.5b1 (build 8964) running on Mac OSX in hopes of better behavior on synch over 6.3.1. After applying the firmware 59 updates I started seeing odd behavior:

1) Works OK with 1 SB2 player.
2) Adding any second player, the players start conflicting with one another on the network. Their displays go dark, then come back.

I checked the DHCP table on the router and learned of an interesting problem, which I saw something similar mentioned for firmware 58, so thought I should point out that the issue still exists. Multiple players are getting the same IP address, whereas on earlier pre-58 releases I was getting correct behavior.

My configuration is a wired network. The player settings for the one player currently connected show that it has a Mac ID which is normal (which in earlier firmware releases would be the same one I would see in the router's DHCP table). Now, the DHCP table shows a weird Mac ID for this player of 717565657A65626F782F303030343230, even though the player info through the browser interface still shows its original normal Mac ID.

When I add a second player, no additional DHCP entry appears.

Running with one player, music seems to play normally.

I had seen behavior like this before when attempting to upgrade to July-timeframe 6.5b1s, but didn't take the time to troubleshoot what was happening, just went back to 6.3.

Note that my Mac on which SlimServer is running has a fixed IP address. The players don't have any trouble finding it, as had been reported in firmware 58. But I mention this because it could be related in some strange way, I suppose.

The reason I have a fixed IP address for the Mac is that in earlier releases of the software, it tended to work better that way - more reliably sustaining network connections to and from the Mac. This was important because my music is stored on a separate NAS device.

MrC Wrote:

For what its worth, that ASCII string looked familiar to me. It reads:

"queezebox/000420"

Thanks, Mike Cappella, for posting my issue here. Reading through, this appears to be exactly the problem I'm having. One other piece of information that's relevant: all four of my SB2 players have MAC addresses starting in 00:04:20 (which is probably not that uncommon), so that's why the router thinks it's being asked for an IP address for the same device each time this garbled string is sent. It's the same string.

You're welcome.

FYI - All Ethernet devices have a prefix.  Slims's is 00:04:20.  You can look this up in:

http://standards.ieee.org/regauth/oui/index.shtml

search for 000420 in the first field.

Could people effected by this bug please post what routers the are using. Thanks.

I have the D-Link DI-604 router with 2005-era firmware on it. Verizon provides it for use with their FIOS internet service. I have this router configured as the DHCP server.

I have another router between the DI-604 and my network, with its DHCP server turned off, because it has a pretty good built-in firewall (better than the D-Link's). It's a Netgear FR114P. However, I have tested with this removed from the network, and it didn't fix the problem. So I put it back in.

Cisco 1721 VPN/K9 with IOS 12.3(10).

1. Anonymous assignment of an IP address to a single SB3 works okay.

2. Recognizing the DHCP client (SB3) and assigning an IP based
   upon that recognition works, but I had to configure the Cisco to
   match based upon the client ID and not the MAC address.  The match
   specifies the full 23 bytes (0x17) of the client id.  Dunno myself
   if the Cisco is using all 23 bytes or truncating it. I'm not aware of
   any length limit imposed on that field by the Cisco and a quick inspection
   of the IOS docs didn't indicate any.  Obviously, truncation would be
   relevant if it were happening.  Workarounds would either be to put
   the MAC address to the front of the client id string instead of the
   end or to shorten the non-unique part of the string at the front of
   the client id.  Again, I don't know if truncation is relevant here
   or not.

I only have one SqueezeBox so I cannot confirm or deny if the Cisco 1721
would have a problem with more than on SB client with either of the cases
above.  I'm happy to try if someone wants to loan me one for a day (S. Calif).

Dan, it does look like this is causing some people problems. I think I misunderstood the RFC. I have not checked again and just wondered if you could sanity check my understanding. 

The 'htype' should not be 'Squeezebox', but actually a numeric type from RFC 1700 page 163/164. And 'chaddr' should be the mac address in binary not ascii. So in the client-identifier field I should have 0x06 (IEEE 802 network), 0x00, 0x40, 0x20, 0x00, 0x00, 0x00 (where the last three digits are replace by the units mac address).

I'm also seeing problems with my Speedtouch 510v4 router.

My Client ID's for two Squeezeboxen (1 x v2 & 1 x v3) show up as:
 	
53:71:75:65:65:7a:65:62:6f:78:2f:30:30:30:34:32:30:30:35:41:31:33:33

53:71:75:65:65:7a:65:62:6f:78:2f:30:30:30:34:32:30:30:36:31:42:45:39

MAC addresses are reported correctly through Slimserver.

SlimServer Version: 6.5b1 - 8947 - Windows XP - EN - cp1252.

Both players function OK.

Richard

Assuming you meant this Dan and not dan@slimdevices.com, I'm not too sure what
to say.  RFC 2132 is, a little vague here.  In Section 9.14 it unambiguously
states in Paragraph 2

   Identifiers SHOULD be treated as opaque objects by DHCP servers.

As such, you should be able to put your favorite pizza joint's phone number
there if you want.  Then later in Paragraph 4 we're told that the identifiers
MUST be unique amongst the client identifiers presented on the same subnet.
So far, so good as reqards the SqueezeBoxen: they are honoring both of these
strongly, clearly stated requirements.

But then we have the third paragraph:

   The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
   hardware type of 0 (zero) should be used when the value field contains
   an identifier other than a hardware address (e.g. a fully qualified
   domain name).

 [3] - RFC 951, BOOTP
[22] - RFC 1700; the then current list of IANA assignments; see RFC 3232
       for info on the current "version" of RFC 1700.

Well, that's just a "MAY".  However, you may now be up against either
common practice, or, worse yet, that which you need to do to work with 99%
of the DHCP servers in the world: the good, the bad, and the ugly.

Now, on to your question.  From my limited experience, regardless of the MAY
of paragraph three, I always have seen client identifiers of the form

         0x01 <six byte MAC address in binary>

The 0x01 is, if I recall correctly, the media type -- in this case ethernet.
Not terribly useful of a client id IMO, but that's all I ever see in my limited
experience on the networks I work on (some nets within Sun and my own neighborhood
network as I'm the ISP for many of my neighbors here in the mountains).
Makes me worry if client id's are one of those things where in general they
aren't useful owing to the varied behavior of DHCP servers round the globe.

When I wrote that I've always seen client identifiers of the form

   0x01 <six byte MAC address in binary>

my point was that I had never seen client identifiers of any form
other than that until I encounted the SB3 with v59 firmware.  (I
never used v58.)

Is it possible to revert either

  1. Revert back to pre v58 behavior and then have an option to enable a player
     to send a "rich" client id (e.g., "Squeezebox/" + <ASCII MAC>), or

  2. Try sending the simpler, boring client id of 0x01 <6 byte MAC in binary> and
     have an option to enable a player to send a "rich" client id?

I mention the above as I understand that the transmission of a client ID was added
as fulfillment of a feature request.  So, hopefully, the "rich" client id is working
usefully for some subset of users.  Either of the above workarounds might enable you
to fallback to what worked for most everyone but still offer the feature to those who
can gainfully use it.

FWIW, at least one DHCP server software engineer tells me that for
maximum interoperability, if you use a client id then you should
stick to

       <1 byte htype> <MAC address in binary>

His experience was that there have been and may still be DHCP servers
which truncate the client id, presumably owing to memory constraints.

Perhaps it might be worth taking a look at the open souce Linksys router code to see how its handled there.

According to the ISC implementation of DHCP, the htype is 1.  This is set for all cases except for Token Ring (6) and FDDI (8).

includes/dhcp.h:#define HTYPE_ETHER  1               /* Ethernet 10Mbps              */
includes/dhcp.h:#define HTYPE_IEEE802        6       /* IEEE 802.2 Token Ring...     */
includes/dhcp.h:#define HTYPE_FDDI   8               /* FDDI...                      */

The hbuf hardware address field in the includes/dhcpd.h file indicates a 17 byte long sequence.  This would indicate an ASCII (not binary) representation of the MAC address.  The client code simply copies this hlen bytes of this data into the chaddr if hlen > 0.

Mike,

From my reading of the ISC DHCP code (v3.0.5), the client identifiers
built are either 7 or 17 bytes.  The are taken verbatim from hw_address.hbuf
and have a byte length of hw_address.hlen.  From the discover.c code, it looks
like hw_address.hbuf[0] set according to the media type -- the htype field.
The length, hlen, is 17 bytes when the media is FDDI; otherwise, it's always 7 bytes.
hw_address.hlen is set to either 7 or 17 and the hardware address is taken from
socket information (sa.sa_data), copied in binary, and either of length 6 or 16
bytes.  In either case, that hardware address (e.g., MAC address) is stuffed
into hw_address.hbuf starting at hbuf[1].  This data, hw_address.hbuf is then
used as the client identifier.  So, my very quick read of the ISC DHCP client v3.0.5
is that it sends a binary string with a binary MAC.  In the typical home
situation (ethernet), there will thus be a 7 byte long, binary client identifier
generated of the form

   0x01 <6 byte MAC in binary>

That there's a case where it's 17 bytes is interesting, but not many low-end
home routers are doing FDDI ;-)  Hopefully, any that do do not truncate to less
than 17 bytes....

Also, it doesn't look like the ISC DHCP client sends a client identifier
by default.  Looks like the hardcoded parameters the client asks for
are: routers, subnet mask, domain name servers, and host name.

Anyhow, that's just my cursory read which could be completely and totally
wrong.

Ah, I can see that the 17 bytes is simply the max size.  I was also reading common/tables.c for at dhcp-client-identifier which is of type "X", meaning ASCII or binary data.

   X - either an ASCII string or binary data.   On output, the string is
       scanned to see if it's printable ASCII and, if so, output as a
       quoted string.   If not, it's output as colon-seperated hex.   On
       input, the option can be specified either as a quoted string or as
       a colon-seperated hex list.

Anyway, there's a funny comment in common/parse.c

        /* Parse the hardware address information.   Technically,
           it would make a lot of sense to restrict the length of the
           data we'll accept here to the length of a particular hardware
           address type.   Unfortunately, there are some broken clients
           out there that put bogus data in the chaddr buffer, and we accept
           that data in the lease file rather than simply failing on such
           clients.   Yuck. */

I suppose this could now refer to squeezebox at firmware 59!

This bug is fixed in squeezebox2/3 firmware 60. You will be notified again when it is made part of
a nightly release.

Hooray! Thanks.

Squeezebox firmware 60 has now been released into test.

Haven't yet noticed this in the 6.5b1 nightlies yet (firmware 60). 
Will it show up in them soon or should I pull from subversion?

Subject: Out of Office AutoReply:  SqueezeBox3 v59 sends ASCII string as DHCP MAC address

I am out of the office on business until mid-day Thursday August 31st. If you have an urgent matter, call  my mobile number 240-899-5886, or instant-message my phone at https://wmg.tmomail.net/customer_site/jsp/messaging_lo.jsp. Otherwise, I will reply to your email message at the earliest opportunity.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.5">
<TITLE>Out of Office AutoReply: [Bug 3851] SqueezeBox3 v59 sends ASCII string as DHCP MAC address</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>I am out of the office on business until mid-day Thursday August 31st. If you have an urgent matter, call&nbsp; my mobile number 240-899-5886, or instant-message my phone at <A HREF="https://wmg.tmomail.net/customer_site/jsp/messaging_lo.jsp">https://wmg.tmomail.net/customer_site/jsp/messaging_lo.jsp</A>. Otherwise, I will reply to your email message at the earliest opportunity.</FONT></P>

</BODY>
</HTML>

I tested Firmware 60 in last night's build, and it looks fixed to me (this bug).

With the 2006-09-01 nightly & firmware rev 60, I now see a more
"traditional" client identifier.