Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I note, that you actively refuse PAP authentication in your configuration (and that generally is a good idea), but it also depends on what the server is configured to use. Maybe the server requires a different authentication mechanism than CHAP (or it's variants)?
I have tried all the authentication mechanisms more or less out of desperation. None of them show any indication of starting authentication. Windows connects as a PPTP client so I am using the standard PPTP settings.
No, if it's not active I don't see how it would impact here. For completeness, what does your current routing table look like?
Code:
ip r
Code:
kim@linux-nogg:~/Downloads> ip r
default via 192.168.0.1 dev eth0 proto dhcp metric 100
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.102 metric 100
192.168.50.0/24 dev vmnet8 proto kernel scope link src 192.168.50.1
192.168.252.0/24 dev vmnet1 proto kernel scope link src 192.168.252.1
Telnet connects to the office server for close to 10 seconds before disconnecting.
Code:
kim@linux-nogg:~/Downloads> telnet 204.87.122.177 1723
Trying 204.87.122.177...
Connected to 204.87.122.177.
Escape character is '^]'.
Connection closed by foreign host.
I have a virtual Windows 10 installed to handle those few programs I use that don't run under OpenSuse. OpenSuse is the host.
You don't need any real argument to convince me this makes no sense. I've spent several days going nowhere on what should have been a 15 minute project.
Ok, I notice that you have NetworkManager version 1.22.10-1.1 (from factory) and NetworkManager-pptp version 1.2.8-2.1 (form factory). The problem may well be the versions in use. This matches the symptoms and versions reported in the openSUSE thread I linked to back in post #2. If I were you I'd disable that repo, and downgrade to the versions provided by the OSS repo.
Ok, I notice that you have NetworkManager version 1.22.10-1.1 (from factory) and NetworkManager-pptp version 1.2.8-2.1 (form factory). The problem may well be the versions in use. This matches the symptoms and versions reported in the openSUSE thread I linked to back in post #2. If I were you I'd disable that repo, and downgrade to the versions provided by the OSS repo.
This will give us the configured repos...
Code:
zypper lr -d
I upgraded from the previous version attempting to find a solution to this issue. I think the next step is to use a packet sniffer and see exactly what is happening. I've never had to use one and that is going to take a bit of time.
NetworkManager logging can be increased by putting it into DEBUG mode. This might yield more information as well.
From 'man NetworkManager.conf'....
Code:
LOGGING SECTION
This section controls NetworkManager's logging. Any settings here are overridden by the --log-level and --log-domains
command-line options.
level
The default logging verbosity level. One of OFF, ERR, WARN, INFO, DEBUG, TRACE. The ERR level logs only critical errors.
WARN logs warnings that may reflect operation. INFO logs various informational messages that are useful for tracking state
and operations. DEBUG enables verbose logging for debugging purposes. TRACE enables even more verbose logging then DEBUG
level. Subsequent levels also log all messages from earlier levels; thus setting the log level to INFO also logs error and
warning messages.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
