Summary: | In Core 175 testing, all OpenVPN n2n connections are broken | ||
---|---|---|---|
Product: | IPFire | Reporter: | Man Grove <mw+ipfire> |
Component: | openvpn | Assignee: | Assigned to nobody - feel free to grab it and work on it <nobody> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | - Unknown - | ||
Priority: | - Unknown - | CC: | adolf.belka |
Version: | 2 | ||
Hardware: | unspecified | ||
OS: | Unspecified |
Description
Man Grove
2023-05-28 11:16:37 UTC
This effect occurred from the fix to Bug#11048 that was applied in Core Update 175 Testing. The fix from 11048 has been reverted and will likely end up in CU176. As this effect is caused by the fix for Bug#11048 and will be solved by the updated fix for Bug#11048, I am closing this bug as a duplicate to that one. *** This bug has been marked as a duplicate of bug 11048 *** If you change the /opt/pakfire/db/core/mine file from 175 to 174 and then rerun the Pakfire Refresh List you can redo the update from CU174 to CU175 Testing but with the most recent build which includes the reversion of the patch set for Bug#11048. (In reply to Adolf Belka from comment #2) > If you change the /opt/pakfire/db/core/mine file from 175 to 174 and then > rerun the Pakfire Refresh List you can redo the update from CU174 to CU175 > Testing but with the most recent build which includes the reversion of the > patch set for Bug#11048. Sadly this didn't solve the problem: still the exact same error. You are of course correct. I reverted the patches but can't revert the actions from the update.sh script. If you look in /var/ipfire/ovpn/ovpnconfig at each of the n2n connections what do you find near the end of the line. There should be an entry at index 43 of no-pass. I suspect it will be an entry of disabled. It could also be pass but should not be. I would like to know what entry you find. Could you please put your answer into bug#11048. I will add your name to the cc list for that bug. |