oliver's questions

I have an Ubuntu 22.04 server, a MikroTik CRS328-24P-4S+RM switch, and Ethernet connected cameras. I wanted to increase the MTU on all systems so that jumbo frames are transferred, to reduce the CPU load on the server when receiving HD streams from many cameras, however I noticed that even with default MTU settings (1500 bytes) the cameras send jumbo frames already.

In more detail:

• on the server ip l shows for the network interface: 2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000; i.e. MTU 1500.
• on the switch management web interface I checked the MTU for the interface towards the server and for the interfaces towards the cameras. They are set to MTU = 1500 and L2 MTU = 1592.
• the cameras I don't know how to check the MTU (they are a blackbox for me).

I checked size of transferred packets:

• on the server I looked at the packets with tcpdump. tcpdump -i eno2 -s 100 -e | less shows packets like this: 16:25:06.315612 <MAC redacted> (oui Unknown) > <MAC redacted> (oui Unknown), ethertype IPv4 (0x0800), length 9014: camera1.3957 > server.46179: UDP, length 8972. The ethernet packets have a size of 9014 bytes.

• I disabled "offloading" on the server, with ethtool --offload eno2 rx off tx off as described at https://wiki.wireshark.org/CaptureSetup/Offloading.

• on the switch I can see that the interface to a camera has an RX rate of ~500 Mbps and an RX packet rate of ~7000 p/s. This comes out to ((500/8)*1024*1024)/7000 = ~9362 bytes/packet.

Questions:

• did I make any mistake in my analysis, above?

• is it possible for network devices to send UDP packets larger than the configured MTU of intermediate devices?

Appendix:

Results of ethtool --show-offload eno2:

Features for eno2:
rx-checksumming: off
tx-checksumming: off
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: off
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off [requested on]
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: on
receive-hashing: on
highdma: off [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: on
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: on
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: on
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]

I have some build hosts where I cannot install a Java JDK (for various reasons). Therefore the Jenkins Agent cannot be started there. How can I use these hosts with Jenkins CI?

Is there an non-Java implementation of the agent available? Or is there an agent available that uses eg. only SSH to execute commands on the build hosts?

In my server there's an mdadm RAID-1 array consisting of two SATA disks, named sdb and sdc. The sdb disk might fail soon (according to SMART data), and I want to replace it with a newly bought disk. The solution at https://unix.stackexchange.com/a/104052 sounds good for copying contents from the failing disk to the new one without stressing the remaining good disk too much (essentially the new disk is added as spare, then all data is copied from sdb to the spare).

Unfortunately the server only has two SATA ports, so I'd like to attach the new disk via a USB-SATA adapter for the copy operation, and later attach it to the SATA port.

But I guess this way the new disk will first get a name like /dev/sdd when attached via USB, and when I disconnect the failing disk and connect the new disk via SATA the new disk will be named /dev/sdb. Will the RAID software cope with this gracefully? Or will this confuse the RAID array? Will it cause an unnecessary rebuild of the array? And if so, what would be a better way to perform this procedure?

This is on Debian 7 (Wheezy), with Linux 3.2 and mdadm 3.2.5.

What is the recommended way to manage installed Nagios (or Icinga) plugins?

At the moment all plugins on my system are installed from Debian/Ubuntu packages, so this takes care of updates, file integrity and clean deinstallation. Is there a similar way to manage plugins which are provided e.g. on http://exchange.nagios.org?

My current impression is that I have to manually download the script files from the website and place them e.g. somewhere in /usr/local/. But I have to manually check for updates and bugfixes to these scripts, I have to manually keep track of where these files were downloaded from, and I have to manually keep track of dependencies in case a plugin consists of multiple files.

Is there a better way to manage such plugins?

In some rare cases, ntpq -p reports here that it has two system peers, like this (IPs and results anonymized):

     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*1.2.3.1         .IRIG.           1 u    1   16  377     0.10   -0.012    0.05
