Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Persistent Names changing on stable multihomed machine
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sat Feb 07, 2015 4:07 pm    Post subject: Persistent Names changing on stable multihomed machine Reply with quote

I have a multi-homed choke firewall box with two wired NICs. The hardware configuration never changes but the machine is frequently cold-started. One NIC is built in, the other is a PCIe adapter.

The add-in PCIe NIC always shows up as enp3s0. The built-in NIC flaps back and forth between enp4s0 and enp5s0. This wreaks havoc on my iptables rules. As I understand it, these names are derived from the PCI bus enumeration, so I suspect something on this particular motherboard is causing a race condition in the enumerating. Ironic that it's the built in one, and ironic that it would be a race condition. None of this matters to me but it is interesting that this goofy convention was supposed to stop a problem I never had while causing the very one it was supposed to prevent. ANYWAY...

I tried going back to the old (and far more likable) kernel naming via the GRUB_CMDLINE_LINUX="net.ifnames=0" mechanism. Sure enough, I get eth0 and eth1, but eth0 -- which should get a fixed IP via /etc/conf.d/net but it does not (i.e., config_eth0="172.16.7.1"). Instead I consistently get an apipa-like (169.154) address. Sometimes I get some spew during start-up like -- can't recall precisely -- "local: waiting for ... 60sec" and it counts down. eth1 gets an address via dhcp no problem.

I did spend some time early on chasing udev work-arounds a while ago on different machines (never this one, it's always used these idiotic 'persistent' names, not meant to rile anyone, just idiotic IMHO)

I don't mind fixing this any which way, but I was wondering if anyone had any tips on the eth0 issue and creating udev rules. I know that there are many howto's out there but udev seems to be harder to get hold of than a greased pig, and what works is not exactly 'universal'....

I am using:
Code:
sys-fs/udev-216
sys-boot/grub-2.02_beta2-r3:2
sys-kernel/gentoo-sources-3.17.8-r1:3.17.8-r103:00.0


The relevant bits fron the PCI bus look this way (The Realtek interface is built in, the Intel adapter is an expansion card):

Code:
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
04:00.0 RAID bus controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)


Any help is be greatly appreciated.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sat Feb 07, 2015 4:33 pm    Post subject: Reply with quote

dbishop,

Write some udev rules to generate interface names based on the MAC addresses of the interfaces.
Avoid the namespaces already in use, since you do not want name collisions.
udev will no longer do renaming for you.

This used to be done automatically for wired interfaces so we had persistant names before udev introduced persistent names.
It was not so good for wifi interfaces that had software assigned (and often random) MAC addresses.

If you can live with the kernel names and just want them to be persistant, make the kernel drver for the interface that is to be eth0 built in and eth1 as a module.
This eliminates the kernel race as built ins are always enumerated before modules.
You still need to tell udev to keep its hands off your interface naming.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Feb 07, 2015 4:56 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Write some udev rules to generate interface names based on the MAC addresses of the interfaces.

dbishop, Neddy ... some weeks back I setup a similar type box for a friend ... not much to it, mostly a stage3 minus udev, and toolchain, plus the addition of iptables and such. I don't have access to the machine so I can only provide similar output from this one:

Code:
# cat /etc/mactab.conf
# Generated by settle-nics from mdev-like-a-boss.
eth0            xx:xx:xx:xx:xx:xx
wlan0           xx:xx:xx:xx:xx:xx

Of course "interface names" can be whatever you want.

best ... khay
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Sat Feb 07, 2015 4:59 pm    Post subject: Reply with quote

What you should do ; edit the 70-per...rules file and force matching it thru its mac adress. I don't use the stupid new naming, so i don't know howto do it with it, but here's howto do it with old style (that works for me)
Quote:
cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:26:18:2f:cc:06", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Quote:
ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.4 netmask 255.255.255.0 broadcast 192.168.0.255
ether 00:26:18:2f:cc:06 txqueuelen 1000 (Ethernet)


I'm totally unsure if this still works with udev but it will with eudev-1.9
Note that if you get totally bored by kernel renaming collision, you could just change eth0 to intel0 and config_intel0="172..." to stop the kernel race condition.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sat Feb 07, 2015 5:49 pm    Post subject: Reply with quote

krinn,

That no longer works if the interface name you are trying to assign is already in use.
Hence my advice to avoid names like ethX.

udev used to do interface renaming, so that this wasn't an issue.
The udev devs dropped that, which messed up most systems with two or more interfaces, then a few udev versions later, thay added "persistent" interface names, which upset most users and at the same time fixed a few corner cases that the owners had learned to live with, at the same time, they created another class of corner cases that took the owners by surprise.

