Re: Trouble configuring a VPN interface to access a Windows network
On Sat, 14 Mar 2009, Dan Williams opined: > Ok, those should have the domain fixes. One thing to debug with would > be to enter the full domain+username in standard Windows format into the > "username" box, and clear the domain box. > > Dan No, that didn't work. Tried domain\user, domain\\user, domain/user. All failed. I then tried a few experiments and, after a bit of fiddling, checked the "Advanced / Use Point-To-Point encryption (MPPE)" and the connection was successfully established!!. So, in the end, this is a (l)user problem. :( For the record, the following is the system log (again slightly edited for security/privacy reasons). ~~~ NetworkManager: Starting VPN service 'org.freedesktop.NetworkManager.pptp'... NetworkManager: VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 24115 NetworkManager: VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections NetworkManager: VPN plugin state changed: 1 NetworkManager: VPN plugin state changed: 3 NetworkManager: VPN connection '???' (Connect) reply received. pppd[24118]: Plugin /usr/lib/pppd/2.4.4/nm-pptp-pppd-plugin.so loaded. pppd[24118]: pppd 2.4.4 started by root, uid 0 pptp[24119]: nm-pptp-service-24115 log[main:pptp.c:314]: The synchronous pptp option is NOT activated pppd[24118]: Using interface ppp0 pppd[24118]: Connect: ppp0 <--> /dev/pts/1 pptp[24128]: nm-pptp-service-24115 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' pptp[24128]: nm-pptp-service-24115 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply pptp[24128]: nm-pptp-service-24115 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. pptp[24128]: nm-pptp-service-24115 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' pptp[24128]: nm-pptp-service-24115 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. pptp[24128]: nm-pptp-service-24115 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 24506). pptp[24128]: nm-pptp-service-24115 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 50185 pptp[24128]: nm-pptp-service-24115 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is , recv_accm is pptp[24128]: nm-pptp-service-24115 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are notsupported! pppd[24118]: CHAP authentication succeeded pppd[24118]: MPPE 128-bit stateless compression enabled pppd[24118]: local IP address 172.25.194.17 pppd[24118]: remote IP address 172.25.194.10 pppd[24118]: primary DNS address 10.20.7.202 pppd[24118]: secondary DNS address 10.20.7.200 NetworkManager: VPN connection '???' (IP Config Get) reply received. NetworkManager: VPN Gateway: 0.0.0.0 NetworkManager: Tunnel Device: ppp0 NetworkManager: Internal IP4 Address: 172.25.194.17 NetworkManager: Internal IP4 Prefix: 32 NetworkManager: Internal IP4 Point-to-Point Address: 172.25.194.10 NetworkManager: Maximum Segment Size (MSS): 0 NetworkManager: Internal IP4 DNS: 10.20.7.202 NetworkManager: Internal IP4 DNS: 10.20.7.200 NetworkManager: DNS Domain: '(none)' NetworkManager: Login Banner: NetworkManager: - NetworkManager: (null) NetworkManager: - NetworkManager: VPN connection '???' (IP Config Get) complete. NetworkManager: Policy set '???' (ppp0) as default for routing and DNS. NetworkManager: VPN plugin state changed: 4 ~~~ The difference starts at the line pppd[24118]: MPPE 128-bit stateless compression enabled in the failed run it was: LCP terminated by peer (^BM-?-M-K^@http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default-Routing problems
Colin, I like this idea. It definitely would be helpful for ethernet and wifi devices where the user only wants to connect to the lan and not have a default route set. It may have relevance to a GSM or CDMA connection(PPP connections in general) if the user is only using that connection to run a vpn over, but I am not sure. With that being said it is not really my decision to make and the more people who show interest in a feature such as this the better chance for it to be implemented. I personally have wanted a feature such as this and priority of interfaces for about two years, but I can not complain because NM has continued to improve for the better and this may still be an edge case for user needs. I do feel this feature will continue to become more and more relevant in the future. -- John On Sun, Mar 15, 2009 at 12:00 PM, Colin Coombs wrote: > Following up to my previous post: > > Here is an idea for an small enhancement to NetworkManager which would > solve my particular problem, and perhaps be generally useful for other > users with 'non-standard' use cases. > > 1. Define a new flag 'Local only' for each network connection. By > default, this flag is unset and does not affect the existing behaviour > of NetworkManager. > > 2. when NetworkManager is choosing which connection to use for the > default route, any connection with the 'Local only' flag set will not be > chosen. > > A connection with this flag set can still be started automatically and > it will have a routing table entry for its particular IP subnetwork as > usual. > > This flag should be set for any network connection that you are only > using to access local resources (e.g. printers and file shares). > > I know of cases where wired-Ethernet and WiFi connections are used in > this manner. I don't know if this flag would be sensible on GSM or CDMA > connections (but I suspect not). > > By the way, I notice that Windows Vista detects whether a given WiFi > connection has internet access or not. I don't know how they detect > that, but I am not proposing the NetworkManager tries to do it -- a > manual setting is all I am asking for. > > Any comments? > > > > ___ > NetworkManager-list mailing list > NetworkManager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default-Routing problems
Following up to my previous post: Here is an idea for an small enhancement to NetworkManager which would solve my particular problem, and perhaps be generally useful for other users with 'non-standard' use cases. 1. Define a new flag 'Local only' for each network connection. By default, this flag is unset and does not affect the existing behaviour of NetworkManager. 2. when NetworkManager is choosing which connection to use for the default route, any connection with the 'Local only' flag set will not be chosen. A connection with this flag set can still be started automatically and it will have a routing table entry for its particular IP subnetwork as usual. This flag should be set for any network connection that you are only using to access local resources (e.g. printers and file shares). I know of cases where wired-Ethernet and WiFi connections are used in this manner. I don't know if this flag would be sensible on GSM or CDMA connections (but I suspect not). By the way, I notice that Windows Vista detects whether a given WiFi connection has internet access or not. I don't know how they detect that, but I am not proposing the NetworkManager tries to do it -- a manual setting is all I am asking for. Any comments? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default-Routing problems
On Sat, 2009-03-14 at 21:47 -0400, Daniel wrote: > The > problem is that when I have a wireless connection going, then plug in the > ethernet - the route defaults to the wired connection. Hence, killing my > ability to waste time surfing and reading mailing lists... ;) Does this happen as well if you create a special "wired" profile for that work site which has the setting "DHCP (Addresses only)"? it could imagine that like this, it will only get an addess and ignore any other info such as DNS servers, WINS servers and NetBIOS node types. Ah.. just tried it. Doesn't work; it still accepts the default gateway from DHCP and modifies the routing table This however works: create a wired configuration profile for that "work site", which has has a static IP, but no default gateway configuration. Like that, the DHCP-learnt route from the WiFi will take precedence. regards Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
