Smartphone Identification Question

[djmcfar]

Hi there. I recently upgraded from an RT-AC68U to the RT-AC86U for the hardware cipher capability (VPN 4 to 5 times faster) and have had no problems whatsoever with the new router (a month old). I have the most recent version of Merlin on both routers and it works flawlessly. One thing that has baffled me about the LAN list dialog box is the ability of the router to display either OS, Model Name or Device Name for the smartphones in my network (see photo below - 4 smartphones). I have done a lot of searching on the subject, and have found nothing to help along those lines. I have written a Linux network utility (years ago, just upgrading now) where one of the features is an ARP scan which shows MAC, OUI name, IP, and either device name or model name, for each device in the network. I am really impressed that the router is able to show smartphone info of any type. If anyone either knows how, or has ideas as to how that can be done I would be very grateful for hints. Thanks in advance.

 

[tgl]

One thing that has baffled me about the LAN list dialog box is the ability of the router to display either OS, Model Name or Device Name for the smartphones in my network

I'm not sure (@RMerlin might know for sure) but I suspect these strings come from DHCP client requests, cf the host name field in RFC 2132. I've noticed that my routers/APs can display something interesting for much of the gear on my network --- but usually it's just the manufacturer name, not anything more specific.

 

[RMerlin]

This is handled by the closed source networkmap daemon. It locates devices using ARP queries, then it will probe them to extract as much information as possible to identify and label them, based on various methods such as DNS lookups, NETBIOS queries, trying to connect to the LPR port, etc...

The manufacturer is determined by looking at the OUI portion of the MAC address.

 

[djmcfar]

I think you are probably correct tgl, and I'll have a look with wireshark, and post back here with the result. Thank you very much !!

 

[drinkingbird]

I think you are probably correct tgl, and I'll have a look with wireshark, and post back here with the result. Thank you very much !!

Already answered but I'll toss in my 2 cents, I toyed with this a bunch to try and figure out the relation of network map to DHCP etc. The icon is figured out by looking at the MAC address of the client (and using some rules they've apparently built in to try go guess if it is a phone, PC, etc based on how it responds to queries). The 386 code base seemed to expand the number of icons and the methods they use to try and decide the right one. The hostname comes from DHCP if the client reports its hostname, and if not it will display the manufacturer of the NIC if it can find it, and if all else fails, the raw MAC address. The raw MAC is usually for clients like phones that are using randomized MAC addresses in my experience.

For devices that you want in DNS that aren't reporting a hostname, you can give them a DHCP reservation. Whatever you put there for hostname will get populated in DNS, the DHCP leases, and the network map (unless you customized that device name in network map, in which case that will override it).

If you don't care about DNS or DHCP table, you can just customize the name in the network map and it will remember it for that MAC address.

 

[djmcfar]

I didn't see your reply RMerlin until now (this forum must auto-update). I'm not surprised that it is within the closed source portion of the project. I'm going to try tgl's suggestion first. Smartphones are reluctant to give up any info, and now-a-days the default is to use a pseudo MAC address, so the router does not need a legit MAC in order display the smartphone info (see 'Galaxy-S10e' in the above photo - bit 2 of the first octet in the MAC is set which indicates a pseudo MAC). I wanted to make a donation to your project tonight, so could I ask if https://www.asuswrt-merlin.net is the correct place to donate ? Thank you very much for responding to my question.

 

[drinkingbird]

I didn't see your reply RMerlin until now (this forum must auto-update). I'm not surprised that it is within the closed source portion of the project. I'm going to try tgl's suggestion first. Smartphones are reluctant to give up any info, and now-a-days the default is to use a pseudo MAC address, so the router does not need a legit MAC in order display the smartphone info (see 'Galaxy-S10e' in the above photo - bit 2 of the first octet in the MAC is set which indicates a pseudo MAC). I wanted to make a donation to your project tonight, so could I ask if https://www.asuswrt-merlin.net is the correct place to donate ? Thank you very much for responding to my question.