All in all, an utter shambles.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Feb 07, 2015 6:14 pm    Post subject: Reply with quote

NeddySeagoon wrote:
All in all, an utter shambles.

... a situation for which the term "omnishambles" was created :)

best ... khay
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sat Feb 07, 2015 6:40 pm    Post subject: Reply with quote

NeddySeagoon (and others),

Very Grateful.

I am happy to create a udev rule set, seems the simplest. I admit I am a little confused about structure, syntax, and location. There used to be /etc/udev/rules.d/70-persistent-net.rules and that bit the dust and trashed a whole bunch of work a while back (I have 20 or so Gentoo boxes doing all sorts of things dating back to 2003 or thereabout). Certain syntax worked, then didn't, then needed arcane options. It was exhausting keeping up. I used to have this a while ago:

Code:
# PCI device 0x10ec:0x8167 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:fc:9f:31:29", KERNEL=="eth*", NAME="eth0"

# PCI device 0x11ab:0x4364 (sky2)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:fc:9f:36:a1", KERNEL=="eth*", NAME="eth1"


And then there is /lib64/udev/rules.d/80-net-setup-link.rules. I read somewhere that there is some sort of equivalent for thwarting it in /etc/udev/rules.d/. I have seen elsewhere people need to symlink whatever workaround to other names in /etc/udev/rules.d to avoid future clobberings. And I'd use eudev if that would help (frankly I am not even sure what the pros and cons are...)

Code:
# do not edit this file, it will be overwritten on update
SUBSYSTEM!="net", GOTO="net_setup_link_end"
IMPORT{builtin}="path_id"
ACTION=="move", IMPORT{db}="ID_NET_DRIVER"
ACTION!="add", GOTO="net_setup_link_end"
IMPORT{builtin}="net_setup_link"
NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"
LABEL="net_setup_link_end"


in which, I get the feeling, there should be a way to fix things in this file with something from this (from a different machine):

Code:
udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null
ID_NET_NAME_MAC=enx50465d70bee1
ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=en Onboard LAN
ID_NET_NAME_PATH=enp0s25


To avoid naming collisions I was thinking to call one 'theo' and the other 'lennart', but if I do that, the box will never stop shouting at itself or it force everything to do things its way or else... :P

Seriously, I am happy to write the udev rules -- would they look like the old "70-" structure/syntax? or the new "80-" format? udev seems to change more often than GTK...
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sat Feb 07, 2015 6:43 pm    Post subject: Reply with quote

dbishop,

I don't suffer from udev or its 'friends' any more.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sat Feb 07, 2015 6:56 pm    Post subject: Reply with quote

No udev? What else is there? It's hard enough trying to keep systemd off my boxes...

What is the difference/benefit of eudev?
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Feb 07, 2015 7:34 pm    Post subject: Reply with quote

dbishop wrote:
No udev? What else is there? It's hard enough trying to keep systemd off my boxes...