-1.2.3.2        4.5.6.7           2 u    3   64  377     0.11    0.014    0.06
+1.2.3.3        4.5.6.7           2 u    5   64  377     0.12   -0.016    0.07
*1.2.3.4        4.5.6.7           2 u    7   64  377     0.13    0.018    0.05
-1.2.3.5        4.5.6.7           2 u    9   64  377     0.14   -0.020    0.06
+1.2.3.6        4.5.6.7           2 u   11   64  377     0.15    0.022    0.07

So there are two servers listed with an asterisk in front, which marks them as "system peers".

Is this actually valid (ie. having multiple system peers), or is that an error in the ntpd or ntpq program?

And if this is a valid situation, I wonder what is the actual stratum of this NTP client in this case - does it have stratum 2 or 3?

A remote user has tried to connect to my SFTP/SSH server for the first time, using the "Transmit" client under Mac OS X, and has found that the host key fingerprint doesn't match the expected value.

I have a screenshot of the displayed fingerprint and have compared it with the output of ssh-keygen -lf /etc/ssh/ssh_host_dsa_key and ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub, and it doesn't match either of these.

I have also unsuccessfully compared the fingerprint against the output of cut -d ' ' -f 2 < /etc/ssh/ssh_host_dsa_key.pub | base64 -d | sha1sum and cut -d ' ' -f 2 < /etc/ssh/ssh_host_rsa_key.pub | base64 -d | sha1sum (because it seems that there are different fingerprinting algorithms in use?).

The message box on client side is titled (translated into English)

Unknown host key for < hostname >

and states

The server is unknown. The fingerprint of the host key is < 16 octets >. ( Allow ) ( Deny ) [ ] Always

So there is no indication whether RSA or DSA key is used, or whether MD5 or some SHA algorithm is used for creating the fingerprint.

The fingerprint displayed to the remote user has 16 colon-separated octets, so it doesn't appear to use SHA-224 or anything higher. Update: I just noticed that even an SHA-1 hash will have 20 octets, so the displayed fingerprint is not in any SHA format apparently.

The connection ultimately goes to the correct server, because I can see the login attempt in my server logs if the user allows the connection. So it appears that the host name/IP is entered correctly on client side.

A connection to another (completely unrelated) SFTP server shows an incorrect fingerprint as well (but a different one than for the first server).

If I try to connect to the server myself using OpenSSH from some other host (or locally from the server itself), I am shown the correct fingerprint (the MD5 fingerprint for RSA host key).

The server is running Debian 6 LTS with the standard OpenSSH server.

What could cause this fingerprint mismatch? How can I debug this problem?

Running # su - oliver --command bash gives a shell but also prints the warning bash: no job control in this shell, and indeed Ctrl+Z and fg/bg don't work in that shell.

Running # su - oliver --session-command bash gives a shell without printing the warning, and job control indeed works.

The suggestion to use --session-command comes from Starting a shell from scripts using su results in "no job control in this shell" which states "[a security fix for su] changed the behavior of the -c option and disables job control inside the called shell".

But I still don't quite understand this. When should one use --command and when should one use --session-command? Is --command (aka -c) more secure? Or should one always use --session-command, and --command is just left in for backwards compatibility?

FWIW, I'm using RHEL 6.4.

I have a HTTP webservice where sometimes the connection setup fails in a strange way:

• client sends a SYN packet
• server sends a SYN,ACK reply
• client responds with RST

In which situations could a client system decide to reply with RST packet? I could imagine this happens when the SYN,ACK contains eg. incorrect sequence numbers (but this doesn't seem to apply in my case - the sequence numbers look fine). So I'm interested in an exhaustive :-) list of cases where a client would send a RST packet after receiving the SYN,ACK packet.

In particular, is it possible for the client application code (using normal BSD-style socket API under Linux) to cause this RST packet, eg. by calling close() while 3-way handshake is still in progress?