Linux – kernel: nf_conntrack: table full, dropping packet; Underlying Reason

The kernel sees the weird scan codes and drops them. I would try to get those scan codes values and then update the hardware database index. So in short the plan is this:

• get the codes from dmesg output - dmesg should output something like this when the unknown keycode is pressed:

  Unknown key pressed (translated set 2, code 0xa0 on isa0060/serio0)
  

a0 being the code value.

• create custom keycode mapping file. The examples and help are in the default file
  (/usr/lib/udev/hwdb.d/60-keyboard.hwdb for Arch, it may be different in other distributions).

• update and trigger the hardware database by running the commands:

  > udevadm hwdb --update
  > udevadm trigger /dev/input/eventXX
  

where eventXX corresponds to your keyboard (you can get it by running evtest). You may also reboot instead of triggering.

Look in Arch wiki and the default keycode mapping file for the more detailed description (or in your distribution documentation if it's not Arch).

This is the reliable and simple method, makes mapping on the kernel level so works whatever display server, DE etc is.

Is it possible to see Where did this rule come from?

Not in the sense "where can I look up the source of this rule". There are several ways to investigate the issue: the most evident is to grep all startup scripts on your system to see which uses ip rule at all, and then start reading them. Or you could start your system in single-user mode, and start services one-by-one, from command-line, using strace. Or you might start your system with bash as init (kernel command line: init=/bin/bash), and then you can exec the real /sbin/init with strace. These are rather advanced ways to trace the startup activities, it may not be trivial to know which scripts to run...

There is no way to know where the specific rule came from if it was an administrator or a hacker entering it manually, and not a script present on the system.

What is the point of empty routing table?

Nothing - until someone starts populating that table. This could be a daemon, initially entering the rule for its own table, and then dynamically changing the contents of its own routing table.

how can there be multiple rules with same priority?

IPROUTE2 Utility Suite Howto

priority PREFERENCE --- priority of this rule. Each rule should have an explicitly set unique priority value. Priority is an unsigned 32 bit number thus we have 4294967296 possible rules.

WARNING!

For historical reasons ip rule add does not require any priority value and allows the priority value to be non-unique. If the user had not supplied a priority value then one was assigned by the kernel.If the user requested creating a rule with a priority value which already existed then the kernel did not reject the request and added the new rule before all old rules of the same priority. This is a mistake in the current design, nothing more. It should be fixed by the time you read this so please do not rely on this feature. You should always use explicit priorities when creating rules.