dbishop ... sys-fs/static-dev (Neddy's favorite), sys-apps/busybox[mdev], sys-fs/mdev-bb::foo-overlay (the latter two can be used with sys-fs/mdev-like-a-boss::foo-overlay) ... and ...

dbishop wrote:
What is the difference/benefit of eudev?

eudev ... a fork of systemd-udev, basically.

best ... khay
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sat Feb 07, 2015 8:24 pm    Post subject: Reply with quote

dbishop,

I use nothing - or more accurately. I have a static /dev with no auto anything.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sat Feb 07, 2015 9:05 pm    Post subject: Reply with quote

NeddySeagoon (and others),

static dev looks interesting, but it would take much longer tom implement than I have available...

Question now is, is it better to switch to eudev or stick with regular udev, and then write some udev rules like this and put it in a file called /etc/udev/rules.d/70-persistent-net.rules?

Code:
# PCI device 0x10ec:0x8167 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:fc:9f:31:29", KERNEL=="eth*", NAME="eth0"


or is there another way? I have searched and searched for smething specific, but can't find it. The best I found was http://www.reactivated.net/writing_udev_rules.html and http://wiki.gentoo.org/wiki/Udev but they seem out-of-date

And I still don't understand why GRUB_CMDLINE_LINUX="net.ifnames=0" yields the old eth* names but I can't get /etc/conf.d/net config_eth0="172.16.7.1" to work
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sat Feb 07, 2015 9:14 pm    Post subject: Reply with quote

dbishop,

Post your /etc/conf.d/net file please.
net.ifnames=0 gets you kernel names, so config_eth0="172.16.7.1" should work too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sat Feb 07, 2015 11:00 pm    Post subject: Reply with quote

Here it is. You can see some genetic baggage from my wrestling with this thing. I am not presently using net.ifnames=0, but when I did, I got eth0 and eth1. eth1 dhcpcd correctly (not in the config at all) but eth0 just returned that ridiculous 169.254 nonsense but did not assign the desired 172.16.7.1 IP.

Code:
# This blank configuration will automatically use DHCP for any net.*
# scripts in /etc/init.d.  To create a more complete configuration,
# please review /usr/share/doc/openrc*/net.example* and save your configuration
# in /etc/conf.d/net (this file :]!)

# globals
searchdomains="test.sys"
nameservers="127.0.0.1"


# local instrumentation network
config_enp3s0="172.16.7.1/24"
config_eth0="172.16.7.1/24"

# upstream interfaces via dhcp
dhcpcd_enp4s0="-C ntp.conf"
config_enp4s0="dhcp"
#fallback_enp4s0="172.16.3.134/25"
#fallback_route_enp4s0="172.16.3.129/25"

dhcpcd_enp5s0="-C ntp.conf"
config_enp5s0="dhcp"
#fallback_enp5s0="172.16.3.134/25"
#fallback_route_enp5s0="172.16.3.129/25"

dhcpcd_eth1="-C ntp.conf"
config_eth1="dhcp"
#fallback_enp5s0="172.16.3.134/25"
#fallback_route_enp5s0="172.16.3.129/25"

# The network scripts are now part of net-misc/netifrc
# In order to avoid sys-apps/openrc-0.12.4 from removing this file, this comment was
# added; you can safely remove this comment.  Please see
# /usr/share/doc/netifrc*/README* for more information.



And here is what it is currently doing -- notice enp3s0. it got assigned a 169.254 address and a route too. Looks like the extra IP and extra route are harmless (or appear to be)

Code:
dbishop@temmanuel ~ $ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1b:21:b1:c5:1f brd ff:ff:ff:ff:ff:ff
    inet 172.16.7.1/24 brd 172.16.7.255 scope global enp3s0
       valid_lft forever preferred_lft forever: xauth key data not generated
    inet 169.254.3.149/16 brd 169.254.255.255 scope global enp3s0rwarding.
       valid_lft forever preferred_lft forever
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c8:60:00:c4:d4:99 brd ff:ff:ff:ff:ff:ff
    inet 172.16.3.134/25 brd 172.16.3.255 scope global enp5s0
       valid_lft forever preferred_lft forever
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default
    link/ipip 0.0.0.0 brd 0.0.0.0
5: ip_vti0@NONE: <NOARP> mtu 1364 qdisc noop state DOWN group default
    link/ipip 0.0.0.0 brd 0.0.0.0


Code:
dbishop@temmanuel ~ $ ip r s
default via 172.16.3.129 dev enp5s0  metric 203
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
169.254.0.0/16 dev enp3s0  proto kernel  scope link  src 169.254.3.149  metric 202
172.16.3.128/25 dev enp5s0  proto kernel  scope link  src 172.16.3.134  metric 203
172.16.7.0/24 dev enp3s0  proto kernel  scope link  src 172.16.7.1


And thank you again for helping.
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sun Feb 08, 2015 12:14 am    Post subject: Still getting stupid 169.254 addresses (APIPA) Reply with quote

Okay, I created a custom udev rule set, replete with an homage, using the same syntax as I used long ago, and that seemed to work okay.

Code:
temmanuel ~ # cat /etc/udev/rules.d/70-net-name-use-custom.rules[/i]
# First one uses MAC information, and 70- number to be before other net rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:c5:1f", NAME="neddy0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c8:60:00:c4:d4:99", NAME="neddy1"


The remaining problem seems to be that the first interface "neddy0" -- hah i was sure there wouldn't be a conflict -- gets both the fixed IP & subnet I assigned in /etc/conf.d/net -- but as a bonus prize I got a 169.254/16 IP assigned as a second interface address. Argghh. I got a bonus route for it too.

How does one get rid of unwanted apipa behaviour?

And here they are below:

Code:
temmanuel ~ # ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
2: neddy0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1b:21:b1:c5:1f brd ff:ff:ff:ff:ff:ff
    inet 172.16.7.1/24 brd 172.16.7.255 scope global neddy0
       valid_lft forever preferred_lft forever
    inet 169.254.106.70/16 brd 169.254.255.255 scope global neddy0
       valid_lft forever preferred_lft forever
3: neddy1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c8:60:00:c4:d4:99 brd ff:ff:ff:ff:ff:ff
    inet 172.16.3.134/25 brd 172.16.3.255 scope global neddy1
       valid_lft forever preferred_lft forever


And below you can see the extra route that got added:

Code:

temmanuel ~ # ip r s
default via 172.16.3.129 dev neddy1  metric 203
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
169.254.0.0/16 dev neddy0  proto kernel  scope link  src 169.254.106.70  metric 202
172.16.3.128/25 dev neddy1  proto kernel  scope link  src 172.16.3.134  metric 203
172.16.7.0/24 dev neddy0  proto kernel  scope link  src 172.16.7.1

and my /etc/conf.d/net

Code:
searchdomains="test.sys bish0p.org donbishop.cc mediacell.com"
nameservers="127.0.0.1"

config_neddy0="172.16.7.1/24"
dhcpcd_neddy1="-C ntp.conf"
config_neddy1="dhcp"
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Feb 08, 2015 12:31 am    Post subject: Re: Still getting stupid 169.254 addresses (APIPA) Reply with quote

dbishop wrote:
How does one get rid of unwanted apipa behaviour?

dbishop ... it should be sufficient to do the following:

/etc/conf.d/net
Code:
modules_neddy0="!apipa !dhcpcd"
config_neddy0="172.16.7.1/24"
modules_neddy1="!apipa dhcpcd"
dhcp_neddy1="nontp"
dhcpcd_neddy1="--noipv4ll"

best ... khay
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Sun Feb 08, 2015 1:20 am    Post subject: Reply with quote

khayyam,

Many thanks. Not sure when the game changed from saying what you wanted for an interface to saying what you don't want, but now that I know I'll play along...
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Feb 08, 2015 2:38 am    Post subject: Reply with quote

dbishop wrote:
Many thanks. Not sure when the game changed from saying what you wanted for an interface to saying what you don't want, but now that I know I'll play along...

dbishop ... you're welcome. It didn't change, its just that with computers it helps to be explicit :)

