ログを拝見しましたが、パッと見た感じではおかしな点はないように思えました。
１．
まずちなみに、DataVLANの設定が不一致ではありませんか？
3850側ではAccessVLANが2132になっていますが、直前の投稿ではDataVLANが"2103"と記載されています。
２．
Cisco側でCDPが有効になっていますか？
VoiceVLANを使用するためにはAccessポートでCDPが有効でなければいけなかったはずです。
３．
IP phone の上位側スイッチ（Buffalo or Cisco）が接続されるポートとPCを接続し、PC側でWireSharkを動作させてパケットキャプチャを行ってみてください。
DHCP Requestフレームにタグがついていませんか？
４．
Buffaloハブの仕様を調べてみてください。
CDPパケットを透過しますか？
802.1qタグ付きフレームを受け取ったアンタグポートは、フレームを転送しますか？
５．
BuffaloハブにDHCPサーバを接続した場合（＝つまりCisco3850を経由させない場合）はIPアドレスが取得できますか？
とにもかくにも、DHCP RequestとReplyがData、VoiceどちらのVLANでやりとりされているのかを調べるのが一番近道だと思います。
IP Phone側、Cisco3850側の両端で調べてみて下さい。
その上でそのパケットがBuffalloハブを通過できているのかを調べれば被疑箇所はほぼ断定されます。
障害解析にこれ以上時間をさけないのであれば、実験されているようにノンインテリジェントなハブを間に挟むか、Cisco PhoneをCisco3850に直接収容する構成にした方が良いと思います。
また、仮になんらかの方法や設定変更/構成変更でDHCPによるIP取得ができたとしても、肝心の音声データはタグ付で流れます。
そもそもNativeVLANとはTrunkポートでタグなしフレームを受信した場合に転送する先のVLANのことですので、Buffaloハブの現在の設定はアンタグポートになっていますので、タグ付フレームを理解できずに転送しないのではないか（＝つまり音声通話ができない）と思います。
