Bug 997039
| Summary: | if connection.secondaries set both networks fail to connect | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vladimir Benes <vbenes> | ||||
| Component: | NetworkManager | Assignee: | Dan Winship <danw> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 | CC: | acathrow, danw, dcbw, thaller, vbenes | ||||
| Target Milestone: | beta | ||||||
| Target Release: | 7.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | NetworkManager-0.9.9.0-28.git20131212.el7 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-06-13 11:13:51 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Vladimir Benes
2013-08-14 14:25:44 UTC
Dan, can you take a look at this? I'd expect this to work, though we may have intentionally restricted this to VPN connections for the moment. If it's easy to remove that restriction (or if I'm remembering correctly and we didn't restrict it) then we should probably do it. The currently code was clearly written under the assumption that it was VPN-only. The biggest problem is that it passes the device of the "master" connection to nm_manager_activate_connection() when activating the secondary connection (which works for VPNs but not anything else obviously), so we'd have to add code there to walk the list of devices to figure out what the correct device to use was... Not sure how "easy" you meant by "if it's easy"... (In reply to Vladimir Benes from comment #0) > I've created connection for wireless network here in office. I added that > UUID into secondary of ethernet device assuming it will connect itself just > after wired network is connected. I have only one time password for vpn so I > was trying to test it this way. How does one-time-password matter? You should get prompted to enter the password when the VPN is started as a secondary just like if it's started automatically. (If you don't, then that's a bug.) Some of the code in dcbw/pending2xxx touches this and makes secondary processing in nm-policy no longer VPN-only. It doesn't solve the device issue, but that should be handled in the manager's generic code anyway where the device gets automatically chosen for a connection. Pass the device for the VPN case, don't pass it for the non-VPN case. (In reply to Dan Winship from comment #2) ng to test it this way. > > How does one-time-password matter? You should get prompted to enter the > password when the VPN is started as a secondary just like if it's started > automatically. (If you don't, then that's a bug.) I just wanted to say I cannot test it automatically as my password for vpn is not still. It doesn't affect this feature at all. What is the current status? Have we decided to dedicate secondaries to vpn only? (In reply to Vladimir Benes from comment #4) > I just wanted to say I cannot test it automatically as my password for vpn > is not still. Ah. Well, given that the only supported VPN in RHEL7 is openswan anyway, I imagine you'll have to set up a test server for that at some point, which wouldn't have the one-time-password problem that the Red Hat VPN has. > What is the current > status? Have we decided to dedicate secondaries to vpn only? It was only expected to work for VPN (and, eg, the UI will only let you add VPN connections as secondaries). We can make it so that trying to use it for other connection types just results in a warning message. NetworkManager[4324]: <warn> Secondary connection 'Team connection 1 (b83d450f-98b7-4c5f-9fc0-6a2e911354ed)' auto-activation failed: The connection is not a VPN. pushed to danw/secondaries note this actually makes the parent activation fail, for consistency with the behavior when you specify a non-existing connection as a secondary Looks good to me. Looks good to me too. > Flags: requires_release_note?
I'm not sure who that flag is directed at, but just to clarify, all we're doing at this point is giving a better error message in a case that never worked and was never documented as working.
OK, just caught up on email. Pretty sure this does not require a release note. Fix is pushed to upstream git. Oops, this should have been removed from RHEL70BetaIssues when we agreed it wasn't a bug (comment 5). this is not working even with vpn.. not speaking about another ethernet Created attachment 886892 [details]
messages
works for me... Do you have the appropriate VPN plugin for that connection installed? (You can install the ones from F20. And restart NM afterward.) What does the journal show when NM reads in the connection at startup? ok, mea culpa. It works well. I was adding wireless network (Red Hat) instead of vpn (RedHat). Bug 1094296 filed for mentioning that vpn can be used somewhere in docs or nmcli. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |