Bug 727870

Created attachment 460009 [details]
NFS Client which cannot locate a NFS Server without entering its IP

Hello :-)

I don't know exactly what you mean - on what part of YaST is the problem.

But I know I have some problems with the yast printer module, problems that are now identified and solved or wontfix'ed.

Specifically I use several Hp network printers. These printers are usually not found by the "search" yast function in the printer module.

By now, the problem *is* the firewall. If I disable the firewall, the printer is found. I could discuss this with the firewall author and he assumes the firewall do his job and shall not be disabled by the yast module.

So my solution is:
* either disable the firewall ("SuSEfirewall stop" as root) as long as you search the printer, then write down the IP;
* let run the firewall and type the IP in the search field, then test the server, it's found

of course, in this case the problem being the firewall doing his job very hard, we can see this as wontfix. However, the yast printer module author added two or three warning messages about the firewall so nobody should now ask why it don't work.

Given dhcp always use the same IP for always present hardware like printer, the problem is not large, I often stick a tape on the printer with the IP number ;-)

(just verified in factory)

DHCP will always try to use the same mappings - unless a netadmin has cause to instruct termination of these mappings via a Router. It is NOT fare to say that you can ALWAYS reply on a Workstation to always have the same IP if DHCP allocates it. The only completely safe way is to create static IP's - Yes.

Now on to the Issue...The problem is that ANY yast application, like the example, cannot auto locate workstation or devices on the network, without the user entering the actual IP.

THE PROBLEM IS NOT THE FIREWALL!

Look at the attached example again - you can see that in the case of a NFS Client, that using the 'Choose' button, NO NFS Server is found on the Network with exported directories.

The only way to locate exported directories is by entering the IP of the NFS Server Workstation.

In respect to the printer Module, I have no problems using the connection wizard with a TCP Port 9100 IF I input the IP of the device. If I use 'scan all hosts' etc. which relies on the same preface as the 'choose button' the device is not found. If I input the IP of the printer in the device is found immediately.

Most all of the Network Services in Yast have a Server/Client type relationship, yet using the 'choose' or 'browse' of 'find' option does NOT find their partner.

In all cases it only works by entering the IP as the 'Host Lookup' has never worked. If you would like me to further clarify with any other Yast Network Service please ask and I will, capture the image

Verify in Factory!!!!!!!!!!!!
This bug has been present since 10.0 and exists to this very moment. Very few users have a network to test Network Services and for the same reason you have given me in your comment, is the very same reason why I haven’t bug reported it over the years... :-)

(In reply to comment #0)
> Steps to Reproduce:
> 1.I have a NFS Server running on IP 192.168.1.20
> 2.I setup a NFS Client and IF I enter the Servers IP above I see the
> directories.
> 3.If I use the 'Choose' button no NFS Servers are found in the first instance.
> THE FIREWALL IS NEVER THE PROBLEM -  the error response is erroneous always,
> always, always. 
> Actual Results:  
> Every single server, client, or locate printer or locate host in Yast fails and
> has never work as tested on my network since Suse Linux 10.0 to current.

I've reproduced the issue you've reported, except the problem was the firewall.

bestie:~ # rcSuSEfirewall2 status
Checking the status of SuSEfirewall2    running
bestie:~ # yast2 nfs-client

# Here, YaST NFS Client could not find any NFS server

bestie:~ # rcSuSEfirewall2 stop
Unloading firewall rules                done
bestie:~ # yast2 nfs-client

# Here it was able to find all NFS servers around

If it doesn't work for you, there might be several reasons:
1.) NFS server doesn't reply for a broadcast
2.) Your firewall is on even if it says it's off
3.) Your router doesn't support broadcast or drop the packets somehow
4.) Your NFS client is in a different network to your NFS server
    and thus unreachable by brodcast

You can easily check the packets going back and forth by tcpdump:

  tcpdump -n port 111

Run this command before starting YaST, then perform the network search
and evaluate the tcpdump output. You should find one or more UDP packets
sent from

  $YOUR_CLIENT.$SOME_HIGH_PORT to $NETWORK.255.111

And get one or more UDP replies from

  $SERVER.111 to $YOUR_CLIENT.$SOME_HIGH_PORT

Please, do the test described in comment #5 and provide your results. Thanks.

Sorry for the delay Lukas - Nice to hear from you - Just got back from holidays and I have 120 message just in my inbox...dont know what my partner in crime has been doing..Get back to you soon

Scott

I think I might set the scene for my LAN
I dont use DHCP - every devise has a static IP.
I do not have IPV6 activated.
I do not run ANY NFS V4 Servers or Clients

Please confirm that this issue in this bug works perfectly in your own environment before we go much further. In other words if you select the choose button on a NFS client you actually do see listed all the NFS Servers on your LAN

Lukas there obviously is traffic flowing from NFS client to server and Back again, otherwise when I input the target IP address all the exported directories appear.

If I open NFS Client and select add and then select 'choose' I get the attached error response. The moment I input the NFS Servers IP in the choose box, I get a list of exported directories no problem - perfect.

When I do input a valid NFS Servers IP AND activate NFSV4 - I get the response attached - 'Internal Error'

The firewall is open for both NFS client and server and traffic must flow between server and client. If I input the NFS Servers IP in and do NOT activate NFSV4 tick box - everything works.

As far as getting a test p[piece of information can you help me to extract the exact traffic and exact port number when I select the choose button. You'll need to help me with the command. 

You may want a far different method of tracking down why this has never worked since 10.0. The reason it has never been fixed is because NO-one who raises a bug report on Yast almost always gets the response WONTFIX.  Changes to Yast in off limits to everyone but suse.de and I can give you a search run in bugzilla to show this is the case...but lets move forward and actually try to get this thing to work as designed, I.E without needing to input IP addresses.

This bug is about yast2-nfs-client. Martin, could you please look into it?

Created attachment 465395 [details]
1 of 4

As I appear to have someone’s ear, I may as well complete the other huge bugs of the NFS Server/Client Relationship. This is yet another example of NFS Server/Client gone mad. In this test I created an NFS Server V4 with GSS Security Option and exported only one directory /home - nothing else.

I opened a new black NFS Client, input the IP address of the NFS Server and hee's the kicker...The list of exported directories were the /home directory of the NFS Server which I did share but the directory above /home, which is /file_server, was also in the list and then the / - root directory of the whole file system above /home and above /file_server.
The title of the image files shows exactly what the image files are about.

The next test shows my standard NFS Server, NON V4, NO GSS Security, NO V4 options on exported directories. This test shows the result of a NFS Client V4, with the NFS Servers IP inserted and where the exported directories should be; the is just 'internal error'

I am sure you needs logs for all the above which are available - Please be very specific is your request for the log files you need - I'll send them to you happily...I fell like Scrooge, wrecking everyone Christmas with all these bugs at suse.de

Created attachment 465396 [details]
2 of 4

Created attachment 465397 [details]
3 of 4

Created attachment 465398 [details]
4 of 4

Please advise specific logs required to fault report as well as the file containing the login script and results

Its a toss up between yast and Kernel...Jiri I'll leave it up to you to reassign to kernel IF you feel that this is a definite Kernel issue..It might be useful if I attach the yast audit logs...Please be specific on which logs you need

Created attachment 471272 [details]
ALL NFS SERVER Errors - Scores of errors Errors ALL

This upload is all the y2logs - Please request other log files with accuracy - I hate confusing so many monumental errors in so many logs

Created attachment 471275 [details]
All NFS Client Logs

Please request any other log files accurately 
_ I dont like uploading so many monumental errors its that frightening

Comment on attachment 471272 [details]
ALL NFS SERVER Errors - Scores of errors Errors ALL

OOOPs - sorry about all the email notifications

YaST calls "rpcinfo -b mountd 1" to find NFS servers. What does that
command output when you run it ina shell?

Please check for /sbin/rpcinfo and /usr/sbin/rpcinfo.

From the NFS Client or NFS Server or both please??

The client. This bug report is about the client side, right?

Created attachment 473366 [details]
As requested

I have bugs open on NFS SAMBA etc...I need to be sure so please forgive me for asking for perfect accuracy.
Not many testers have an offline LAN to test on, - I do so I can test many things that fall over or don’t work. My Production LAN is left alone.
It would be essential that you use the GUI interface of Yast to illustrate that this is 100% reproducible - If I have a bug that is not 100% reproducible - I don’t log it.

Created attachment 473367 [details]
/usr/sbin/rpcinfo

I asked for the output of the program not the binary itself!

You will need to be more precise in what logs you want...I live in advanced user world and not a coding and compiling world like you. IF you could help me provide the exact file name/logs you need we can start to work together to fix this bug once and for all. Please tell me the results you find in the same network conditions by only using the KDE GIU interface.

I'll reassign back to default, so they can legitimately close this as valid or invalid.

See above entry I set as the third or fourth comment
Quote

>> I am sure you needs logs for all the above which are available - Please be >> very  specific is your request for the log files you need - I'll send them to you happily..................

Unquote

Long time no response.So closed.Feel free to reopen it.Thanks.

I placed NEEDINFO ON YOU so you can answer my question
>> I am sure you needs logs for all the above which are available - Please be >> very  specific is your request for the log files you need - I'll send them to you happily..................
None the less I am reopening for two reasons
First this issue occurs in 12.1 and secondly so you can guide me to provide any other log data before it disappears.
Its 100% reproducible and if this is not occurring at your development the question is why the difference - Please request any 12.1 Logs you need

Last time, you were asked for the output of /usr/sbin/rpcinfo command.

Can you be a bit more specific with the above command which only yields

scott@MULTIVAC-010:~> /usr/sbin/rpcinfo command
Usage: rpcinfo [ -n portnum ] -u host prognum [ versnum ]
       rpcinfo [ -n portnum ] -t host prognum [ versnum ]
       rpcinfo -p [ host ]
       rpcinfo -b prognum versnum
       rpcinfo -d prognum versnum

For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
scott@MULTIVAC-010:~> /usr/sbin/rpcinfo
Usage: rpcinfo [ -n portnum ] -u host prognum [ versnum ]
       rpcinfo [ -n portnum ] -t host prognum [ versnum ]
       rpcinfo -p [ host ]
       rpcinfo -b prognum versnum
       rpcinfo -d prognum versnum

For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
scott@MULTIVAC-010:~>

Could you try calling 'rpcinfo -b mountd 1' as hinted in comment 19?

My apologies for not replying to #19.
The output is as following

scott@MULTIVAC-010:~> su
Password: 
MULTIVAC-010:/home/scott # rpcinfo -b mountd 1 
MULTIVAC-010:/home/scott # rpcinfo -b mountd 1
MULTIVAC-010:/home/scott # 

When I execute the above the PC takes some time before a NUL output...and YES I do have NFS Services on this PC and other running at the time of the above

Can you please clarify what info I can help with in the above.
This bug effects any find or locate PC from NFS to Printer. I think its well time that this really does work without having to enter the IP address of the client PC or device.
I am happy to lower to major, but I can help looking and feeling very foolish when asked why it never works....even since 10.2! Too many times I find myself having to say 'Oh that bit doesn't work in Yast' use this work around

This all seems a bit too hard to fix after 9 or so month - Closed as WONTFIX IS APPROPRIATE

I'll just keep saying to other...Oh! That doesn't work, just enter the IP address.
...and you must use static IP's

DHCP  works fine until the LAN admin changes the router input to the patch panel and all DHCP mappings are all change asa the mappings rely on the MAC address of the routers input V/LAN patch panel and all devices from the patch panel/switch.

It also seems a bit too hard to have just 2 PC networked in a test Lab bench where are these 100% reproducible bugs can be reproduced saving hundreds of man hours with dialogue going back and forward.

Despite this bug has been there for ONE+r years  with log files back and too NOTHING WAS DOE TO CORRECT THIS. It was closed by the reporter as WONTFIX DUE FACTS ALL CONTAINED here how apparent no resources were ever going to be allocated for solution.

Suse needs 'A problem Manager, a Integrated Problem management Database and allocation of expected result along the line that leads to the bug being fixed.

The problem managers is get solved as many bugs as possible even if they have to cary a big stick and at its highest , problem at the highest form be a major problem at site - That classifications should call all resources working out 24/7 to solve the problem and to have a autopsy why it failed at site...etc. etc. etc.

The Problem Manager of which we have none, nor any classification on how the bug effects only site, site distro'd, only versions, only architecture should and the PM Must have teat - Just like in standard commercial companies

Let the record show that despite this bug long exist and, and 100% reproducible that no work has progressed since 10.0 and this in my third time and 3rd year to to what it is suppose to do...Lets forget the locate or browse and tell users to enter IP addresses that always work.

It is perfectly clear this will never be fixed