Odd Traffic Graph bug in 2.1.5
I am running the current 2.1.5 x86_64 embedded release of pfSense on a dual core machine with two interfaces.
Yesterday I was trying to troubleshoot something on my Lan, and had occasion to use the Traffic Graph feature which I set for:
Interface:Lan, Sort by:Bw In, Filter:All, Display:IP Adress
I noticed some strange traffic between 0.0.0.0 and 220.127.116.11,
which resolves via reverse DNS to 18.104.22.168.broad.wh.hb.dynamic.163data.com.cn
I freaked out and shut down every host on the network trying to identify the source. I eventually isolated the suspect traffic to my recently acquired Dell Powerconnect 2816 switch.
I added a temporary subnet using a USB ethernet adapter, and set up rules to isolate the bare switch on the new subnet.
Running tcpdump in the pfSense shell I noticed spanning tree (STP) (BDPU) traffic from the switch.
Here is a slightly sanitized packet dump:
18:17:34.288389 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.XX:XX:db:8b:eb:b3.8001, length 43
message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
root-id 8000.XX:XX:db:8b:eb:b3, root-pathcost 0, port-role Designated
Looking at the six digit hex portions of the root-id and bridge-id portions of the STP packet, and watching the simultaneous suspect traffic to China in the Traffic Graph it occurred to me to check the HEX==>ASCII conversion of the hex data in the packets.
db:8b:eb:b3 (HEX) ==> 22.214.171.124 (ASCII) ==>
To make matters worse, when Display is set to FQDN, the Traffic Graph dutifully converts the spurious IP address to an evil looking fully qualified domain name in China.
It looks like the Traffic Graph code is just a wee bit brain dead when it comes to STP traffic.
I was scared to death that I had managed to pick up a switch on eBay that had been back-doored in hardware, and was tunneling my data to China.
Hopefully this post will save some grief for other users that run into this odd bug.
kejianshi last edited by
OK - So what was your final conclusion?
Is your traffic being sent out to china or not?
I came to the conclusion that the Traffic Graph code is misinterpreting the MAC address embedded in the STP packet and converting it to a dotted quad IP address.
The last four HEX digits of the mac address of the root bridge on my switch (db, 8b, eb, b3) just happen to translate to 219, 139, 235, 179. The Traffic Graph code is doing the hex to ascii conversion on those last four digits and then presents it as either a dotted quad: 126.96.36.199, or as the fully qualified domain name: 188.8.131.52.broad.wh.hb.dynamic.163data.com.cn
My data is not going to China, but the Traffic Graph code makes it look like it might be, because it apparently can't cope with the STP packets sent by my switch.
I will note that the switch is set with a static RFC-1918 IP address, and no default gateway (0.0.0.0).
I haven't checked, but I may be able to set the bridge MAC so that it resolves within Traffic Graph to any arbitrary seemingly remote address I choose.
kejianshi last edited by
I understand now - I'm sure the chinese are quite disappointed to get this bad news… haha.
This quirk still exists in PFSense 2.3.4.