Things are working the way they are supposed to, and possibly the only way they can work. Let me explain.
Without an Apache module called mod_rewrite (or the equivalent Nginx or IIS component) requests to PHP pages have to go to an actual filesystem file. That is what you see with requests like 192.168.1.8/wordpress/?p=123. The file being accessed is the directory “index” file— index.php. That request is the equivalent of 192.168.1.8/wordpress/index.php?p=123. What you are doing is requesting some other file/directory with requests like this one– 192.168.1.8/wordpress/asdasdasd— and no such file or directory exists in the filesystem.
With mod_rewrite and .htaccess properly configured all requests get sent to index.php. Take a look at the stock WordPress .htaccess file:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
That RewriteRule pushes everything (almost everything) to index.php. That allows WordPress to process any request, even requests for files that don’t physically exist on the system.
Without pretty permalinks enabled– that is, with the “default” permalinks selected– WordPress will not even try to parse the requests so that is equivalent to not having mod_rewrite or .htaccess at all.
And, if WordPress can’t parse the request, WordPress can’t load the theme’s 404.php. Apache, of course, still knows the request is bad and loads its own 404 message.
So, without mod_rewrite, a proper .htaccess file, and pretty permalinks you get the behavior you describe, which is exactly how things are supposed to work.