Re: [FIRMWARE] Itus Networks Shield Firmware Upgrade *WIP*
Posted by
Roadrunnere42 on
Jun 28, 2019; 3:48pm
URL: https://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1786.html
Hi
It's starting to go above my knowledge level but found this git hub page about afpacket hash fault on some linux kernels, may be worth a look before spend time with afpacket-fanout
just had a look at the snort conf files and when the Shield is in bridge mode (snort_bridge.conf) it uses afpacket
config daq: afpacket
config daq_dir: /usr/lib/daq/
config daq_mode: inline
config daq_var: buffer_size_mb=300
but when in router mode (snort7.conf and snort8.conf) it uses nfq
config daq: nfq
config daq_dir: /usr/lib/daq/
config daq_mode: inline
config daq_var: queue=7
Not sure why Itus used the two different methods, but I was told by one of there tech guys that they needed to get the Shield delivered and then sort things out with software updates.
Roadrunnere42
On Thu, 27 Jun 2019 at 18:01, Grommish [via Itus Networks Owners Forum] <
[hidden email]> wrote:
Roadrunnere,
I'm beginning to suspect your assumption on why there were 2 snorts might be right. The configurations seem identical, which you wouldn't suspect would be the case if they were actually different.
I did find some interesting things though.
If I switch from nfq to afpacket, I can span the interfaces (eth0:br-lan) and do a spread.
PACKET_FANOUT (since Linux 3.1)
To scale processing across threads, packet sockets can form a fanout group. In this mode, each matching packet is
enqueued onto only one socket in the group. A socket joins a fanout group by calling setsockopt(2) with level
SOL_PACKET and option PACKET_FANOUT. Each network namespace can have up to 65536 independent groups. A socket
selects a group by encoding the ID in the first 16 bits of the integer option value. The first packet socket to
join a group implicitly creates it. To successfully join an existing group, subsequent packet sockets must have
the same protocol, device settings, fanout mode and flags (see below). Packet sockets can leave a fanout group
only by closing the socket. The group is deleted when the last socket is closed.
Fanout supports multiple algorithms to spread traffic between sockets, as follows:
* The default mode, PACKET_FANOUT_HASH, sends packets from the same flow to the same socket to maintain per-flow
ordering. For each packet, it chooses a socket by taking the packet flow hash modulo the number of sockets in
the group, where a flow hash is a hash over network-layer address and optional transport-layer port fields.
* The load-balance mode PACKET_FANOUT_LB implements a round-robin algorithm.
* PACKET_FANOUT_CPU selects the socket based on the CPU that the packet arrived on.
* PACKET_FANOUT_ROLLOVER processes all data on a single socket, moving to the next when one becomes backlogged.
* PACKET_FANOUT_RND selects the socket using a pseudo-random number generator.
* PACKET_FANOUT_QM (available since Linux 3.14) selects the socket using the recorded queue_mapping of the re‐
ceived skb.
Fanout modes can take additional options. IP fragmentation causes packets from the same flow to have different
flow hashes. The flag PACKET_FANOUT_FLAG_DEFRAG, if set, causes packets to be defragmented before fanout is ap‐
plied, to preserve order even in this case. Fanout mode and options are communicated in the second 16 bits of the
integer option value. The flag PACKET_FANOUT_FLAG_ROLLOVER enables the roll over mechanism as a backup strategy:
if the original fanout algorithm selects a backlogged socket, the packet rolls over to the next available one.
I was going to specify config daq_var: fanout_type=lb and config daq_var: fanout_flag=defrag, although some of the other ones might be worth looking at.
Does anyone have any way to stress-test Snort to test for throughput?