okleinschmidt/wdmc

WD NAS returns invalid JSON

Closed this issue · 4 comments

Nota bene: This is not a problem with the code, but with the server with which it interacts.

My WD PR4100 NAS returns invalid JSON in response to this method in the Client class. The response includes an unescaped newline (\n), resulting in JSON which cannot be parsed.

def network
      response = get("#{@config['url']}/api/2.1/rest/network_configuration", {accept: :json, :cookies => cookies})
      JSON.parse(response, :symbolize_names => true)[:network_configuration]
    end

Running the response body through jq...

echo '''{"network_configuration":{"ifname":"bond0", "iftype":"wired", "proto":"dhcp_client", "ip":"192.168.1.33", "netmask":"255.255.255.0", "gateway":"192.168.1.1", "dns0":"192.168.1.1
", "dns1":"", "dns2":"", "gateway_mac_address":""}}''' | jq .

...produces the following:

parse error: Invalid string: control characters from U+0000 through U+001F must be escaped at line 2, column 1

Running it through od...

echo '''{"network_configuration":{"ifname":"bond0", "iftype":"wired", "proto":"dhcp_client", "ip":"192.168.1.33", "netmask":"255.255.255.0", "gateway":"192.168.1.1", "dns0":"192.168.1.1
", "dns1":"", "dns2":"", "gateway_mac_address":""}}''' | od -t x1

...produces the following:

0000000  7b  22  6e  65  74  77  6f  72  6b  5f  63  6f  6e  66  69  67
          {   "   n   e   t   w   o   r   k   _   c   o   n   f   i   g
0000020  75  72  61  74  69  6f  6e  22  3a  7b  22  69  66  6e  61  6d
          u   r   a   t   i   o   n   "   :   {   "   i   f   n   a   m
0000040  65  22  3a  22  62  6f  6e  64  30  22  2c  20  22  69  66  74
          e   "   :   "   b   o   n   d   0   "   ,       "   i   f   t
0000060  79  70  65  22  3a  22  77  69  72  65  64  22  2c  20  22  70
          y   p   e   "   :   "   w   i   r   e   d   "   ,       "   p
0000100  72  6f  74  6f  22  3a  22  64  68  63  70  5f  63  6c  69  65
          r   o   t   o   "   :   "   d   h   c   p   _   c   l   i   e
0000120  6e  74  22  2c  20  22  69  70  22  3a  22  31  39  32  2e  31
          n   t   "   ,       "   i   p   "   :   "   1   9   2   .   1
0000140  36  38  2e  31  2e  33  33  22  2c  20  22  6e  65  74  6d  61
          6   8   .   1   .   3   3   "   ,       "   n   e   t   m   a
0000160  73  6b  22  3a  22  32  35  35  2e  32  35  35  2e  32  35  35
          s   k   "   :   "   2   5   5   .   2   5   5   .   2   5   5
0000200  2e  30  22  2c  20  22  67  61  74  65  77  61  79  22  3a  22
          .   0   "   ,       "   g   a   t   e   w   a   y   "   :   "
0000220  31  39  32  2e  31  36  38  2e  31  2e  31  22  2c  20  22  64
          1   9   2   .   1   6   8   .   1   .   1   "   ,       "   d
0000240  6e  73  30  22  3a  22  31  39  32  2e  31  36  38  2e  31  2e
          n   s   0   "   :   "   1   9   2   .   1   6   8   .   1   .
0000260  31  0a  22  2c  20  22  64  6e  73  31  22  3a  22  22  2c  20
          1  \n   "   ,       "   d   n   s   1   "   :   "   "   ,
0000300  22  64  6e  73  32  22  3a  22  22  2c  20  22  67  61  74  65
          "   d   n   s   2   "   :   "   "   ,       "   g   a   t   e
0000320  77  61  79  5f  6d  61  63  5f  61  64  64  72  65  73  73  22
          w   a   y   _   m   a   c   _   a   d   d   r   e   s   s   "
0000340  3a  22  22  7d  7d  0a
          :   "   "   }   }  \n

Would be interested to know if others have this problem, as well.

Yes, same here:

irb(main):002:0> puts Wdmc::Client.new.network
{:ifname=>"egiga", :iftype=>"wired", :proto=>"dhcp_client", :ip=>"192.168.180.10", :netmask=>"255.255.255.0", :gateway=>"192.168.180.1", :dns0=>"172.16.20.1\n", :dns1=>"8.8.8.8\n", :dns2=>"8.8.4.4\n", :gateway_mac_address=>""}
=> nil
irb(main):003:0>

Blocks #4.

Yes, same here:

irb(main):002:0> puts Wdmc::Client.new.network
{:ifname=>"egiga", :iftype=>"wired", :proto=>"dhcp_client", :ip=>"192.168.180.10", :netmask=>"255.255.255.0", :gateway=>"192.168.180.1", :dns0=>"172.16.20.1\n", :dns1=>"8.8.8.8\n", :dns2=>"8.8.4.4\n", :gateway_mac_address=>""}
=> nil
irb(main):003:0>

Yeah, makes sense. I suspect that this is what you were fixing in commit a872d92.

Work-around added/documented on PR #6. Removed old eval()-based work-around on PR #7.

Resolved. Closing.