Hi all,

X-server abnormalities, specified as accurate as possible and hopefully,
it is reproducible and sorry for a rather long description.

Hosts and Slackware versions + Windows client which are used to connect to X:
Slackware14.2
Slackware64 14.2
VcXsrv X-client (Windows to Slack*)
Slackware64-current

Script used to connect from Host to another Host are:

ipv6
/usr/bin/X -query ipv6-myhost :1 -auth "$HOME/.Xauthority"
ipv4
/usr/bin/X -query myhost :1 -auth "$HOME/.Xauthority"

Type of connections tested

Abnormal results of X current to other X servers, black screen.

The problem behaviour of one X-server to another is at the end of this story.

Firstly I describe the normal behaviour.

Slackware 14.2 to Slackware64 14.2

For Slackware 14.2 both ipv4 and ipv6 hosts connect fine with the above type
of command line.

netstat shows the connection
tcp6 32 0 ipv6-hostA:45242 ipv6-hostB:6001 ESTABLISHED
/var/run/xdmctl shows the creation of "dmctl-ipv6-hostB:1

ipv6-hostA, ipv6-hostB, hostA (ipv4), hostB (ipv4) are defined in /etc/hosts
The search should always take "hosts" first and secondly take "bind".
The hosts run Secure DNS (bind, ipv6 and ipv4 (dualstack))

WINDOWS TO SLACK 14.2 & CURRENT
VcXsrv to Slackware(64) 14.2, Slackware64 current

The settings of VcXsrv includes a "-from" definition to solve inet/inet6 matters.
but VcXsrv acts as an ipv4 client only.

Abnormalities:
The clients on the local network only deviate between host name in current (19 April and earlier version)

hostC.mydomain.nl (slackware64-current)
hostA (slackware 14.2)
hostB (slackware64 14.2)

The "hostC.mydomain.nl" is also shown on slackware64 current's LOCAL KDM logon screen.

Please note that the server Slackware64 14.2 (hostA) is connected to the internet (WLAN) and
"domain.nl" is not on the local network.
There exists eth0 (local network), eth1 (WLAN, the world) and eth3 (wifi)
The firewall is between eth1 (WLAN) and eth0 (local) & eth2 (wifi)
the firewall applies ipv4 NAT and ipv6 NAT.
This means that any reference of "mydomain.nl" never can appear in any X-server listing.

SLACKWARE 14.2 to CURRENT
To Current runs OK, for ipv6 and ipv4 and the correct host appears in the netstat list,
and in the /var/run/xdmctl entries,
except that the logon name of current is hostC.my.domain.nl and not hostC
as in 14.2.

However, hostC-current's netstat

tcp6 32 0 ipv6-hostC:45242 ipv6-hostB:6001 ESTABLISHED
/var/run/xdmctl shows the creation of "dmctl-ipv6-hostB:1

So far OK

CURRENT TO 14.2 THE PROBLEM....... the A.nom.a.lies in CURRENT

The script hostC to hostA

/usr/bin/X -query ipv6-hostA :2 -auth "$HOME/.Xauthority" (from hostC to hostA, using DISPLAY:2)
In netstat on hostA the server to the outerworld

and in netstat we find a dangerous record !!!!

tcp 0 1 mydomain:54454 mydomain.nl:6002 SYN_SENT
tcp 0 0 hostA:38261 hostC:1714 ESTABLISHED

very weird, no such thing should be established !!!

CURRENT, only shows a black screen.

/var/run/xdmctl
appears a wrong "dmctl-domain.nl:2 instead of "dmctl-ipv6-hostC:2

there is no connection whatsoever possible. "domain.nl" is not equal to ipv6-hostC, so current does not look in "hosts".

/usr/bin/X -query ipv6-hostA :2 -from hostC -auth "$HOME/.Xauthority"

then there is an ipv4 only connection while requested was ipv6.

Probably a DNS derived from KDMs Logon screen is used to look into a wrong domain not on the local network

I looked around to find a solution, but the only is ipv4 solution is
the "-from hostC" addition.

So it would be great if somebody has a solution to make current X behaviour equal to 14.2's behaviour, without those
dangerous records to the outerworld, the public internet.

regards,

talo

Raw X11 sessions over network was a fun thing they used to do in the Heroic Age of Computing, beyond 30 years ago. When the computer labs was fully enclosed and there was no Internet yet.

Even if the today X.org inherits/supports that thing, doesn't will be a secure thing, and no one will bother to ever think about those ancient features.

Long story short, today better keep your raw X11 sessions in localhost and if you really do not want to use a modern remote solution like at least VNC, I strongly suggest you to use at least SSH tunnels, even in a local network.

