Analyzing Network Traffic
The JNIOR captures network traffic continuously. A large queue is established at boot and a record of network packets is kept. Once the queue fills the oldest packets are dropped. Depending on your network usage that queue might contain the past hour of traffic or much more.
The NETSTAT -C command generates a network capture file /temp/network.pcapng on demand containing the content of the capture queue. For example:
HoneyPot /> netstat -c LAN connection active (100 Mbps) generating capture file... /temp/network.pcapng created collected 4791 packets from the previous 16 minutes HoneyPot />
You can download this file to your personal computer. If you have Wireshark installed you will likely be able to double-click this PCAPNG file and it will open right up for viewing and analysis.
By the way you can download Wireshark for free from https://www.wireshark.org/.
Notice that in my example only the past 16 minutes were captured. First of all the capture begins at boot. So if your JNIOR has only been up for 16 minutes that is all that you will get. This, I think, was the case here.
It is important also to note that when you access the DCP you are also using the network. That means that all of the packets involved with your browser access will also be captured. If you leave the DCP up to monitor the status of your JNIOR all of that traffic takes up space in the capture buffer. If you are interested in analyzing the JNIOR interaction with another device that DCP traffic will limit the amount of information you can capture relative to that other device.
One solution is to not use the network to monitor the JNIOR by using the RS-232 (COM) port. But for that you have to be physically at the JNIOR and have the ability to use a serial connection. A better solution is to use capture filtering.
With the JNIOR you can both filter the packets that are to be retained in the capture buffer and filter the packets that you extract into the /temp/network.pcapng file. For example I will set this JNIOR up to ignore HTTP (Port 80) traffic and capture everything else. I can then use the DCP without loading the capture buffer with packets that we are not interested in.
HoneyPot /> netstat -f !80 LAN connection active (100 Mbps) capture filter set HoneyPot />
This tells JANOS to only accept packets into the capture buffer that DO NOT reference port 80. This takes effect immediately (provided there isn’t a syntax error). The next /temp/network.pcapng file that I generate will no longer contain HTTP communications and therefore nothing to do with the DCP. There will be many more packets from a longer period of time all pertaining to other communications that might help with my debugging.
The NETSTAT -F command basically sets the IpConfig/CaptureFilter Registry key. If you mouseover that key in the Registry tab of the DCP and hit F1 you will see the documentation for filtering and the syntax for these filters. These details are in the Registry Key Assignmentsdocumentation. The current version of that documented is distributed as part of the DCP. It will be present on every Series 4 JNIOR that is up to date.
Network Filtering
The content of a network capture or the network clients allowed to interact with the JNIOR can be controlled through dynamic filtering. These filters can be quite simple or, if needed, much more sophisticated.
The IpConfig/CaptureFilter Registry key may optionally define a filter which is applied to incoming packet data prior to capture. There is limited storage for captured information and by filtering you can extend the capture period and the amount of pertinent information collected.
A filter may also be used in generating the network.pcap capture file from the capture buffer. Here the filter allows you to extract only pertinent information and otherwise keep file sizes at a manageable level.
The IpConfig/Allow Registry key may optionally define a filter which is applied to incoming connections. In this case the referenced IP addresses refer to the incoming source IP addresses, those of clients. Referenced port numbers refer only to destination ports, those available on the JNIOR.
IP Address Filters
To filter packets referencing a specific IP address you need only include the IP address in the format “nnn.nnn.nnn.nnn” in the filter string. Any packet that references this IP address either as the source or the destination address will be selected for inclusion. All other packets will be excluded unless covered by some other part of the filter.
To exclude packets referencing a certain IP address you can prefix a ‘!’ exclamation point to the address like this “!nnn.nnn.nnn.nnn”. All packets that do reference the IP address as either a source or destination address will NOT be selected for inclusion. This can also be written as “NOT nnn.nnn.nnn.nnn”.
Note that an IP address is identified by its format, four decimal values between 0 and 255 separated by the ‘.’ period.
The domain syntax allows a range of IP addresses associated with a netmask to be specified. The format is “nnn.nnn.nnn.nnn/mm” where ‘mm’ specifies the number of high order bits in the netmask. For example, “10.0.0.0/24” specifies any IP address in the domain that contains IP addresses 10.0.0.1 through 10.0.0.255 and uses a netmask of “255.255.255.0”. This would be useful in selecting only local traffic for instance.
MAC Address Filters
Although less often required you can filter on a specific MAC address. The MAC address is included in the filter string in the format “hh:hh:hh:hh:hh:hh”. The format is six hexadecimal values (0-9a-f or 0-9A-F) separated by the ‘:’ colon. For instance most INTEG Series 4 JNIORs have MAC address formatted as “9C:8D:1A:hh:hh:hh” where the lower three bytes are assigned in some sequence.
As with IP addressing, packets with MAC addresses may be excluded by writing the filter as “!hh:hh:hh:hh:hh:hh” or “NOT hh:hh:hh:hh:hh:hh”. Again a MAC address is identified by its format.
TCP/UDP Port Filters
A port is specified in the filter string as a decimal value between 1 and 65535 inclusive. No punctuation is used. The capture filter does not distinguish between a TCP or UDP port number. A port may be excluded using the negation “!nnn” or “NOT nnn”.
There are standard ports assigned for various functions. The capture filter knows some of them by name. Some may be reconfigured through the Registry. As a convenience the port may be specified using its protocol name. The capture will be filtered on the port as configured at the time the filter is compiled (at boot or upon NETSTAT command). JANOS recognizes these port names where the default values are shown in parentheses: SMTP (25), NTP (123), JNIOR (9200), FTP (21), HTTP (80), HTTPS (443), TELNET (23), and BEACON (4444). These ports may be excluded using the same negation syntax as previously shown
Boolean Constants
The capture filter will also recognize the terms TRUE and FALSE. True indicates that the packet is to be included and False otherwise.
Logical Operations
To filter on a single IP address, MAC address or port (or to exclude a single item) the filter need only specify the address or port in the associated format. The following would select the communications involved in an email transfer. If this is used as an incoming filter, only email transactions would be captured. If this is used with NETSTAT –C in generating the PCAPNG file, the file would only include email communications.
NETSTAT –C SMTP
netstat –c 25
Note that filters (and also commands) are not case-sensitive. Either form above will create a PCAPNG file with just email communications. This assumes that you have not reconfigured the SMTP port. If you have set Email/Port to another port (587 for instance) then the first line will extract your email communications and the second will not. Although the second filter might show an application trying to use the incorrect port.
Filters often need to be slightly more complex in order to include the collection of communications needed. The syntax allows you to specify any number of addresses or ports in any combination using AND, OR and XOR logic. As an alternative you may use the notation ‘&&” and ‘||’ for AND or OR respectively.
As an example perhaps you want to filter only email communications with the SERVER.
netstat –c 10.0.0.4 && smtp
If you want to also include BEACON communications you might write the filter as:
netstat –c 10.0.0.4 AND smtp OR beacon
But here you might question the order of precedence of the logical operations. The capture filters do not support an order of precedence but perform the operations from left to right. So this would be calculated as follows:
netstat –c (10.0.0.4 && SMTP) || BEACON
And this would have done what we had said. If there is some question you can use the parentheses in the filter as shown. The following will create the same subset of packets but would not if we were to exclude the parentheses:
netstat –c BEACON || (10.0.0.4 && SMTP)
A parentheses grouping can be negated as you would expect. The following will create a capture of all activity EXCEPT email communications with the SERVER.
netstat –c !(10.0.0.4 && smtp)
Finally if we had wanted to mask these email communications from the overall capture buffer we can install this filter using the command:
netstat –f !(10.0.0.4 && smtp)
This would result in the following Registry setting and would filter out matching communications until such time as the filter is removed.
IpConfig/CaptureFilter = !(10.0.0.4 && smtp)
The JNIOR will only capture packets that are addressed to it. That would include broadcasts.
Ok. Well perhaps it is undocumented (and you didn’t hear it from me) but you can set the IpConfig/Promiscuous Registry Key to true. The JNIOR then will capture (subject to any filtering) all traffic including packets not addressed to the JNIOR. But for this to be of any use you will need to be using a Network Hub instead of a Network Switch. There is a difference. The latter “switch” will only pass packets to the JNIOR that are addressed to it in addition to any broadcasts. If you are interested in other traffic you need to use the “hub” which passes all traffic to all connected devices.
The Series 4 JNIOR with a hub then can be a valuable network debugging tool useful in sniffing traffic between two other devices (connected via hubs). It would allow you to remotely use the features of Wireshark.