That makes a lot more sense.
Sigh, and I read the whole thread. Should have known it was a wild rabbit hole the moment I saw “high fidelity” network. Actually, I did know. Guess I was just bored. 
6 Likes
This is like black-boxing images or beeping-out audio. I’m sure I’m imagining more provocative stuff than mateo orginaly “said.” 
2 Likes
Yeah, apparently suggesting that trolls be removed is worse for the “community” than the trolls themselves…
Peace out…
1 Like
Apologies if this is causing frustration. I have no intention to troll anyone here. I’m doing the best I can to understand the situation and hoping it’s nothing for my kids’ sake. Please feel free to ignore this thread if it’s irritating you but do please stay if you feel you can add value or learn from this situation.
What I know so far is that Ubiquiti does not store the IP addresses or timestamps alongside DPI logs. As @Rockslice mentioned DPI classification rules are stored in a proprietary format on the USG. I don’t know where the DPI logs themselves are stored. I dumped a bunch of log files but I see no matching mac addresses or any reference to the “Omegle” cat_id (128). If anyone know where they are please share.
Ubiquiti claim that it’s very unlikely traffic in a vlan can get erroneously attributed to client in other vlans. Not to say it’s impossible but they have never seen it happen before.
I have run tcpdumps for tcp and udp traffic from the USG and see no reference to any IP addresses related to any services other than Wowrack, OVH, globalaxs and 10.123.102.12 (??) - see short snapshot attached. So, from what I can assume is that suspect traffic has stopped; is buried in the reems of logs currently being analysed; has been erroneously labelled and erroneously attributed by Unifi USG; or the packets sent configs to numerous IM services along with a bunch of decoys for “unknown” services to intercept packets from the cams…??? Don’t know how I will conclude any of these possibilities at this point but hoping between here and others I have helping out I can get something definitive.
I’ve attached screenies of the Unifi DPI dashboard associated with the macs of the cams. And also screenies of the cam device info screen from the Wyze app with corresponding mac addresses for cross reference sake - risky sharing mac addresses but likely I won’t use the cams again.
https://drive.google.com/file/d/18YipxCBOt--Blo08PbKD05ZJxItKnWpP/view
https://drive.google.com/file/d/1iz-9jhAaIhcpb-99PCuQSbLVVvr6pfuF/view?usp=sharing
2 Likes
Sigh. There is nothing in what you’ve provided that indicates traffic went anywhere untoward. Nada. All you have is a purported “deep packet inspection” record from your MAC address, but that’s just your vendor trying to classify what’s IN the packet, not where it’s going! (“actual data contents in the IP packet, in some cases even encrypted traffic”)
It has simply misclassified them. It doesn’t have much to go on and is making dumb pattern matching guesses against whatever is in a little packet, based on what it thinks related application traffic looks like. It’s a wild guess, a shot in the dark, a pretense of accuracy. It’s a false alarm. Don’t worry about it.
" Starting from the v1.7.0 EdgeOS firmware release, Deep Packet Inspection (DPI) and Traffic Analysis are supported on EdgeRouters. Compared to traditional packet analysis tools which only give a glimpse of packet information such as port number and IP address, DPI is used to analyze and report the actual data contents in the IP packet, in some cases even encrypted traffic. When enabled, the DPI engine drills down to the core of the packet, collecting and reporting information at the Application-layer, such as traffic volume of a particular application used by the host."
2 Likes
As I stated way back early in this thread - not an issue.
@Customer provides another great and succinct analysis.
Admittedly, I was bored and so downloaded the mp4 … and the packet capture to analyze in Wireshark [1], [3].
From the video (the original screenshot did not show), we can see the packets for a specific MAC address … and it ONLY shows up to about 45 records.
Here’s the hilarious part - it shows 4-5-6 “analyzed” packets of:
“instant messaging”
… all of those packets ONE AFTER THE OTHER, but from different “sources” [2]
I suspect the “Wyze-side analysis” is taking a long time because they have lawyers involved, burning through cash.
The OP is one of those who has what they believe to have an “advanced hardware and software” product, but doesn’t have the analytics to “make sense of the data”.
Someone remind me to not buy this “high fidelity home network” product : )
.
.
[1] There are those who think Wireshark is a dinosaur of some sort, even though we network engineers use it all the time
[2]
[3]
IP Address 37.120.216.214
inetnum: 37.120.216.0 - 37.120.216.255
netname: M247-LTD-NewYork
descr: M247 LTD New York Infrastructure
country: US
geoloc: 40.7175544 -74.0083725
admin-c: NYC-RIPE
tech-c: NYC-RIPE
status: ASSIGNED PA
mnt-by: SDAT-MNT
mnt-routes: GLOBALAXS-MNT
mnt-domains: GLOBALAXS-MNTvvv
IP Address 209.90.225.252
NetRange: 209.90.224.0 - 209.90.239.255
CIDR: 209.90.224.0/20
NetName: WORLDLINK-2
NetHandle: NET-209-90-224-0-1
Parent: NET209 (NET-209-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS27323
Organization: Wowrack.com (WOWTEC-1)
RegDate: 2006-01-20
Updated: 2015-11-09
Ref: https://rdap.arin.net/registry/ip/209.90.224.0
OrgName: Wowrack.com
OrgId: WOWTEC-1
IP Address 89.100.154.228
inetnum: 89.100.142.0 - 89.100.155.255
netname: VM-IE
descr: Residential DHCP
descr: Virgin Media Ireland
country: IE
admin-c: DH2529-RIPE
tech-c: DH2529-RIPE
status: ASSIGNED PA
mnt-by: VM-IE-MNT
created: 2017-10-27T09:34:28Z
last-modified: 2017-10-27T09:34:28Z
source: RIPE
person: Denis Hanley
address: UPC Ireland
address: LEDP
address: Enterprise Development Park
address: Roxboro Road
address: Limerick
IP Address 10.123.102.12
NetRange: 10.0.0.0 - 10.255.255.255
CIDR: 10.0.0.0/8
NetName: PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle: NET-10-0-0-0-1
Parent: ()
NetType: IANA Special Use
Organization: Internet Assigned Numbers Authority (IANA)
Updated: 2013-08-30
Comment: These addresses are in use by many millions of independently
1 Like
Nice add, @myswtest . Is it persuasive to you other geeks (used fondly)? I don’t have the chops to judge.
What’s your current take:
- Case closed, not an issue.
- Yet to be determined, shelter-in-place.
0 voters
I have read the entire thread:
- Yes
- No
0 voters
The tip off to me was calling a social network a “pedophile” ring. Pedo’s are well known to ALL social networks. Facebook and Twitter chief among them. There is more child porn on Facebook than anywhere else I am aware of.
So to specifically say what they did with no evidence of sexual traffic or intent in this situation was done to attract attention and ONLY to attract attention.
An “unnamed” insurance company was unwittingly hosting terabytes of underage porn on their servers and cooperated with investigators when it was discovered. An creep of a network engineer was the culprit. It happens more than most people realize.
2 Likes
This is one of the few threads I hope engineering is paying LESS attention to. Wyze has enough real issues on the technology and business sides.
This is the rough equivalent of seeing someone in a mask walking their dog and claiming a burglary ring is operating.
Let’s try again: it’s the equivalent of me using the word “ring” in a sentence and your tool concluding I’m getting married.
MOD NOTE: Post edited to conform to the Community Guidelines.
4 Likes
Hey Bob, do you believe in “micro-expressions”?
Not sure? What do you mean specifically?
re tip-off, or “tell,” to an individual’s earnestness or true intent.
The expression that you highlighted in this case was not so subtle:
There may have been subsequent textual microexpressions that reinforced your developing hunch. Or not.
/edit
I’m not endorsing or referring to Wiki’s full piece - it’s just a point of common reference.
I read a book, I don’t know, twenty years ago, written by a police detective, I think, who explained how he had used this tool and others to determine a subject’s credibility in an interview.
He found it (again, memory) a useful tool, at minimum, and at best, quite incisive, in that quest.
/edit
Apropos, roughly, to the subject of truth and trust:
This week in discussion with a family member I found out that they didn’t consider lies of omission “really lying.”
This was startling, because to me, they are the worst.
I explained why, but I don’t think my view was persuasive to them, so it becomes just a good thing to know about each other as we communicate.
Bringing it back to this thread, here’s an omission (no response) that I filed away:
I follow a lot of the above but to be perfectly honest I am not sure how it applies?
3 Likes
You’re right, I don’t have full command of the subject, guess we’ll have to work it out, together, on the fly, toward this:
Another option, of course, is to just reject it. Bad attempt. Next.
Totally fine.
Anyway, bareboned:
-
Is the OP a legitimately concerned customer, or a troll.
-
How do we determine if he is trustworthy?
-
Are there contradictions in what he is claiming, communicating.
-
Are there omissions in what he is communicating, is he fully forthcoming?
Microexpressions are expressive of an internal contradiction ineffectively masked.
What is omitted? A truth that may be relevant.
Ok so final update here. Thank you for your patience while I worked through this. I’ve attached 3 CSV files with the name resolved logs for all IPs (or IP/PORT combos) from my vlan with only WyzeCams connected. Each sample was c.250k packets and all outputs were pretty much exactly the same. I ran as many features triggered by app and camera as possible for each sample.
For samples I ran:
tcpdump -ni eth1 net 192.168.2 -e -vv -tttt -w /tmp/tcpdump -W 48 -G 1800 -C 100 -K -n
…on my USG gateway, pulled the dumps into wireshark and “filtered” using endpoint statistics feature.
TL;DR
All traffic was to expected/trusted hosts, no untoward traffic. CONCLUSION (with help from some useful guidance from the community - thank you): The Unifi DPI classification is clearly inaccurate and the cameras’ traffic seems entirely legit.
Apologies, again if this thread irritated anyone and thanks to those who contributed useful information.
UDP: https://drive.google.com/file/d/1Z5gALh5LkBmBtFnOLa58sRWv94NHNJ0_/view?usp=sharing
TCP: https://drive.google.com/file/d/1v8fyuGlbr0oxnJFKmuxXWlFt5wgajziU/view?usp=sharing
IPv4: https://drive.google.com/file/d/1PV51PcL0pkLNng384TgL_vdqdr47sSah/view?usp=sharing
6 Likes
Thank you for all of the info here and for several folks who helped investigate this event.
Admins, could we please lock or close this thread as it’s no longer on topic and the OP has given his findings on it?
1 Like
Some posts were removed or edited that did not follow the Community Guidelines. Please flag posts that violate the guidelines so the moderators can respond appropriately.
Key points from the guidelines to keep in mind:
- Remember to criticize ideas, not people
- Please avoid name-calling
- Don’t divert a topic by changing it midstream
- Keep posts relevant to Wyze
Important sections:
Always Be Civil
Somtimes We Disagree
1 Like
This thread has been declared solved by the OP and is now closed.
7 Likes