They will give you a much much better security and will reduce considerably the flooding with pixmaps of the network.

Blame your habits of using '80 designs, blame also the X.org that they changed the code in the newest releases, then I suggest you to move over. Slackware does not patch things, they are used as is.

PS. No offense, but that "hostC.mydomain.nl" thingie is a laughable idea. Why you will do that?

Dear Darth Vader,

We only use X-server on the local network, and it is protected by the firewall.
There is no possibility to go beyond the firewall to the outer world,
unless X behaves strange, in other words does mangle host names, and does not use explicit names as given,

so X goes to the outer world where is should not be.
I can use ipv4 connection -- savely -- but not ipv6.
Then X creates wrong addresses, and thats the problems.

The usage is rather restricted, and now user unfriendly.

Do you wish me to fall back to Windows, I have such a system which restarts randomly,

please consider some user friendly option, under strict conditions,


talo

@talo

You are right in your original post about the sequence of resolving host names, first /etc/hosts and then the nameserver, but I'm wondering if you addressed also the ipv6 in your /etc/hosts and not only ipv4
https://unix.stackexchange.com/quest...t-from-windows

In another post you've mentioned that X might have issues with ipv6 and I'm suggesting to focus on setting up your systems correctly:
https://www.linuxquestions.org/quest...0/#post5845181

Hi Abga,

We have both ipv6 and ipv4 names in the host file.
It's rather simple, I have put ipv6- before the base host name.
I love the old greek, so we have some like
xx.xx.xx.xx archimedes archimedes.domain.nl
fdfx::yy ipv6-archimedes ipv6-archimedes.domain.nl

So I always know whether an address in ipv6 or ipv4 and I use the short names
for local and these name only apply to the local network (dualstack).
I have a script to define static ipv6 addresses to eth0, eth1 and eth2.
This works on 14.2 any system and any windows system on the local network.
There are not so many people here, but I need more than one platform.
I started with slackware 3.1, a long time ago.

So we have a dualstack static solution using slackware 64 14.2.
It is a wunderful system and it keeps all ugly people from my beloved system.
So all humble love to the slackware development.

But ivp6 works in 14.2 and it works from 14.2 to current.
The reverse goes wrong.
What did make we worrying were the strange addresses being not on the local network.
Our system, is attacked at recugular times. This has to do with my works on languages.
So I am in the invitation book of so many.

I had expected that X-server should work out of the box, and when times comes I would
look around the refinements.

The preferred DNS addresses don't work.
So I will look to your suggestions.

But in my opinion things should me kept as simple as possible.
In science psychophysiology we try to explain things using the simplest method.
Nowaday things are made complex.

I will look around and see whether I understand the man pages etc. etc etc.

But the system is setup correctly, all daemons work in dualstack, except some inetd daemons.

Thanks,

talo

I'd check the entire name resolution related configuration on the Slackware current system(s) and not only focusing on /etc/hosts but also on /etc/nsswitch (which defines the order for the name reguests), /etc/networks and on the file /etc/resolv.conf, where I would suggest to examine the search option:
https://superuser.com/questions/5700...tion-option-do

Note that once a hostname is resolved by an application or a service, it will remain in cache for a while and the only option to clear the cache manually is to either restart the network interface(s) (flush the configuration) or the whole system (pretty lame but simpler).

I'd also like to hint to not use the nslookup or hosts tools to test your file based name resolution, because both will talk to the configured nameserver.
should help you with your ipv6 investigation.

Not ruling out that xorg might have some issues with ipv6, but at least with the help of ping6 you can check if your configuration is solid.

It'll be also useful to define local LAN zones in your configured nameserver (bind).

Hi abga,

I have looked into the nsswitch.conf file, but the are no differences between current and 14.2:
passwd: compat
group: compat

hosts: files dns
networks: files

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
bootparams: files

automount: files
aliases: files

ping6 -c 1 hosts answer with one ping, a space was required in ping6's current.

resolve.conf on current includes the follow on current:

search mydomain.nl
nameserver 192.168.xx.1
nameserver fdfx::1

what's wrong?

The most alarming was that I found specialport request on the server
from "world ip6" to the world eth1 ip6 address, of course rejected
by the firewall

Apr 21 07:39:31 MYHOST kernel: [51156.981872] fp=SPECIALPORT:1 a=DROP IN=eth1 OUT= MAC=68:05:ca:3d:73:82:34:31:c4:5c:8e:42:08:00 SRC=83.162.193.xxx DST=192.168.yyy.xxx LEN=44 TOS=0x00 PREC=0x00 TTL=62 ID=4199 DF PROTO=TCP SPT=52711 DPT=6001 WINDOW=29200 RES=0x00 SYN URGP=0