The pseudo MAC still comes from a range that is identifiable back to the manufacturer, but Samsung phones report their name and will show up fine, so it isn't having to do any "magic" there, the phone reports its name (default or the custom one if you've renamed it), and the Asus code looks up either the beginning of the MAC or just has rules in it for when it sees those generic phone names reported. I have noticed that Iphones used to report their name (even the customized name that the user assigned like "Joe's Iphone" but nowadays they seem to just show up as a MAC address, so Asus hasn't figured out the ranges that Apple is using for their pseudo MACs apparently. Some Android phones do this too, each manufacturer can tailor it however they want, if they don't want it to report its name for security reasons, they just turn that off in their implementation.

 

[RMerlin]

I didn't see your reply RMerlin until now (this forum must auto-update). I'm not surprised that it is within the closed source portion of the project.

It used to be open sourced (I actually fixed a ton of bugs in that code in the early days of this project), but was closed down later as more code related to Broadcom and Trend Micro got integrated into it.

I wanted to make a donation to your project tonight, so could I ask if https://www.asuswrt-merlin.net is the correct place to donate ?

Yes, that is my website, with the link to my Paypal account.

 

[djmcfar]

drinkingbird - thanks for your comments on my question. I'm going to look into it your last reply. I'm enjoying a Founder's Centennial IPA (or 2) at the moment...

 

[djmcfar]

Thanks RMerlin. Great work on the project.

 

[drinkingbird]

drinkingbird - thanks for your comments on my question. I'm going to look into it your last reply. I'm enjoying a Founder's Centennial IPA (or 2) at the moment...

Smartphones are all over the place these days as far as how they work with DNS/DHCP etc.

The way I work it, if it is something I just want to see a friendly name in the client list, I just customize the name there (once I figure out what device it is). As long as you don't reset the wireless on that phone or "forget" the network and rejoin, it will use that MAC with your SSID always, so the router will remember it.

If it is something I want to be able to do DNS lookups against (and it doesn't report its name) I'll give it a DHCP reservation.

UK markets don't open until 4AM this week (their DST is a week out of synch with ours) so maybe I'll have a beer too, not like those guys aren't drunk at work half the time anyway.

 

[djmcfar]

drinking bird - if it pans out that tgl's answer is correct, then ARP poisoning followed by DHCP spoofing would be the only way to get some smartphone info that I'm looking for the ARP scan portion of my utility (that I can think of at the moment - for home use), but your suggestion about pseudo OUIs is a good alternative, thanks.

 

[drinkingbird]

drinking bird - if it pans out that tgl's answer is correct, then ARP poisoning followed by DHCP spoofing would be the only way to get some smartphone info that I'm looking for the ARP scan portion of my utility (that I can think of at the moment - for home use), but your suggestion about pseudo OUIs is a good alternative, thanks.

Didn't quite catch the part where you were looking to update your own utility.

For devices in DNS (ones that report their hostname in the DHCPREQUEST) it should be fairly simple. You ping scan your subnet (even if devices don't respond, you'll get ARP for them) or force an ARP broadcast, then you can reverse lookup the IPs in DNS (if the device reports its hostname) and if you need it, the OUI against the public database. As far as the pseudo MACs, I don't think you'll have much luck, they are only required to use a specific second digit of the OUI to signify randomized MAC, I can't find any reference to ranges used by Apple, Android, etc. It appears to be completely random other than that second digit (which must be 2, 6, A, or E)

If the device doesn't report the hostname field when getting a DHCP lease, unless you want to add it to DNS with a reservation, you're going to be limited to just showing the vendor if the OID is known, or "randomized mac" if it isn't. The router has the benefit of being able to see more data than a scan tool will based on the fact that it can see the whole DHCP exchange plus snoop some other stuff, so it may be able to do some additional trickery that you can't.

For the icon displayed, I suspect that they first look at the DHCP exchange. Various OS's support various extra fields and announce various capabilities, and they can determine lots from that. The next step would be to look at the OUI if it is in the public database. I suppose they could also look for keywords in the hostname reported back, or snoop some traffic and look for certain patterns, but I doubt it is going to that extent. My guess is it is limited to information it can get from DHCP and/or the OUI.

For the name displayed in the client list, the priority seems to be this order (stopping when one matches):
1. Name you've manually customized in the network map list
2. Hostname you've assigned to DHCP reservation
3. Hostname reported back in DHCP response
4. Manufacturer name associated with OID
5. Raw MAC address if all else fails

Not sure how you're planning to spoof DHCP, typically the client initiates all DHCP, and if you send an unsolicited DHCPOFFER I wouldn't think you'd get a response, but never tried. If you're going to poison the ARP to try and force the client to send a DISCOVER and REQUEST and snoop those broadcasts, I guess that could work, since you won't actually be replying, just watching. But keep in mind that DHCP renewals are unicast which you won't see, so the client has to be forced to start the process from scratch (release and renew essentially) which will interrupt their traffic when you scan. If you are able to get the full DHCPREQUEST packet then you should be able to see a good amount of info on the device.

 

[djmcfar]

drinkingbird - I really wasn't expecting anyone to give such a well thought out suggestions here, particularly because I didn't come here with a router issue - thanks very much !

One of the things that got me to want to update the utility is an unidentified network appliance. I was able to identify the servers it was contacting using tcpdump pcap file output, (running on the router and viewed on PC) a list of google related services using TLS 2.1 or 3.1, and the service types were visible in the TLS plain text hello packets that are sent when the data transfer cypher selection is being made, and I was able to verify the IP source of those services within the google cloud. I dumped everything google about a year ago, so this ticked me off a bit LOL. It is the only device in the network that the router doesn't give a clue on. Since I couldn't physically locate it, I decided to reserve the IP and block internet access instead. Other methods would have prevented any device on the network from making "legitimate" accesses to those services.

It turns out that the info was in DHCP 'Hostname' field as tgl suggested (traces below taken on router as pcap and viewed on PC). Thank you all for helping me with this issue. Now I have to decide if it's worth the time to implement, but that's my problem LOL (my wife might think differently).

 

[drinkingbird]

drinkingbird - I really wasn't expecting anyone to give such a well thought out suggestions here, particularly because I didn't come here with a router issue - thanks very much !

One of the things that got me to want to update the utility is an unidentified network appliance. I was able to identify the servers it was contacting using tcpdump pcap file output, (running on the router and viewed on PC) a list of google related services using TLS 2.1 or 3.1, and the service types were visible in the TLS plain text hello packets that are sent when the data transfer cypher selection is being made, and I was able to verify the IP source of those services within the google cloud. I dumped everything google about a year ago, so this ticked me off a bit LOL. It is the only device in the network that the router doesn't give a clue on. Since I couldn't physically locate it, I decided to reserve the IP and block internet access instead. Other methods would have prevented any device on the network from making "legitimate" accesses to those services.

It turns out that the info was in DHCP 'Hostname' field as tgl suggested (traces below taken on router as pcap and viewed on PC). Thank you all for helping me with this issue. Now I have to decide if it's worth the time to implement, but that's my problem LOL (my wife might think differently).

Yes, most/many devices report that, f you look under network map in the router and compare it to the DHCP leases in the router, you'll be able to see which devices are reporting their hostname using that field.

DHCP leases will show "*" for a device that does not report that field, but network map will put something there, usually the manufacturer or the raw MAC address. Those are the ones you would potentially need to find some other way of identifying (and even then it would be a fairly generic identification).

The ones that report their hostname are easy, your scan tool just needs to do a reverse lookup against DNS for any IP in the ARP table (after a ping scan or something else to populate the table).

Your dilemma reminds me of an old joke - "I've lost a server. It isn't down, I can ping it, it is working fine, I just don't remember where it is".

 

[djmcfar]

I'm using the router DHCP server (gonna install linux DHCP server later today) and the reverse DNS doesn't report anything, but filtered and parsed avahi output in combination with smblookup fills most of the gaps - for instance the utility reports the exact model name of my printer, while the router reports only it's MAC. If I use the local (non-router) DHCP server I'll at least have access to the DHCP logs where the smartphone info I'm looking for is present (decided the ARP poisoning method requires too much work, although my utility already has that capability).

 

[drinkingbird]

I'm using the router DHCP server (gonna install linux DHCP server later today) and the reverse DNS doesn't report anything, but filtered and parsed avahi output in combination with smblookup fills most of the gaps - for instance the utility reports the exact model name of my printer, while the router reports only it's MAC. If I use the local (non-router) DHCP server I'll at least have access to the DHCP logs where the smartphone info I'm looking for is present (decided the ARP poisoning method requires too much work, although my utility already has that capability).

Every client in my DHCP list that shows a hostname (and not *) has both an A and PTR record present in DNS. You may have something corrupted in your router that needs to be reset or maybe the machine you're using is not actually looking up to the router DNS (try specifying the IP address of the router in your lookups).

The exact model of your printer is likely just its hostname, most printers use their brand/model as their hostname. But sounds like you're on the right track and have a plan, just seems wasteful to run a separate DHCP/DNS when you're already essentially running a linux DNS box. You could enable syslog and bump up the verbosity of the output and get all the DHCP logs sent to a log server for parsing too.

 

[djmcfar]

Got some strange results here. When I was using the router's DHCP server, I never tried commands that use reverse DNS from Windows - (home net = 2 Ubuntu 22.04, 5 windows 10 and 11), so I thought I'd try it from a couple of windows machines after installing the isc-dhcp-server, and lo and behold, windows reports the DHCP hostnames using nslookup or 'ping -a', but linux still does not. I verified using wireshark that DNS from DHCP is set to go to the router in both cases (router or Ubuntu DHCP server). Next I switched it back to use the router's DHCP server with the same result. So the local reverse-DNS failure here is only coming from the Ubuntu 22.04 machines (same result on both), not the network configuration. It doesn't do me any good that it works on windows because it's a linux utility. It would be handy to run the utility from either linux machine and get the smartphone hostname reported. As it is now, that would only work on the machine having the DHCP server installed and running (parsing DHCP log file). Edited: forgot to mention that 'host' and 'dig' don't work either.

It turns out that HP's convention for reporting LaserJet DHCP hostnames is "NPI" followed by the last 3 octets of the MAC address (from an HP website). I found that out by wondering what the string "NPI08A208" stood for when I saw it being reported as the hostname during DHCP discovery (not the model number). The field I use from avahi parsing is "HP LazerJet MFP M140w".

 

[drinkingbird]

Got some strange results here. When I was using the router's DHCP server, I never tried commands that use reverse DNS from Windows - (home net = 2 Ubuntu 22.04, 5 windows 10 and 11), so I thought I'd try it from a couple of windows machines after installing the isc-dhcp-server, and lo and behold, windows reports the DHCP hostnames using nslookup or 'ping -a', but linux still does not. I verified using wireshark that DNS from DHCP is set to go to the router in both cases (router or Ubuntu DHCP server). Next I switched it back to use the router's DHCP server with the same result. So the local reverse-DNS failure here is only coming from the Ubuntu 22.04 machines (same result on both), not the network configuration. It doesn't do me any good that it works on windows because it's a linux utility. It would be handy to run the utility from either linux machine and get the smartphone hostname reported. As it is now, that would only work on the machine having the DHCP server installed and running (parsing DHCP log file).

View attachment 45197

View attachment 45198

It turns out that HP's convention for reporting LaserJet DHCP hostnames is "NPI" followed by the last 3 octets of the MAC address (from an HP website). I found that out by wondering what the string "NPI08A208" stood for when I saw it being reported as the hostname during DHCP discovery (not the model number). The field I use from avahi parsing is "HP LazerJet MFP M140w".

Strange, maybe some bug in that linux release. Did you try doing -type=ptr or -type=any ? You could also dig -x the IP

 

[ADFHogan]

Where I have devices on my network that I'm not sure what they are (and wireshark oui lookup fails), I'll run a tcpdump (installed from entware) on br0 interface against that device's IP..

Eg. tcpdump -i br0 -X host 192.168.x.y

I've identified LED strip controllers, Amazon devices, game consoles and smart TVs by DNS queries and connections they make back to specific systems.