best ... khay
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Feb 08, 2015 12:46 pm    Post subject: Reply with quote

dbishop,

:)

You get the 169.254.x.x address for free when dhcp cannot find a dhcp server. Its a self assigned address that is useful only for ad hoc networks where there is by definition, no router.
No route is required to reach other 169.254.x.x/16 members either.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
UberLord
Retired Dev
Retired Dev


Joined: 18 Sep 2003
Posts: 6835
Location: Blighty

PostPosted: Mon Feb 09, 2015 10:09 am    Post subject: Reply with quote

NeddySeagoon wrote:
No route is required to reach other 169.254.x.x/16 members either.


A subnet route of 169.254/16 is still required.
That's technically a route :P
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool
Back to top
View user's profile Send private message
dbishop
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2007
Posts: 107

PostPosted: Mon Feb 09, 2015 1:58 pm    Post subject: Reply with quote

Thx everyone. I understand what apipa is, I just was wrestling with keeping it off this system since I didn't really want it, and worse, it was breaking things -- ordinary things. To me, Gentoo always meant never ending up with Microsoft-inspired cruft unless i put it there. *sigh*

It started popping up on some of my Gentoo boxes while on others it did not. On this particular machine it started when I used ifnames=0. The afflicted interface that was set to a fixed IP via /etc/conf.d/net while it was not getting the fixed IP, so the dhcp-ness of it all was baffling. There was an appropriate link in /etc/init.d/net.eth0 (all instances of enp3s0 -> eth0) and /etc/conf.d/net was correct too.

Adding to the irony, the "persistent names" were bouncing around, probably something to do with a PCI bus enumeration race condition on this particular Asus mobo. Of course a flapping interface name is anathema to things like iptables on a multihomed machine acting as a router, so it had to be fixed, and publicly so, hence the public forum work-through. Which of course points out why megalomaniacs should stick to people-politics and not become OS Nazis.

In the end, Khay hit on it -- just overtly disable apipa. I combined this with Neddy's good advice to re-introduce udev mac-based-remapping rules (which I am sure will be a constant source of upgrade headaches like before). I called the interfaces neddy1 and neddy2, but on further thought i will rename one of them to khay1. Always be grateful (-:
Back to top
View user's profile Send private message
UberLord
Retired Dev
Retired Dev


Joined: 18 Sep 2003
Posts: 6835
Location: Blighty

PostPosted: Mon Feb 09, 2015 2:07 pm    Post subject: Reply with quote

dbishop wrote:
Thx everyone. I understand what apipa is, I just was wrestling with keeping it off this system since I didn't really want it, and worse, it was breaking things -- ordinary things. To me, Gentoo always meant never ending up with Microsoft-inspired cruft unless i put it there. *sigh*


Apple had the biggest hand in writing the RFC, Sun also participated.
It shouldn't break anything at all and I don't see how it possibly could.

There are many valid use cases for this, especially when partnered with mDNS.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum