aboutsummaryrefslogtreecommitdiffstats
path: root/network-scripts
Commit message (Collapse)AuthorAgeFilesLines
* ifup-routes: Use `ip route repace` to avoid raceJan Macku2022-01-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This should resolve the scenario when the link is brought up prior to disabling accept_ra. This only happens when both IPv4 and IPv6 address is on the interface, because network-scripts does IPv4 first and brings up the interface. Then it does IPv6 which disables the RA's, at that point the node has already learned the route from RA and setting a default route fails. Using `ip route replace` we ensure if the above scenario happens we end-up with the correct default ipv6 route. Huge thanks to Harald who debugged this issue and prepared a patch! (cherry picked from commit a71dcfd392cc1022c255208fdd94a0fc6c13ceb0) Resolves: #2040679 Co-authored-by: hjensas <hjensas@redhat.com>
* added veth supportGeiger2021-06-241-0/+11
|
* ifup-eth: add a new PERSISTENT_DHCLIENT_IPV6 option for IPv6 dhclient daemonZhiqiang Liu2021-06-241-1/+1
| | | | | | | | | | | | | | | | | | | | | In 76226a34 ("ifup-eth: apply PERSISTENT_DHCLIENT to IPv6 dhclient daemon"), one PERSISTENT_DHCLIENT option works for both IPv4 and IPv6, so the IPv4 and IPv6 settings are consistent. However, the user settings for IPv4 and IPv6 are limited. For example, users try to adopt both IPv4 and IPv6 protocol. DHCPv6 servers may be not stable as DHCP servers, thus the expectation for obtaining IPv6 address is lower than IPv4 address. For users, IPv4 address must be obtained for the basic communication. So the PERSISTENT_DHCLIENT option is set to be "yes | 1" for IPv4 address. However, the network service may be stuck until it fails due to missing DHCPv6 servers, and the remaining devices also cannot obtain both IPv4 and IPv6 addresses. The problem is very serious for users. Here, I add a new PERSISTENT_DHCLIENT_IPV6 option only for IPv6 dhclient daemon, so users can set IPv4 and IPv6 separately. Fixes: 76226a3 ("ifup-eth: apply PERSISTENT_DHCLIENT to IPv6 dhclient daemon") Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
* ifdown removes veth pair if both peers are downGeiger2021-06-241-0/+6
|
* network scripts: Avoid infinite loop of arpingJan Macku2021-02-122-4/+5
| | | | | | | | | Introduced in the bonding driver (commit ae46f184bc1f) now reports transmission failures. Before that, it silently dropped the packet and replied with success error code. The arping of iputils retries endlessly when a transmission error occurs. This patch fix this behavior.
* network: fix condition in set_link_up()Jan Macku2021-02-041-2/+5
|
* network: fix set_link_up()Jan Macku2020-12-171-3/+1
| | | | This patch fixes issue, when interface wasn't bring up.
* network: add option to keep the link downJan Macku2020-12-039-16/+25
| | | | | | | | Some interfaces like Open vSwitch bridges using the userspace datapath, needs the link to be kept down to avoid issues. Add a LINKSTATUS=[down|up] ifcfg parameter to add this functionality. If not specified, the link will default to up as before. Patch provided by Matteo Croce <mcroce@redhat.com>
* network-scripts: Use net_log() instead of loggerJan Macku2020-11-052-10/+8
| | | | Use internal network-scripts function net_log() instead of /usr/bin/logger if possible to make code more consistent and cleaner.
* Add warning to warn user when ETHTOOL_OPTS is set and ethtool binary is ↵Jan Macku2020-08-121-17/+21
| | | | missing - Olav Vitters
* Add optional 'dev' keywordJan Macku2020-07-242-3/+3
| | | | | | | | Fix the problem when the device name could be interpreted as an iproute2 keyword. For example, for a bridge slave named "a" the iproute2 would treat the name as a prefix of keyword "address" and the network-scripts would fail to set the bridge master. Related: rhbz #1859785
* Maintain permisision to set umaskzhangnaru06052020-07-141-0/+3
| | | set umask in case resolv.conf doesn't exist
* Correct spelling, IP, …Allan Nordhøy2020-07-141-1/+1
|
* Fix spelling, for more infoAllan Nordhøy2020-07-141-1/+1
|
* Wait for scope link addresses as well as for scope global addressesJan Macku2020-03-241-3/+3
| | | | Resolves: rhbz#1773798
* Use function is_true for testing true conditionsJan Macku2020-03-092-2/+2
|
* network-function: bridges are created by ifup-ethLukáš Nykrýn2019-10-171-0/+3
| | | Resolves: rhbz#1404265
* Repalace hardcoded tests for yes and no with testing functionsJan Macku2019-09-129-60/+60
| | | Resolve issue: #42
* ifup-eth: Fix bridge setting stp optionBell2019-08-211-1/+1
| | | | | | | | | | | Fixes https://bugzilla.redhat.com/1743522 An uninitialized variable was copied from a closed PR [1] to submitted PR [2]. [1] https://github.com/fedora-sysv/initscripts/pull/212 [2] https://github.com/fedora-sysv/initscripts/pull/213 Signed-off-by: Bell Levin <blevin@redhat.com>
* ifup-eth: Check that device name is setJan Macku2019-08-191-0/+5
|
* Add ip6gre tunnel optionJan Macku2019-07-312-1/+6
| | | | Resolve: BZ #1691552
* ifup/ifdown: print DEPRECATION_WARNING_ISSUED waring info after source_configZhiqiang Liu2019-07-252-12/+12
| | | | | | | | | In ifup/ifdown scripts, move deprecation waring info after source_config, so users can config DEPRECATION_WARNING_ISSUED in ifcfg-** file to decide whether show deprecation waring info when calling ifup/ifdown. Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
* ifup-eth: apply PERSISTENT_DHCLIENT to IPv6 dhclient daemonZhiqiang Liu2019-02-121-1/+7
| | | | | | | | | | | | | | | | | | | IPv6 dhclient daemon only tries one time to obtain a IPv6 address from a DHCPv6 server regardless of the setting of PERSISTENT_DHCLIENT. PERSISTENT_DHCLIENT option is only used for IPv4 dhclient daemon. With the popularization of IPv6 protocol, some users prefer setting IPv6 like IPv4. I think there are two solutions as follows, 1. adopt PERSISTENT_DHCLIENT option to both IPv4 and IPv6. 2. create a new option, such as PERSISTENT_DHCLIENT_IPV6 option, just for IPv6. The first solution does not introduce addition options, and the IPv4 and IPv6 settings are consistent. So I perfer choosing the first solution. Fixes: bf00a0048 ("Replace /var/run with /run everywhere") Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
* ifup-post: fix incorrect condition for RESOLV_MODSDavid Kaspar [Dee'Kej]2018-08-241-1/+1
| | | | | | | | | | This was causing the /etc/resolv.conf file to be always updated when RESOLV_MODS was not set... Before the commit 5d6156454bf8f6dab4a5fdd7e1bf6 we were not updating the /etc/resolv.conf file if the RESOLV_MODS was empty. See https://bugzilla.redhat.com/show_bug.cgi?id=1610411 for more info.
* network/ifup/ifdown: deprecations warnings redirected to stderrDavid Kaspar [Dee'Kej]2018-08-062-6/+6
|
* ifup-eth: use 'bc' instead of 'expr' when computing $forward_delayDavid Kaspar [Dee'Kej]2018-08-031-2/+4
| | | | | | | | | | | | | | | | Because the return value of 'convert2sec()' function can sometimes be decimal, the follow up 'expr' call can fail, since 'expr' does not support floating point calculations. This can sometimes lead to error: """ expr: non-integer argument /etc/sysconfig/network-scripts/ifup-eth: line 91: [: 0: unary operator expected """ To solve this bug, we switch to 'bc' utility, which supports floating point computations. We also have to change the comparison condition of $LINKDELAY and $forward_delay to use 'bc' as well.
* network/ifup/ifdown: deprecation warnings for 'network-scripts' addedDavid Kaspar [Dee'Kej]2018-08-022-0/+12
| | | | | In case of 'network' service these warnings are displayed only once, to not spam unnecessarily user's journalctl if they have many NICs.
* network-scripts: Add previously dropped error checkingPhil Sutter2018-06-141-2/+2
| | | | | When converting from brctl to ip-link, the call to exit in case bridge adding failed was dropped by accident.
* network-scripts: Replace brctl with ip-linkPhil Sutter2018-06-142-17/+19
| | | | | Since ip-link has full support for Linux bridges (and slave ports), use that instead of the deprecated brctl from bridge-utils.
* network-scripts: setting of firewall ZONE fixedDavid Kaspar [Dee'Kej]2018-06-073-5/+6
| | | | | | | | | | | | | For currently unknown reason the dbus-send calls will fail to set the firewall zone for the given interface if we omit the --print-reply option... This looks like some kind of race-condition in dbus-send, since the --print-reply makes the call synchronous and slower. Hopefully this is only a temporary workaround until DBus is fixed. Resolves: #1586284
* ifdown-post: artifact whitespace removed from the DBus callDavid Kaspar [Dee'Kej]2018-06-071-1/+1
| | | | | | | This was causing the DBus call to fail, and we didn't catch it before since we were forwarding everything into /dev/null... Related: RHBZ#1586284
* netreport functionality droppedDavid Kaspar [Dee'Kej]2018-05-304-35/+0
| | | | This concept is quite outdated, and not sane to use at all.
* Repository scheme updated to new layoutDavid Kaspar [Dee'Kej]2018-05-3027-0/+4971
NOTE: This commit just moves files around, without actually fixing the Makefiles and specfile. See follow up commits which resolve this.
generated by cgit v1.2.1 (git 2.21.0) at 2024-11-25 23:59:05 +0000