quote: Marcel Birgelen

---

WireShark and tcpdump run in "promiscuous mode", so they also capture all traffic not destined for the machine itself, even if it's in an entirely different subnet or in many cases even if there is no IP address assigned to the interface of the listening machine.

---

This works well for traffic broadcasted by the device with the unknown addressing. It helps to be aware of the difference between a "network switch" and a "hub". We keep a number of "hubs" around for use in situations when you want to watch traffic between two other devices. Or, a device and the gateway. Just about all you can get these days are switches. Those try to be smart and only route packets to addressed devices in an effort to reduce bandwidth and network load. So your PC connected to a switch won't see packets from the unknown device unless they are specifically addressed to the PC or broadcasted.

Just FYI and worth noting if you are going to mess with Wireshark and want to really analyze some of the communications. Most devices broadcast something at some point (most likely after power is applied) so you might see that.

We do a lot with Wireshark since the JNIOR Series 4 can export a network capture using the NETSTAT command. The capture is a PCAP file that will open right up in Wireshark. The JNIOR is always queuing packets so it is kind of like you can look back in time when something needs attention.

By the way, JNIORs use a protocol called Beacon and announce themselves with UDP packets on port 4444. Most of that is with broadcasts and it is how the Support Tool can enumerate JNIORs on the current subnet. If you are in Wireshark you might peek at that for fun assuming you have a JNIOR around.
 

---

Posted by Marcel Birgelen (Member # 6801) on 10-14-2019, 11:37 AM:
 
You shouldn't put a switch in between in this case, as a switch sends directed packets only to the ports the switch has seen the MAC address on. A hub will work fine, but hubs are increasingly hard to find. An alternative is a monitoring port on a switch. Most managed switches allow you to configure a monitoring port, that will essentially receive a copy of all traffic on the ports you specified.

Almost every device running IPv4 will at some point do some broadcast traffic, to resolve some local IP address to its MAC address via ARP, even if it's just the local gateway.
 

---

Posted by Mark Gulbrandsen (Member # 72) on 10-15-2019, 08:06 AM:
 
Totally agree on using Advanced IP Scanner! Going into an unfamiliar booth you can get a list of all equipment and IP address in about a minute.

Mark
 

---

Posted by Marcel Birgelen (Member # 6801) on 10-15-2019, 07:52 PM:
 
Again, it may be a good tool in a network where your machine gets an IP address in the same subnet, but it will not work in this particular case...
 

---

Posted by Bruce Cloutier (Member # 9615) on 10-16-2019, 09:18 AM:
 
We've run into some issues with IP scanners and the JNIOR. Basically most of those attempt to open certain key ports at each possible local IP address. Some of those scanners then attempt default logins and or protocol exchanges in an attempt to identify security risks or additional specific information about the active port. Connections made by the scanner are sometimes left open and not properly closed. Sometimes the assumption of a protocol can forward data that is confusing to the system.

Generally none of this is a real issue but we have had some concerns. For instance, the Series 4 JNIOR can make secure connections. A port scanner testing port 443 makes a secure connection. A secure connection is labor intensive from the point of view of the JNIOR's microcontroller. The unnecessary load can cause variations in timing. I supposed that adds some risk in affecting the job that the JNIOR has to do. Our secure services process is normally not running. The scanner hitting port 443 starts it up and it stays active for a little while before going back to sleep. The same thing happens in other systems. The scan can affect the product. Hopefully not in any disastrous way.

I'm just saying that IP scanners can cause devices (not just JNIORs) some concern. A passive scanner collecting for instance broadcasted ARP requests would be a lot safer. An advanced IP scanner designed to be used buy IT departments in policing their networks may be a bit of overkill and comes with a risk.

We have JNIORs hanging on cellular modems in other markets. In those instances we work to keep bandwidth and therefore cellular charges to a minimum. We have seen elevated cellular costs not because of the JNIOR but due to port scanners repeatedly waking the connection. Obviously not a cinema thing but you see that an IP scanner is not always a noninvasive diagnostic tool.

Just saying.
 

---

Posted by Marcel Birgelen (Member # 6801) on 10-16-2019, 11:10 AM:
 
Yeah, you should not like, run an nmap on all your devices. Your Dolby CP650 won't like it also, for example. Those machines have CPUs that are like 1000 times slower than what many of us have in their mobile phone, so if you bug them with portscans, they're not going to be happy with you.

Passively collecting ARP traffic will usually take a whole lot longer than actively scanning, but I think that scanners that simply send out a single or a few ICMP (like no more than 3 per IP) packets at every IP address in a range are generally harmless, unless you put a small interval of a few milliseconds between each packet.
 

---