if somebody else did a request the SRC would have been different (there are people who
are trying to hack a system). These results match to the fact that X did try to use "mydomain.nl" which is indeed the above address.

I will try other things too, but that will take time.

I assume a hard restart will flush the configuration (cache)

regards,

talo

Sorry, I was hungry and ate the space between the -c (count) option and the parameter - corrected now in my previous post.
The ping6 test was supposed to check what is used for the name resolution - local files / name server. I forgot (I considered it obvious) to mention to use tcpdump on the network interface and look for a potential DNS request generated by the ping6, if none available, then the local files were the ones used for the name resolution. All these in order to test your local name resolution (files) configuration and to answer your statement from your original post:
You said you're running your own BIND as a resolver and I suggested to define your local LAN domain in it, because that will help you with processes that ignore the local files (which might be erroneous) and send the DNS request the configured name server. Here you have a start point (ipv4 only):
https://www.madboa.com/geek/soho-bin...a-local-domain

Where is the IPv6 Address? SRC=83.162.193.xxx might be the IP resolved by your BIND for the domain mydomain.nl, or someone indeed probing you. I guess you're aware that portscanns are something continuously happening nowadays, it's already an "obvious" phenomenon.

Now, you're having this dual-stack configuration, which is a sort of double-trouble, since you need to care about both ipv4&ipv6 in all your configuration/firewall/DNS at the same time. I'm wondering however, why are you not keeping your LAN on IPv4 only? If you have some remote hosts, you can easily use a VPN (openvpn) to connect to them and keep them in your IPv4 LAN, have better control on the traffic and the connection is secure too.

Just a side note:

Basically, the entire Romania is covered by a 1GB private network within an IPv4 10.0.0.0/8, while the Romanians are really active in this domain. Every family have at least a computer, but many has several. We are 20 millions, and of course, our private network is open to Internet.

Believe or not, a similar nation-wide 1GB private network, within 10.0.0.0/8 is used by North Korea for their own Intranet, and they are 25 millions. But in this case, the network is closed and careful tracked.

Did the OP believe that his own private network needs more than 16 millions IP addresses, then he must go IPv6? Or, he just love to complicate his life?

The IPv6 specification became a draft internet standard almost 20 years ago.

I use the private 10.x.x.x network inside my home's intranet. If my ISP supported IPv6, I'd switch over in a heartbeat.

Hi All,

There is a lot to do.

The following works on Current but only for ipv4.

/usr/bin/X -query hostA :2 -from hostC -auth "$HOME/.Xauthority"

So this can be used for a while.

If my previous usage of X without -from did not host the /etc/hosts file, than
I will have to trace what is really happening. Not only on current, but also the server
which is connected to the Internet. So we have:
current eth0 (local net)
SL14 64 14.2 eth0 (local net) -- eth1 (the world wide internet)

As far as I can see ipv4 and ipv6 behave identically.

I remark on using ipv6 with X or with any other ipv6 application.
The reason NAT was introduced to ip6tables was not a matter of amount of numbers
but only "privacy of infrastructure". It is a choice made (Darth Vader), ipv6 is not a problem, nor dual stack.
ssh(d) -6 works within the local network without any problem,
the ftp-client takes ipv6 and connects to ipv6-hostA on the local address,
current handles SMB call as usual with out any problem.

Probably I have to define a local ZONE for DNS (as abga said)

It will take some days because I cannot change too frequently things on the server (14.2).
But I will start to trace DNS in current first.

So I will return on the matter.


talo

I was briefly going again through your original post and noticed that your Slackware -current HostC, which has the domain mydomain.nl, might not be properly configured after all, since your logon name contains the mydomain.nl entry.
Just for orientation, here you have a host configuration example from an actual configured LAN that talks only ipv4, note that I'm using the simple one word "lan" instead of "mydomain.nl":
The simple ping6 + tcpdump test that I suggested would help you check your local files configuration, not that much to do, nowhere near "a lot"
There is a distinct possibility that the new version of X ignores the static ipv6 entries in the local files and only talks to the DNS server, but I doubt it.

This resolv.conf imply that you have two DNS (bind?) servers up and running in your local network.

Hi ZhaoLin1457

What's wrong? The behaviour of X as a net work display server and its usage of DNS.
Current behaves different.

There have more than one DNS (binds) running, usually one for intern and one for external world.

We have more than one slackware system for the case that there are problems, replicas.
Once the power supply of the main server was broken, so I had to exchange the PCs.
We have no problems with Slack 14.2 to Slack 14.2.

Current is set up to be as close as possible to slackware 14.2,
but it used for test purposes only.
Some changes to DNS zones have to be made and I have to read some bind docs for
multiple interfaces (NICS). So resolve.conf might change.

talo